CVE-2026-18953：AWS 的 Transform MCP 服务器缺少写入边界

Amazon 于 2026 年 8 月 5 日发布了安全公告 2026-075-AWS，涉及 CVE-2026-18953，这是路径遍历漏洞，位于 get_resource 工具中，该工具属于 awslabs.aws-transform-mcp-server，这是一个开源 Model Context Protocol 服务器，运行在开发者自己的机器上，以便 AI 助手驱动 AWS Transform 作业并检索其产物。版本 0.1.0 至 0.1.4 未充分限制路径名，而 savePath 参数可能将文件写入预期工作目录之外——Amazon 仓库中的 GitHub 公告称这“可能导致本地代码执行”。Amazon 将其评为 8.6，高危。修复版本是 0.1.5，且不存在仅服务端或仅配置的变通方法，因为易受攻击的代码路径存在于默认配置中。没有公开来源记录有人利用过该漏洞。完整记录及其严重性和置信度评级位于 Orca AI Incident Archive，与同一月份归档的 MCP 和智能体运行时事件并列。

一个能在开发者工作之处进行写入的 MCP 服务器

模型上下文协议服务器是为助手提供可调用工具的那一层，而这一款被刻意设计为本地运行。亚马逊的公告将其描述为"一个开源 MCP 服务器，它在开发者机器上本地运行，让 AI 驱动的助手能够与 AWS Transform 交互，以运行代码转换作业并获取其产物。"它在 Python 包索引上的包描述称，该服务器通过 19 个工具公开 Transform 生命周期，管理转换工作区、作业、连接器、人在回路任务、产物和聊天，并涵盖大型机现代化、VMware 迁移、.NET 现代化以及自定义代码转换。

这种位置安排正是该缺陷之所以重要的原因。运行在供应商自有基础设施上的服务器如果对文件名处理不当，损坏的是供应商的存储。而这一台是以开发者身份、在开发者的主目录中运行的，紧挨着他们的 shell 配置和 SSH 密钥，而且 Amazon 所描述的影响并非下载文件损坏，而是“本地代码执行”。附加在该 CVE 上的每一个评分都在一点上达成一致：攻击向量是本地性的，而非网络性的。

公告中提到的这个工具负责把作业产物下载到磁盘。get_resource接收一个savePath，用于指定文件应写入的位置。该缺陷在于，没有任何机制阻止这个路径指向别处。

有多糟，又是按谁的计算方式？

此 CVE 附有三个评分，且它们并不一致。Amazon 作为编号机构分配了该 CVE，在 CVSS v3.1 上给它评分为 8.6（High），其向量为 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H——本地、低复杂度、无需权限、需要用户交互、范围已改变，对机密性、完整性和可用性影响高。NIST 在 National Vulnerability Database 中的条目带有其自己的 v3.1 主要评分 8.8，基于不同的向量，CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H：需要低权限、无需用户交互。两者都落在 High 区间。分歧在于前提条件——行为者是否已经需要立足点，以及是否需要有人被说服——而不在于结果有多严重。

对于同一 CVE，Amazon 的 CVSS v4.0 评分为 6.3，中等，依据为 CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H。解读影响指标：易受攻击系统本身没有任何影响，而后续系统上的所有影响均为高。这就是一种突破工具自身边界的遍历所具有的形态——损害作用于工具所能触及的任何对象，因此它落在子系统列，而易受攻击系统的得分为零。

CISA 于 2026 年 8 月 6 日对该 CVE 所作的富化记录给出了 SSVC 判定：利用情况：无，可自动化：否，技术影响：完全。NVD 的记录最后修改于 2026 年 10 月 23 日，仍同时并列保留 8.6 与 8.8 两个评分。两份文档均未认定对方有误。

有漏洞的代码做了什么，以及 0.1.5 改变了什么

