「Zapocalypse」攻击链：五个已知反模式如何组成灾难性的软件供应链漏洞

研究人员通过读取 /proc/self/mem 文件，并针对可读内存区域运行了四个正则表达式模式，成功恢复了 Lambda 的 IAM 角色所使用的实时 AWS STS 会话令牌，完全绕过了沙箱 。

第二阶段：利用最小权限枚举容器镜像仓库

恢复的 AWS 角色名为 allow_nothing_role，但这个名称颇具误导性。这个角色实际上被授予了四项 Elastic Container Registry（ECR，即亚马逊云服务中的容器镜像仓库）的权限：ecr:DescribeRepositories、ecr:ListImages、ecr:BatchGetImage 和 ecr:GetDownloadUrlForLayer 。

这四项权限足以让人直接通过 AWS API 拉取容器镜像，而无需任何 Docker 注册表的认证令牌。利用这些权限，研究人员成功枚举了 1,111 个生产环境代码仓库，并通过层获取 API 拉取了容器镜像 。

第三阶段：从容器镜像历史中恢复 NPM 令牌

在其中一个被拉取的容器镜像中，研究人员发现了一个泄露到容器配置历史中的 NPM 发布令牌。该令牌在构建过程中通过 Dockerfile 的 ARG 指令被传入，而这个指令会被永久序列化到镜像的不可变 history[] 字段中。这意味着，任何能够拉取该镜像的人都可以恢复此令牌 。

第四阶段：获得绕过双重认证的 NPM 发布权限

恢复的 NPM 令牌包含了三个关键属性：

action: write

name: null

bypass_2fa: true

其中

bypass_2fa: true

第五阶段：潜在的供应链立足点与浏览器代码执行

在整个攻击链中，最关键的包是 zapier-design-system，它会在 zapier.com 的每个已认证会话中加载。研究人员通过浏览器的开发者工具验证了这一加载路径，并在此处停止了行动——他们并未发布恶意包 。

如果一个攻击者发布了一个被植入恶意代码的版本，那么在下一个版本发布时，它将在已认证的 zapier.com 来源中执行攻击者控制的 JavaScript。从那个位置出发，攻击者可以代表已认证用户创建 Zaps、Tables 和 MCP 服务器，并通过平台驱动已有的集成服务。需要注意的是，已连接服务的 OAuth 令牌和 API 密钥保存在服务器端，浏览器无法直接接触，但即便如此，其对业务运营造成的破坏性影响也可能是极其严重的 。

Zapier 的响应时间线

Token Security 于 2026 年 2 月 12 日 提交了漏洞报告。仅仅四天之内，Zapier 就完成了报告的初步分类，撤销了泄露的 NPM 令牌，并收紧了底层的 AWS 角色权限。到 2026 年 3 月 5 日，修复工作被确认为全面完成。Zapier 表示，未发现任何证据表明该漏洞已在野外被利用 。

研究人员获得了该漏洞赏金项目的最高奖金 3,000 美元，Zapier 也承诺会在下一次项目审查时重新评估赏金上限 。

值得一提的是，这项研究披露与 2025 年 11 月 24 日发生的一起真实的供应链攻击事件是相互独立的。在那次事件中，一个名为 Shai Hulud 2.0 的蠕虫病毒入侵了 Zapier 的 NPM 账户，并感染了 425 个包 。

更广泛的教训：组合漏洞落在团队间隙

Token Security 的安全研究团队负责人 Yair Balilti 阐述了核心发现：

“链条中的每一个环节都是一种已知的模式。漏洞在于组合，而组合恰恰是落在团队与团队之间的事情。Lambda 沙箱、ECR 和 IAM、GitLab CI 令牌、NPM 发布、浏览器——每一个都由不同的团队负责，每个团队都可以审视自己的那一部分，并合理得出‘没问题’的结论。只有当你追踪一条跨越所有这些部分的路径时，风险才会显现。”

这里的关键启示是，没有任何一个单独的团队造成了独立的漏洞。Lambda 沙箱团队认为内存搜寻不是问题，因为令牌本来就不该在作用域内；IAM 团队看到的是一个权限仅限于只读操作的 ECR 角色；CI/构建团队把 NPM 令牌作为构建过程的环境变量传入；NPM 团队管理着一个具有写入权限的令牌；前端团队加载着一个设计系统包。每一个决策单独看来都是合理的，但将这五个系统串联起来的结果，却是灾难性的 。

这充分说明，身份和访问权限的审查必须追踪跨越系统边界的攻击路径，而不是孤立地审计每个组件的权限。组织需要进行跨团队的安全审查，审视那些看似无害的配置如何在系统交互时，组合成危险的攻击链 。