AWS MCP 沙箱失守：从四层 Python 限制到系统命令执行

沙箱设计：四层限制与 MCP 安全测试的摩擦

AWS 把 MCP Server 的 GA 定在 2026 年 5 月 6 日，这是一个托管的远程 Model Context Protocol 服务器，让 AI agent 能调用 AWS API 来源：xplo1t-sec。核心工具叫 `aws___run_script`，接受一段短 Python 脚本作为参数，在服务器端的 AWS Lambda 沙箱里执行。设计意图是让 agent 把多个 AWS API 调用、过滤和结果处理打包在一次请求里完成，省掉来回发好几个单独调用的开销。 沙箱设了四道限，分别卡住 imports、builtins、attribute access 和 file operations 来源：xplo1t-sec。做这个安全研究的作者是 xplo1t-sec，文章发表于 2026 年 10 月 24 日，标注阅读时长 11 分钟 来源：xplo1t-sec。研究是他跟 Claude Opus 4.6 协作完成的。 安全测试本身也带来了摩擦。作者在文章里提到，通常把 MCP server 接到 Cursor 或其他 agent 上做测试会增加摩擦，因为 payload 要过一遍 AI agent 才能触发工具调用，payload 一开始还行，后来变得太乱之后就成了痛苦 来源：xplo1t-sec。他干脆写了一个 Python CLI 当 MCP client，用 mcp-proxy-for-aws 签本地 AWS 凭据来请求，然后在测试账号里建了一个权限受限的 IAM user 做评估。

反直觉漏洞：属性读取藏在模式匹配里，三步逃逸链直达命令执行

整个研究的核心漏洞叫做 "Attribute Reads Hidden in a Pattern"，翻译过来就是属性读取藏在模式里。沙箱对 attribute access 的限制可以通过模式匹配中隐藏的属性读取来绕过 来源：xplo1t-sec。这个发现有点反直觉，因为模式匹配本身是 Python 语言层面的语法结构，不在沙箱显式拦截的范围内。 逃逸链分三步走。先从受限环境中恢复一个真实可用的函数引用，再通过代理机制补全调用链，最后确认在 Lambda 环境内拿到系统命令执行能力 来源：xplo1t-sec。文章末尾附了 Vulnerability Disclosure Timeline，说明走了负责任披露流程。 仅靠限制 imports、builtins、attribute access、file operations 这四样东西不足以阻止逃逸。这是 xplo1t-sec 从实验中得出的判断，我没有独立验证，但从他的描述来看逻辑是通顺的。Lambda 沙箱的安全边界比 AWS 官方暗示的要薄。

多源交叉验证：受影响工具链与社区关注度错位

受影响的 AI 编码助手有三款：Claude Code、Kiro 和 Cursor，都通过 AWS MCP Server 接入 来源：xplo1t-sec。AWS 把 MCP Server 定位为 "managed" 安全托管服务，而 xplo1t-sec 的实验证明其沙箱可以被攻破 来源：xplo1t-sec。 我去看了 HN 上的讨论情况，截至抓取时只有 1 个点赞、0 条评论 来源：HN。一个能打通到 Lambda 内系统命令执行的沙箱逃逸，在 Hacker News 上只有这个热度。定位上是 11 分钟阅读量的技术博客，走的是工程实操路子。这种社区关注度与漏洞严重性的错位让我有点意外。 研究范式也变了。xplo1t-sec 用 Claude Opus 4.6 当协作工具来挖漏洞，AI 在这里充当的是研究员的搭档 来源：xplo1t-sec。研究成果以 11 分钟技术博客的形式发布，定位偏工程实操。

---

原文：

Breaking the AWS MCP Python Sandbox · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月27日