CVE-2026-85654 深度解读：DynamoDB MCP Server 如何把数据模型风险带到 CDK 部署宿主

系列位置：基础篇第 35 篇
调研日期：2026-09-05
关键词：CVE-2026-85654 · DynamoDB MCP Server · MCP · CDK · IaC · 代码注入 · Agent 安全 · 生产准入

30 秒摘要

AWS 于 2026-09-04 发布安全公告：开源组件 awslabs.dynamodb-mcp-server 的 CDK generator 存在代码注入问题。受影响版本为 2.0.10 至 2.1.5，包含两端 ；问题已在 2.1.6 修复。

官方给出的精确条件是：在特定情况下，上下文相关行为者可在 data model 文件的 table、index 或 attribute 名称中放入未被正确中和的特殊元素；当后续流程生成并部署应用时，可能在执行部署的宿主上运行任意代码。它不是 Amazon DynamoDB 托管服务被攻破，也不是一个无需前置条件、可从互联网直接触发的远程代码执行漏洞。

这次事件真正值得工程团队关注的，是一条经常被忽略的转换链：

数据模型 → 模板渲染 → CDK/应用代码 → 构建与部署 → 宿主执行

只要团队把"模型文件"当成普通数据、把"生成代码"当成可信输出，并让生成与部署共享生产凭据，一处模板边界缺陷就可能越过多层控制。因此，升级 2.1.6 只是第一步；完整生产门还应包括资产盘点、版本锁定、输入约束、隔离生成、生成物审查、最小 IAM、受限出网、fork 补丁、canary 和宿主级回退。

一、先把漏洞边界说准确

|--------|-----------------------------------------------|-------------------------------|
| 项目 | AWS 已确认的事实 | 不能据此推出的结论 |
| 影响组件 | awslabs.dynamodb-mcp-server 的 CDK generator | 不是 DynamoDB 服务端控制面或数据面漏洞 |
| 影响版本 | >= 2.0.10 且 <= 2.1.5 | 不能只检查直接依赖声明而忽略锁文件、镜像和缓存中的实际版本 |
| 输入位置 | data model 文件中的 table、index、attribute 名称 | 不表示任意一次普通查询都会触发 |
| 结果 | 特定条件下，可在部署生成应用的宿主执行任意代码 | 不是无交互、无上下文要求的互联网远程 RCE |
| 修复版本 | 2.1.6 | 不能据此宣称所有 MCP、模板或 CDK 风险已经消失 |
| 临时措施 | 人工审查 dynamodb_data_model.json，不使用不可信来源的模型文件 | 人工浏览文件不是长期替代升级的补偿控制 |

AWS 将公告标为需要关注的安全通告，但没有在该公告中给出 CVSS，也没有声明已发现现实攻击。本文不补写分数，不推测利用规模，更不提供构造输入或利用 payload。

"上下文相关行为者"也需要谨慎理解：官方没有把它等同于匿名互联网攻击者。工程上可以把风险来源建模为可能影响 data model 的人员、自动化、Agent 上下文或上游文件，但这是为了设计防线，不是对攻击来源的额外事实认定。

二、攻击路径不在 DynamoDB，而在"数据升格为代码"

通常，团队会认为 table、index、attribute 名称只是结构化元数据。问题在于，CDK generator 需要把这些名称填入模板，生成可继续执行、构建或部署的代码。数据一旦跨过模板边界，它的安全属性就发生了变化。

人员 / Agent / 上游工具
        │
        ▼
dynamodb_data_model.json
  table / index / attribute 名
        │  输入未被充分约束
        ▼
CDK generator 模板渲染
        │
        ▼
生成的应用或 IaC 代码
        │  被当作可信构建输入
        ▼
依赖安装 / 合成 / 部署
        │
        ▼
部署宿主执行
  ├─ 工作区与缓存
  ├─ CI 身份和临时凭据
  ├─ 制品仓库写权限
  └─ AWS 部署角色可达资源

这里至少有三次信任跃迁：

1. 模型文件从外部输入变成生成器参数。
2. 生成器输出从文本变成可执行代码。
3. 代码从审查对象变成拥有云权限的部署任务。

如果三步都在同一台长期 runner 上完成，并复用同一个高权限角色，那么最后一道部署权限会反向放大最前面的输入缺陷。反之，即使生成器出现问题，只要生成阶段没有生产凭据、生成物必须经过差异审查、部署阶段重新取得受限身份，攻击链就会被拆断。

三、第一道门：资产盘点、升级与锁版

