AWS 于 2026 年 9 月 9 日发布的两份安全公告，把一个常被抽象描述的问题变得非常具体：能够查询生产数据库的 AI 工具，不能把字符串匹配规则当作最后一道防线。公告涉及 AWS Labs 的两个开源、自托管 Model Context Protocol（MCP）服务器，分别面向 PostgreSQL 和 MySQL。两者都提供只读模式，意图阻止助手执行会修改数据的 SQL。但最终决定请求能做什么的，仍然是数据库账户。

人工智能网络与数据库被警示闸门隔开的抽象插图，表现只读文本过滤器的局限性。

PostgreSQL 问题更为严重。AWS 将这一弱点编号为 CVE-2026-87911。在特定的软件包版本、连接方式、数据库权限和用户交互组合同时存在时，它可能导致操作系统命令执行。修复版本为 1.1.7。

MySQL 公告涉及 CVE-2026-85788，描述的是只读检查中的另一种失效：在特定条件下，SQL 行内注释可以绕过过滤器。受影响的是 1.0.21 及更早版本，AWS 表示该问题已在 1.0.23 中修复。

这些并不是 Aurora、RDS 或其他 AWS 托管控制平面中的服务端漏洞，而是客户自行安装和运营的客户端软件包中的问题。这个区别会影响事件响应范围，但并不意味着公告无关紧要。这些软件包把 AI 助手连接到数据库、凭据，以及某些配置下运行服务器的主机。一处很小的解析错误，便可能在自然语言请求被转换为数据库操作的节点上，演变成访问控制问题。

AWS 公布了什么

两份公告同时出现，但它们描述的技术条件不同，应当分别分级处理。若把它们笼统地称为一个 MCP 漏洞，反而会降低响应的准确性。

对于 awslabs.postgres-mcp-server，AWS 表示 1.1.7 之前的版本在 SQL 验证组件的只读强制逻辑中存在操作系统命令注入弱点。公告点名了 PostgreSQL 的 COPY ... TO PROGRAM 语句这一数据库功能。在存在漏洞的部署中，即使服务器运行在默认只读模式下，经过身份验证的用户与 MCP 服务器交互时所处理的内容仍可能到达这条路径。

公告没有说每一种安装都能被远程利用，而是指出了更狭窄的部署画像：使用 PG_WIRE_PROTOCOL 连接方式连接自主管理 PostgreSQL 服务器，并且配置的数据库角色拥有超级用户权限或 pg_execute_server_program 角色。AWS 将可能后果描述为：在自主管理 PostgreSQL 服务器的主机上执行操作系统命令。这里“可能”二字很重要。公告确认了一个危险漏洞及其相关条件，但并未确认客户已经遭到攻击。

PostgreSQL 官方文档解释了为什么权限条件会改变严重程度。PROGRAM 命令由数据库服务器执行，而不是由客户端执行；PostgreSQL 将这一能力限制给超级用户或被授予服务器程序角色的用户。换言之，该数据库权限本身就具有强大能力。MCP 弱点的关键在于，它可能让输入越过软件包只读模式本应守住的边界。

对于 awslabs.mysql-mcp-server，AWS 表示 1.0.21 及更早版本在特定条件下可能允许执行本应被只读检查阻止的语句，触发方式是使用 SQL 行内注释。公告没有描述与 PostgreSQL 公告相同的操作系统命令路径，而是说明该软件包为自托管，并且该问题不影响 AWS 服务的机密性或完整性。实际风险在于：权限超出预期的数据库账户，可能执行应用层检查试图拒绝的写操作。

首先应记录的运营事实就是修复版本：PostgreSQL 为 1.1.7 或更高版本，MySQL 为 1.0.23 或更高版本。不要推断升级一个软件包就能修复另一个。它们是两个独立的发行包，版本线也彼此分开；一支软件队伍中很容易同时存在两者。

“只读”为什么会造成误解

很多数据库工具把“只读”当成一个单一属性，其实并不是。这个词背后至少藏着三类不同的控制。

第一类是应用内部的解析器或过滤器。它检查 SQL 文本，拒绝与写入、会话修改或其他敏感操作相关的标记。这种方式速度快，也适合给用户即时反馈。它可以拦住普通错误，例如用户要求生成报告，助手却生成了 UPDATE。

