亚马逊 MCP 网关注册表中的标识符位 SQL 注入

这是什么？

2026 年 7 月 6 日，亚马逊为 mcp-gateway-registry 发布了一份安全公告。该项目是面向 Model Context Protocol（MCP）服务器的开源网关与注册表，集中管理发现、认证与授权，并为 AI 代理和编码助手代理 MCP 工具——实际上是位于代理与其调用工具之间的控制平面。公告描述了指标服务保留策略组件中的一个已认证 SQL 注入。该缺陷归类为 CWE-89，CVSS 评分为 8.1（v3.1）/ 8.6（v4.0），均为高危，并已在 1.0.13 版本中修复。这是一个已披露并已修补的漏洞；下文为防御性分析，不复现任何可用的攻击代码。

工作原理

保留策略管理代码允许调用者指定某项策略应用于哪张指标表。这个由调用者提供的 table_name 值被插入到 SQL 语句的标识符位置——即表名或列名所在之处——而未经适当净化。受影响的版本为 1.0.3 至 1.0.12。

微妙之处在于为何常规防御在此不起作用。参数化查询——针对 SQL 注入的标准解药——仅在值位置绑定不可信输入：

# 安全：值被绑定，绝不被解析为 SQL
cursor.execute("SELECT * FROM metrics WHERE day = %s", (user_day,))

# 不安全：标识符无法被绑定，因此被字符串拼接进去
cursor.execute(f"DELETE FROM {table_name} WHERE ts < now() - interval '30 days'")

大多数数据库驱动都不为表名或列名提供占位符，因此开发者转而使用字符串格式化——而保留逻辑天然会遍历一组表名，正是该模式出现的经典位置。由于注入的文本被解析为查询结构的一部分而非数据，已认证的远程用户便可跳出预期的标识符，对指标数据库执行任意 SQL。根据公告，这包括读取已存储的数据——乃至 API 密钥材料——以及删除或篡改存储的记录。

为何重要

普通 Web 应用中的 SQL 注入泄露的是数据行。同样的缺陷出现在 MCP 网关中，泄露的却是授权代理访问下游工具的凭据材料。这与 2026 年整波 AI 基础设施缺陷所揭示的教训一致，包括 LiteLLM 代理的预认证注入：网关是一级凭据面，因为它们聚合了原本分处不同边界之后的秘密。

有两个细节抬高了实际风险。首先，在代理生态中，「已认证」是比人类场景更低的门槛：这类网关服务于众多代理身份、服务账户和令牌，其中任何一个都可能是那个已认证的调用者。其次，注入触及的存储——按公告自身的描述——可能保存密钥材料。此处的读取原语可级联到这些密钥所解锁的系统，从而将单一组件的缺陷放大为多工具的沦陷。

防御

1.0.13 中的修复是正确的范式，其通用教训适用于任何从名称构建 SQL 的服务：

• 对标识符使用白名单。 将 table_name 与一组固定且已知的指标表进行校验，拒绝其余一切。切勿将调用者输入插入标识符位置，即便已做转义。
• 不要指望参数绑定能覆盖标识符。 占位符保护的是值，而非表名或列名。若名称必须动态，应通过查找映射实现，而非字符串格式化。
• 最小权限的数据库账户。 指标服务应以只能触及指标表的角色连接——而非包含凭据或配置的表——从而使注入无法向秘密横向移动。
• 将秘密与遥测数据分离。 不要将 API 密钥材料与指标数据放在一起，并对静态秘密加密，使对一个存储的读取无法交出另一个。
• 限制并审计管理面。 以强授权保护保留策略管理，并记录其使用。
• 升级并轮换。 升级至 1.0.13 或更高版本。任何运行过受影响版本、且可被不可信的已认证身份访问的实例，都应轮换其存储的密钥并复核其指标数据的完整性。

状态

项目	详情	状态
参考	CVE-2026-14471（GHSA-79qc-vqfr-xx5q）	公开
受影响版本	1.0.3 – 1.0.12	已确认
修复版本	1.0.13	可用
公告发布	2026 年 7 月 6 日	公开（AWS）
严重性	CVSS 8.1 v3.1 / 8.6 v4.0，CWE-89	高
临时缓解	无——须升级	—

结论狭窄却可复用：参数化查询是必要的，但并不充分。凡是代理平台允许调用者指定表、列或排序字段名之处，该名称都需要一份白名单——因为标识符永远无法被安全地绑定，只能被校验。