不要只在主仓库搜索一行版本声明。MCP Server 可能存在于开发者本机、Agent 基础镜像、CI 工具镜像、内部模板仓库、临时实验环境和上游 fork 中。真正要回答的是"哪个可执行环境最终解析并运行了哪个版本"。

建议建立以下盘点表：

|--------------|-------------------------------|-------------------------|
| 资产 | 应记录的证据 | 准入要求 |
| Agent/MCP 配置 | server 名称、启动命令、工作目录、owner | 不允许指向未知或用户可写的全局环境 |
| 锁文件与环境 | 解析后的包版本、依赖锁摘要 | 最低修复版本 2.1.6，并锁定到已测试结果 |
| 容器/runner | 镜像 digest、构建日期、SBOM | 重建镜像，不能只在运行容器中临时升级 |
| CI 工作流 | 调用生成器的 job、权限、网络和 artifact 流向 | 生成与部署必须是不同安全域 |
| fork/衍生代码 | 上游基线、补丁 commit、内部版本 | 明确合入修复，不能以改名或 fork 状态豁免 |

生产环境应把 2.1.6 视为最低修复线，并按官方建议升级到最新可用修复版本；具体采用哪个版本，仍需经过兼容性验证并写入不可变锁文件或镜像摘要。若声明已升级，但旧基础镜像、缓存虚拟环境或自托管 runner 仍能调用 2.1.5，准入并未完成。

无法立即升级时，只能把 AWS 的临时建议当作短期例外：人工检查 dynamodb_data_model.json，且不接收不可信或未经验证来源的模型文件。例外必须有 owner、工单、到期日和禁止进入生产部署的范围，不能长期依赖"值班同学看一眼"。

四、第二道门：把生成与部署拆成两个安全域

最有效的架构变化，是不让 CDK generator 所在阶段持有生产部署能力。

受控 data model
      │
      ▼
隔离生成 job
  - 无生产 AWS 凭据
  - 临时工作区
  - 默认禁止出网
  - 仅输出生成物
      │
      ▼
Artifact Gate
  - 输入 schema/名称策略
  - 规范化 diff
  - SAST/secret/依赖检查
  - 人工或双人审批
      │
      ▼
独立部署 job
  - 重新拉取已批准 artifact
  - 重新取得短期 IAM 身份
  - 先生成 change set
  - 只触达批准范围

生成 job 不应继承部署 job 的环境变量、凭据目录或共享主机缓存。最好使用一次性 runner；任务结束即销毁工作区。若确实需要拉取依赖，应按仓库和域名设置出网 allowlist，并记录请求，而不是允许任意外连。

部署 job 只接受带摘要的批准制品，不重新运行生成器，也不从聊天附件、临时分支或未经验证的对象存储位置读取 data model。审批之后任何字节变化，都必须令旧批准失效。

五、输入校验与生成物 review 必须同时存在

只修模板转义而完全信任输入，或只限制名称而不看生成代码，都不够稳健。

输入门：名称不是任意字符串

团队可以为 table、index、attribute 名定义比服务上限更严格的内部规则：允许字符集、长度、前后缀、保留词、环境标记与重复名称检查。重点不是猜测某一种攻击字符串，而是把自由文本压缩为业务确实需要的名称空间。

校验结果应绑定 data model 的 SHA-256，并写入构建证据。文件发生变化就重新校验，不能让 Agent 在校验后继续改写同一路径。

生成物门：审查真正将被部署的代码

生成代码不是"机器产物所以无需 review"。流水线应保存生成前后的规范化差异，并至少执行：

• 解析或编译检查；
• SAST 与危险 API 规则；
• secret 和高熵内容扫描；
• 新增依赖与生命周期脚本检查；
• CDK synth 输出和 CloudFormation change set 审查；
• 与已批准 data model 摘要的关联校验。

SAST 没有告警不等于生成物安全。它只是证据之一；异常的新文件、命令执行路径、网络访问、构建脚本或超出数据模型意图的基础设施变化，都应阻断发布并转人工调查。

六、第三道门：最小 IAM 与最小出网

即使生成物通过 review，部署身份也不应拥有账户级管理员权限。最小权限需要同时限制四个维度：

# 团队策略意图示意，不是可直接部署的 IAM/CDK 配置
deployment_gate:
  identity: short-lived-oidc-role
  account: approved-account-only
  region: ap-southeast-1
  resources: approved-stack-prefix
  actions: reviewed-deployment-actions
  session:
    duration: short
    tags:
      change_id: required
      artifact_sha256: required
  network:
    egress: allowlist

CDK/CloudFormation 部署有时需要较宽的创建权限，因此更要分离 bootstrap、合成、变更集查看和正式执行角色。服务角色、权限边界、SCP 与资源标签应共同限制爆炸半径，不能因为"CDK 很方便"就长期使用 AdministratorAccess。