第二类是数据库会话或事务模式。PostgreSQL 和 MySQL 都提供了限制会话行为的机制，不过具体行为和例外取决于数据库引擎、连接方式及账户。会话级设置可以再增加一层保护，但仍不能替代账户权限，而且必须针对实际工作负载进行测试。

第三类是数据库身份本身，也就是登录服务器的角色或用户。这个身份拥有授权、对象所有权、角色成员关系、存储过程访问权，以及可能存在的特殊服务器能力。它才是持久的边界，因为请求经过客户端、MCP 服务器、SQL 解析器和中间策略后，最终仍由数据库来评估这个身份。

AWS 当前的 PostgreSQL 服务器 README 明确说明，只读强制机制是尽力而为的保护措施，不是安全边界。文档建议使用专用数据库角色，并警告不要使用超级用户、rds_superuser 或集群主用户。MySQL README 也表达了同样的观点：服务器端 SQL 文本防护属于纵深防御，真正的边界是配置的数据库角色。

这些公告让原本停留在文档中的提醒变成了运营问题。文本过滤器只能处理它识别到的表示形式。SQL 具有注释、带引号标识符、条件语法、存储例程、版本相关功能、多语句，以及会随时间变化的解析器行为。LLM 又增加了一层变化：它可能生成不常见但语法有效的输入，也可能受到数据库或其他工具返回内容的影响。不能指望一个正则表达式完整建模所有这些交互。

因此，安全设计要提出两个不同的问题。“MCP 服务器会不会拒绝这个请求？”有助于减少意外写入；“如果服务器接受了这个请求，数据库账户能做什么？”才是限制影响范围的问题。第二个问题的答案必须在第一层控制被绕过、配置错误、版本过旧或覆盖不完整时，仍然安全。

哪些团队应当立即复核

PostgreSQL 公告与以下组织最相关：在 1.1.7 之前安装了 AWS Labs 软件包，并通过 wire protocol 连接自主管理 PostgreSQL 部署的组织。如果数据库角色是超级用户，或拥有 pg_execute_server_program，应当立即检查。使用 Aurora 或其他托管配置的部署，可能不符合公告列出的受影响画像；但运营团队仍应升级，因为软件包版本属于软件供应链的一部分，而服务器安全指南的适用范围也不只限于某一个利用前提。

MySQL 公告适用于 1.0.21 或更早版本的安装。由于该软件包常常通过版本范围或浮动的 latest 引用启动，团队不能从“配置现在能运行”推断实际运行的代码。应从真实客户端环境、容器镜像、锁定文件或部署产物中解析已安装版本，并记录结果，而不是只看配置文件中的软件包名称。

团队还应复核凭据的选择方式。AWS Labs 文档描述的连接可能使用 AWS 凭据发现数据库资源，并使用 Secrets Manager 凭据向数据库进行身份验证。因此，数据库连接型 MCP 服务器可能同时处于两套权限平面下：AWS IAM 权限和数据库权限。限制性的 IAM 角色不会自动让数据库登录变成只读；只读数据库角色也不会自动阻止 MCP 服务器在周边配置授予能力时读取敏感 AWS 元数据或本地文件。

当服务器运行在开发者工作站上，而工作站还保存源代码、云凭据、SSH 材料、构建产物或浏览器会话时，风险会更高。服务器通过网络暴露、由多人共享，或使用广泛的管理员凭据启动时，风险同样升高。AWS API MCP Server 文档虽然讨论的是相关软件包，但提醒其本地 STDIO 设计假定单一用户直接访问主机；文档还指出 IAM 仍是主要控制，并且只读分类并不保证命令输出无害。这些都是数据库 MCP 部署可借鉴的架构警示。

第一响应应当是清点，而不是猜测