亚马逊对该机制的描述只有一句话，而且措辞谨慎：该工具“未能充分限制路径名”，这可能使“一个依赖情境的行为者”能够通过 savePath 参数“在预期的工作目录之外写入任意文件”。该安全公告没有界定这个行动者，没有说明是什么触发了写入，也没有描述成功的利用会是什么样子。它只表示结果“可能导致本地代码执行”。

关于该机制最详细的公开说明并非出自亚马逊。它来自一个小型概念验证仓库，ronamosa/CVE-2026-18953，该仓库于2026年8月8日以Apache-2.0许可发布在GitHub上——截至撰写时仅有两次提交，没有星标也没有复刻——其中原样收录了存在漏洞和已修补的file_validation.py，并用相同的输入驱动两者。

它对 0.1.4 的解读如下：validate_write_path()解析了savePath使用realpath和expanduser，拒绝了一份简短的位置拒绝名单（~/.aws、~/.ssh、~/.gnupg、~/.docker、~/.aws-transform-mcp、/etc/shadow、/etc/passwd），并从提供的文件名中剥离了目录组件。它从未将解析后的路径限制在任何基础目录或工作目录内。一份敏感文件名黑名单——.bashrc、.zshrc、authorized_keys、id_rsa——在读取时强制执行，但在写入时未强制执行。

该仓库演示了该机制允许的三种写入：一个完全不需要路径遍历的绝对路径、一个相对的 ../../ 逃逸，以及一个读取路径原本会拒绝的点文件名。这三种写入都落在脚本创建的临时目录内，其示例输出显示 dropped_by_absolute_path.sh、dropped_by_traversal.sh 和一个 .bashrc 位于诱饵主目录下；真实主目录从未被触及。0.1.5 版本增加了缺失的边界：一个取自 $AWS_TRANSFORM_MCP_WRITE_DIR 或服务器启动工作目录的基准目录，每个解析后的写入都必须位于其下，此外还将文件名黑名单应用于最终解析后的写入路径。修复后的验证器会对这三种情况均抛出“Write path must be within the working directory”。

这些细节均未出现在安全公告中，仓库也未声称它们来自该公告。应将拒绝列表、只读文件名检查和基础目录修复视为根据源代码进行的还原，而非第二个官方发现。仓库在公告之外确实补充的，是对谁能够提供该路径的说明：由于服务器的工作是将作业和任务内容拉入助手的上下文，选择savePath的一方不必是坐在键盘前的人。一个受其通过同一工具获取的不可信内容所引导的助手也能作出这一决定。这是仓库依据代码和工具设计提出的论点，而非亚马逊提出的主张；亚马逊未定义的“依赖上下文的行为主体”与此一致，并且仅止于此。

补丁与公告之间相隔七周

修复并未随公告一同到来。Python Package Index 的发布历史——来自该软件包所发布注册表的第一方元数据——显示 0.1.4 的日期为 2026 年 5 月 20 日，0.1.5 为 2026 年 6 月 17 日，比 2026 年 8 月 5 日发布的公告 2026-075 早了七周。索引中根本没有 0.1.0 文件；受影响范围内最早发布的构件是 0.1.1，于 2026 年 5 月 9 日上传。因此，从该索引安装的开发者只可能在 5 月 9 日至 6 月 17 日期间获得存在漏洞的构建版本，而任何跟踪发布动态的人到 6 月中旬时都已经在使用已修补的代码。

Amazon 并未说明它何时得知该问题、报告何时送达，也未说明为何发布那个了结此事的版本。记录中唯一被点名的人是 Drew Raines，公告和 GitHub 安全通告都感谢他“通过协调式问题披露流程就这一问题展开协作”。GHSA-66mr-jr63-2jgw 于 2026 年 8 月 5 日发布在 Amazon 的 awslabs/mcp 仓库中，与公告同日发布；CVE 记录于当日 13:44 UTC 预留，并于 19:33 UTC 发布。

