Zapocalypse 漏洞鏈：當五個「合理」的設計缺陷聯手，就能摧毀軟體供應鏈安全

第二階段：用最小權限列舉 ECR

還原出來的 AWS 角色名為 allow_nothing_role，名字聽起來無害，實際上卻具備四項 Amazon Elastic Container Registry（ECR）權限：ecr:DescribeRepositories、ecr:ListImages、ecr:BatchGetImage 與 ecr:GetDownloadUrlForLayer 。

這四項權限已足夠透過 AWS API 直接拉取容器映像檔，完全不需要 Docker 登錄驗證令牌。研究人員利用這些權限，列舉出 1,111 個生產環境的儲存庫，並透過映像層 API 拉取了其中多個映像 。

第三階段：從容器映像歷史紀錄挖出 NPM 令牌

在其中一個拉取的容器映像裡，研究人員發現一組 NPM 發布令牌（publish token）外洩在該容器的組態歷史紀錄中。該令牌是透過 Dockerfile 的 ARG 指令傳入建置流程的，這會讓參數永久序列化（serialize）在映像檔不可變的 history[] 欄位中。這意味著任何能拉取該映像的人，都能還原這組令牌 。

第四階段：取得 NPM 發布權限並繞過雙重驗證

這組外洩的 NPM 令牌具備三項致命屬性：

action: write

name: null

bypass_2fa: true

特別值得注意的是

bypass_2fa: true

第五階段：潛在的供應鏈立足點與瀏覽器端程式碼執行

整條鏈中影響最關鍵的套件是 zapier-design-system。這個套件會在 zapier.com 每一個已登入的工作階段中載入。研究人員透過瀏覽器開發者工具確認了這條載入路徑，並在這一階段煞車——他們沒有釋出任何惡意套件 。

假如攻擊者發布了一個遭到竄改的版本，下一次版本釋出時，惡意的 JavaScript 就會在已登入的 zapier.com 原始環境中執行。從這個立足點出發，攻擊者可以建立 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 團隊管理了一組具寫入權的令牌；瀏覽器端團隊載入了一個設計系統套件。每一項決策單獨來看都算合理，但串聯五個系統後，後果是災難性的 。

這項案例說明，身分與存取權審查必須跨越系統邊界來追溯攻擊路徑，而非孤立地稽核每個元件的權限。組織需要進行跨團隊的安全審查，檢視那些看似無害的組態，在系統與系統互動時會如何組合成危險的攻擊鏈 。