处理这些公告时，运营人员不必先证明漏洞是否可利用。第一目标是确认易受影响的代码和权限条件是否存在。一份简短清单就能回答大部分高价值问题。

  • 找出所有 awslabs.postgres-mcp-server 和 awslabs.mysql-mcp-server 的安装，包括本地开发者配置、容器、CI 工作节点、共享跳板机和打包在 IDE 中的环境。
  • 为每个安装记录确切版本、启动方式、连接方式、数据库引擎以及数据库端点配置。
  • 将每个服务器使用的数据库用户或角色映射到其授权和成员关系。重点查看 PostgreSQL 超级用户状态、pg_execute_server_program、MySQL 管理权限、广泛的 schema 授权、存储过程执行权限，以及生产对象所有权。
  • 确定服务器仅限本地访问，还是可通过网络触达；并确认是否有多人或多个租户可以调用同一进程。
  • 检查服务器是否能够写入数据库、读取本地文件、调用云 API，或在工具输出中返回秘密信息。
  • 在修改环境前保存相关软件包清单、容器摘要、配置历史、身份验证日志、数据库审计记录和 MCP 客户端日志。

重点是建立事实画像。“我们使用 AI 助手”不足以评估这个问题。使用低权限报告角色连接自主管理 PostgreSQL 的场景，与开发者笔记本使用集群主凭据连接生产数据库，是完全不同的情况，即使两者运行的是同一个软件包名称。

升级，然后收紧权限

立即修复措施是升级到供应商修复版本：PostgreSQL MCP 服务器 1.1.7 或更高版本，MySQL MCP 服务器 1.0.23 或更高版本。要在真正负责启动服务器的机制中固定版本。如果配置使用 @latest、宽泛的软件包范围或未固定的容器标签，那么下一次更新可能更安全，但当前状态仍难以复现和审计。应使用锁定文件、不可变镜像摘要或等效的受控发布机制。

升级后，如果数据库权限超出任务所需范围，也要同步修改。对于报告工作流，专用角色通常只应访问所需数据库、schema、表、视图和少量明确批准的例程。PostgreSQL 文档与 AWS Labs README 都建议此类集成远离超级用户和服务器程序权限。一个只需读取已批准报告视图的角色，不应继承能够管理集群或在数据库主机上执行程序的角色。

MySQL 也是同样的原则。AWS Labs README 建议使用只拥有所需授权的专用账户，例如对相关数据库授予 SELECT，并且只对明确批准的过程授予 EXECUTE。文档还说明，服务器端过滤器的目标是捕获常见的变更语句，但无法保证覆盖每一种语法边界或未来的 SQL 功能。可靠的失败模式应当是数据库因缺少权限而报错，而不是助手自信地声称写入已被阻止。

不要试图用更复杂的提示词规则解决问题。提示词指令可以改善行为，但不是访问控制。引导文件、系统消息、批准列表和人工确认提示，在分层设计中都很有价值；但保护生产数据的唯一屏障不能是其中任何一项。用户或被注入的文档可能影响发送给模型的文本，模型也可能生成提示词作者没有预料到的请求。执行请求的账户仍必须无法超出预定范围。

单独检查 AWS 权限平面

有些团队会只盯着 SQL 过滤器，忽略 MCP 进程所使用的 AWS 权限。PostgreSQL README 表示，服务器可能使用 AWS profile 发现集群或实例；对于 RDS Data API 路径，可能还需要执行语句的权限。在文档所述配置中，它也会使用 Secrets Manager 获取数据库凭据。这些都是独立于数据库用户授权的决策。

为该进程使用专门构建的 IAM 角色或 profile。在 AWS 服务支持的地方限定资源范围，不要因为助手可能需要查看基础设施，就直接附加管理员策略。AWS 的 IAM 指南建议遵循最小权限原则；在可能的情况下为工作负载使用临时凭据；定期审查未使用的权限；并使用 IAM Access Analyzer 根据实际活动帮助细化策略。

还要记住，AWS API 层面的“只读”不等于“输出安全”。某些读取操作可能返回配置、标识符、策略文档或其他敏感材料。AWS API MCP Server 文档直接提醒了这一点。一个能够组合云端发现、秘密读取、数据库查询和本地文件操作的数据库助手，其实际权限远大于“SQL 只读”这几个字所暗示的范围。

在可能的情况下，应拆分这些功能。回答已批准数据相关问题的工具，不一定需要创建集群、修改网络控制、读取任意秘密或写入文件的权限。如果某个工作流确实需要这些能力，应将它们放到单独批准的工具和身份之后，而不是加到通用报告进程中。

审计是否使用过受影响版本