因此，修复的日期已经确定，而修复的原因却没有。一个补丁版本在公告发布整整七周之前就已存在于软件包仓库中，这与“悄悄修复、随后进行协调披露”的做法相符——但这只是根据两个时间戳作出的推断，两份文件都没有说明这一点。

记录确立了什么，以及没有确立什么

档案库将该条目评为 A 级——文档记录充分，一手来源一致——且未将其标记为有争议。它将其归档为一项研究记录，即一项漏洞发现，而非部署事故，且没有记录在案的现实世界危害。该评级关乎文档的质量，而根据已审查的证据，该评级成立：公告、GitHub 安全公告和 CVE 记录是三份由 Amazon 发布的文件，它们在产品、版本、修复方案和致谢方面保持一致。

• 已确认。Amazon 于 2026 年 8 月 5 日发布了公告 2026-075-AWS，涉及 CVE-2026-18953，这是一处 CWE-22 路径遍历，位于 get_resource 的 savePath 处理逻辑中（存在于 awslabs.aws-transform-mcp-server 0.1.0 至 0.1.4 中），已在 0.1.5 中修复；由于存在漏洞的路径位于默认配置中，因此没有服务端或仅配置层面的变通方案。

• 已确定。各项评分及其差异：Amazon 作为 CVE 编号机构给出的 8.6 高危，NIST 作为 NVD 主要评分给出的 8.8 高危，CVSS v4.0 的 6.3 中危，以及 CISA 于 8 月 6 日作出的 SSVC 决定，即未观察到利用活动，也未发现可自动化路径。

• 已确认。Python Package Index 上的发布日期，以及致谢 Drew Raines 的协调披露。

• 由第三方根据源代码推断。拒绝列表、只读文件名阻止列表、缺失的基础目录以及 _ALLOWED_WRITE_BASE 修复均来自 ronamosa 概念验证仓库，任何人都可以对比其中随附的两个验证器版本副本。

• 根据时间戳和设计推断。即 0.1.5 是一次有意发布的安全版本，且受不可信内容引导的助手可能提供恶意路径。Amazon 对这两点均未说明。

• 尚未确定。 是否存在任何野外利用。CISA 的“Exploitation: none”（利用情况：无）标注日期为 8 月 6 日，比公开的概念验证出现早两天，因此它只反映当时的情况，不代表此后任何情况。尚未公布受影响用户数量、客户通知或遥测数据。

• 尚未确定。独立报道。似乎没有主流媒体对此 CVE 进行过报道。公开记录包括亚马逊的三份文档、NIST 和 CISA 对这些文档的补充、重述该记录的各跟踪页面，以及上文所述的那个小型概念验证仓库。

发生了什么变化，以及需要检查什么

亚马逊的补救办法只是把版本号往上提，别无其他：升级到 0.1.5 或更高版本，并“确保任何分支代码或衍生代码都已打上补丁以纳入新的修复”。真正会向外传播的正是第二个分句。该服务器是开源的，而一个内置了 0.1.4 版校验器的分支，在继承这一缺陷的同时并不会继承这份公告；该公告要求衍生代码的运营方把这一变更带入自己的代码中，也就是说，上游的发布版本并不会自动抵达由他人维护的副本。

概念验证仓库提出了安全公告拒绝提出的建议。它称，无法立即升级的运维人员应让服务器在将其工作目录设为专用空目录的情况下运行，并将服务器能够写入的任何文件都视为已失陷。Amazon 的立场更为严格：根本不存在任何服务器端或仅靠配置的变通办法。按照该仓库自己的说法，这一建议也缺乏说服力，因为易受攻击的代码从一开始就从未将写入限制在工作目录内。在两者不一致之处，以厂商仅限升级的指示为准。

这条记录有价值的地方不在于它的评分，而在于它的形态：一个本地 MCP 服务器，一次由调用方指定目标位置的工件下载，以及两者之间没有边界。真正重要的检查不是公告日期，而是锁定版本——0.1.5 或更高，并且同样的改动要带入任何复制了该验证器的派生分支。