生成阶段原则上不需要生产 AWS 写权限。部署阶段也不应携带与目标无关的代码托管、制品发布或其他云账号密钥。出网应只允许必要的 AWS API、制品仓库与审计端点；异常 DNS、HTTP 请求和新目的地必须可观测、可阻断。

七、fork 与内部衍生版本不能漏补

AWS 明确建议 fork 或衍生代码合入修复。企业最容易漏掉的恰恰是"我们没直接用官方包，而是内部改过"。

对 fork 应建立单独门禁：

1. 记录 fork 基于哪个上游 commit 或版本。
2. 定位 2.1.6 对应修复并完成差异审查。
3. 为 table、index、attribute 名边界添加回归测试，但不在公开日志保存攻击样本。
4. 重建内部包和基础镜像，生成新 SBOM。
5. 撤销旧制品的生产准入，而不是只发布一个新标签。
6. 扫描其他复用相同模板辅助函数的生成器。

"已经 cherry-pick"不是充分证据；最终二进制、包摘要、镜像 digest 和回归结果必须能关联到补丁。

八、canary 与回退要覆盖宿主，而不只覆盖 CloudFormation Stack

升级后先在非生产环境运行一份已知正常的 data model，验证生成结果、synth 差异、部署权限和审计链，再选择一个低风险 stack 做 canary。观察至少包括：生成物是否稳定、是否出现意外文件或依赖、出网是否符合基线、IAM 是否有额外拒绝、CloudFormation change set 是否只包含预期资源。

回退也要分两层：

• 应用/基础设施层：停止执行 change set，回滚 stack，恢复上一份已批准 artifact。
• 部署宿主层：若怀疑旧版本曾处理不可信模型，不能只回滚 stack；应隔离并销毁临时 runner，轮换或撤销其可用凭据，清理缓存，检查审计和出网记录，再从可信镜像重建。

原因很直接：公告描述的执行位置是部署生成应用的宿主。任意代码若已在宿主阶段运行，CloudFormation 回滚并不能自动撤销宿主上的副作用。

扩大灰度前应满足：

[ ] 所有运行点已解析到修复版本
[ ] 生成 job 无生产凭据
[ ] data model 与生成 artifact 均有不可变摘要
[ ] review、SAST、synth、change set 全部关联同一 artifact
[ ] 部署角色只覆盖目标账户、区域、stack 与动作
[ ] canary 无异常文件、依赖、出网和权限请求
[ ] runner 销毁、凭据撤销与 stack 回滚均已演练

九、六个常见误区

1. "这是 DynamoDB 被入侵。" 错。公告指向开源 DynamoDB MCP Server 的 CDK generator，不是托管服务漏洞。
2. "升级后不用再审生成代码。" 错。2.1.6 修复本次问题，不替代生成式 IaC 的长期审查。
3. "模型文件是 JSON，所以只是数据。" 错。进入模板并产出可执行代码后，它已跨越数据---代码边界。
4. "没有 CVSS 就不紧急。" 错。优先级应结合组件版本、输入来源、宿主权限和部署频率判断，不能虚构分数，也不能因缺少分数忽略暴露面。
5. "CloudFormation 能回滚，所以宿主也安全。" 错。宿主执行发生在 stack 之外时，需要 runner、凭据和缓存级处置。
6. "内部 fork 不受影响。" 错。若保留同类缺陷，改包名不会消除风险；AWS 也明确要求衍生代码同步修复。

结语

CVE-2026-85654 的价值，不只在于提醒团队升级一个 MCP Server。它把 Agent 工程里最危险却最容易被忽略的链条具体化了：模型文件看似是数据，模板让它进入代码，CDK 让代码接近云控制面，部署宿主再把本地执行能力与云身份叠在一起。

可靠的生产门应让每次信任升级都留下证据：输入受约束，生成环境无生产钥匙，生成物可审查，部署身份最小化，网络目的地受限，fork 有补丁追踪，canary 和回退覆盖宿主。这样，即使下一次问题不再出现在同一个字段或模板中，攻击链也难以一次跨完所有边界。当天其余浏览器、模型与开发平台变化可从 《计算机每日时报（2026-09-05）》 继续追踪。

官方来源与事实边界

1. AWS Security Bulletin 2026-097-AWS：CVE-2026-85654：发布日期、影响版本、触发条件、宿主执行边界、2.1.6 修复与临时缓解措施。
2. awslabs/mcp 官方仓库：DynamoDB MCP Server 的官方开源代码、版本演进与衍生代码核对入口。