公告没有证明这些缺陷已经在野外被利用。围绕 CVE 的公开讨论不是事件证据，系统中存在易受攻击软件包也不是攻击者已经触达它的证据。但由于易受影响路径把用户可控内容连接到数据库执行面，检查日志仍然合理。

针对 PostgreSQL，应查看数据库日志和审计记录，寻找异常使用服务器端文件或程序功能、意外的角色变更、创建陌生函数、身份验证配置变化，以及 MCP 服务账户偏离正常查询模式的活动。检查数据库服务器上的主机遥测，关注无法由数据库工作负载解释的进程、文件、网络连接或持久化机制。防御性检测应停留在审计层面，不要把文章或事件工单变成重现命令执行的操作指南。

针对 MySQL，应检查本应被阻止却出现在审计日志中的语句、生产表的异常变更、管理权限或文件相关权限的使用，以及 MCP 账户在异常客户端或异常时间发起的连接。如果有记录，应将实际语句与生成这些语句的自然语言请求进行比对。两者不一致，可能暴露提示词注入、工具契约过宽、解析器问题或普通的模型错误。

CloudTrail 可以帮助调查 AWS 一侧，但不能取代数据库和主机遥测。应寻找异常的 Secrets Manager 读取、正常工作流之外的 RDS 或集群发现、IAM 或安全组变更，以及与 MCP 进程相关身份的异常访问。将 MCP 客户端、数据库、操作系统和云日志的时间戳相互关联。

如果证据表明存在未授权访问，应遵循组织的事件响应流程：隔离受影响进程，视情况轮换或撤销凭据，保存证据，并评估数据库与主机完整性。如果高权限凭据可能已经被使用，仅仅升级软件并不构成完整的事件响应。

这对 MCP 部署设计意味着什么

眼前的动作是升级软件包，但更广泛的教训在于：AI 集成应当位于架构中的什么位置。把自然语言转换为 SQL 的 MCP 服务器不只是一个便利适配器，它是放在人、模型、工具协议和有状态系统之间的解释器。每一层都可能改变请求，或为请求增加新的含义。

因此，需要采用在模型行为异常时仍然清晰可理解的控制。一个实用的部署会把只读分析与数据库运维访问分开，使用专为该集成创建的数据库角色，将角色限制在批准的对象范围内，并把生产写入放入要求独立身份和明确变更流程的工作流。若产品是为单用户 STDIO 操作设计的，则应让 MCP 服务器保持本地运行或置于等效隔离环境中；同时限制进程周围的主机权限、网络出口、秘密和文件系统访问。

还要让版本和配置具备可观测性。团队应能回答：运行的是哪个 MCP 软件包、使用了哪些参数、以哪个身份运行、连接了哪个数据库，以及哪次工具调用产生了每条查询。如果这些答案无法获得，漏洞公告就会引发一场关于“可能安装了什么”的漫长争论，而不是迅速做出修复决定。

测试应覆盖实际安全契约，而不只是验证一条顺利执行的查询。要确认普通读取请求能够工作，未授权写入会在数据库层失败，进程无法使用受限的服务器特权功能，错误会以拒绝方式处理，异常或畸形输入不会悄悄关闭策略。依赖升级和数据库引擎升级后都要重新测试。目标不是证明过滤器认识所有可能的 SQL 写法，而是证明不受信任的请求无法让身份超出其被允许的结果范围。

实际结论

AWS 9 月 9 日的公告再次说明，“只读”是一个必须在多个位置实施的设计声明。PostgreSQL 问题尤其需要关注这样的环境：旧版本软件包通过 wire protocol 连接到自主管理服务器，而使用的角色是超级用户或拥有 pg_execute_server_program。MySQL 问题则影响较旧的软件包版本，也说明对文本过滤器看似无害的 SQL 语法，仍然可能产生实际影响。

凡是存在这两个软件包的地方，都应完成升级。清点真实启动版本和连接方式；用范围狭窄的角色替换高权限数据库账户；复核 MCP 进程周围的 IAM profile、秘密访问权、主机权限和网络暴露；再结合数据库、主机及云日志，判断受影响安装只是存在漏洞，还是已经被滥用。

持久有效的建议很简单，但落实需要工作：让数据库执行数据库边界。把模型指令和 SQL 过滤器当作边界周围有帮助的防护层，而不要把它们当成边界本身。

来源