然而,这种方法只是调用了 libc 的 unsetenv,并没有将留在进程堆内存中的字节清零 。
研究人员通过读取 /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 发布令牌。该令牌在构建过程中通过 Dockerfile 的 ARG 指令被传入,而这个指令会被永久序列化到镜像的不可变 history[] 字段中。这意味着,任何能够拉取该镜像的人都可以恢复此令牌 。
恢复的 NPM 令牌包含了三个关键属性:action: write、name: null 和 bypass_2fa: true。这种组合赋予了攻击者对关联 NPM 账户所能发布的所有包的写入权限,包括 zapier-platform-core、zapier-platform-cli 和 zapier-design-system 等关键包 。
其中 bypass_2fa: true 这个设置意味着,任何发布操作都无需经过双重认证,这实际上为所有关联的 NPM 注册表包赋予了不受限制的写入权限 。
在整个攻击链中,最关键的包是 zapier-design-system,它会在 zapier.com 的每个已认证会话中加载。研究人员通过浏览器的开发者工具验证了这一加载路径,并在此处停止了行动——他们并未发布恶意包 。
如果一个攻击者发布了一个被植入恶意代码的版本,那么在下一个版本发布时,它将在已认证的 zapier.com 来源中执行攻击者控制的 JavaScript。从那个位置出发,攻击者可以代表已认证用户创建 Zaps、Tables 和 MCP 服务器,并通过平台驱动已有的集成服务。需要注意的是,已连接服务的 OAuth 令牌和 API 密钥保存在服务器端,浏览器无法直接接触,但即便如此,其对业务运营造成的破坏性影响也可能是极其严重的 。
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 团队管理着一个具有写入权限的令牌;前端团队加载着一个设计系统包。每一个决策单独看来都是合理的,但将这五个系统串联起来的结果,却是灾难性的 。
这充分说明,身份和访问权限的审查必须追踪跨越系统边界的攻击路径,而不是孤立地审计每个组件的权限。组织需要进行跨团队的安全审查,审视那些看似无害的配置如何在系统交互时,组合成危险的攻击链 。