2026 年 4 月 20 日，Vercel——Next.js 的母公司，也是現代網路上最被廣泛使用的雲端部署平台之一——公開承認攻擊者入侵了內部系統並竊取客戶資料。到了 4 月 21 日，一個自稱 ShinyHunters 的威脅行為者正在以 200 萬美元叫價兜售這批資料。
最初的媒體報導把它描述成典型的雲端資安事件。不是。Vercel 這起事件，是全球第一個被公開確認的重大案例：一款 AI 生產力工具被武器化，成為攻擊一家雲端基礎設施服務商的入口。全世界所有資安團隊都應該把這份事後報告讀一遍。
用白話說一遍攻擊路徑
攻擊者走過的路，正常到近乎電影化。一位 Context.ai 的員工下載了一個 Roblox 遊戲外掛。外掛裡帶著 Lumma Stealer，一種會竊取瀏覽器 session、cookie 與已儲存憑證的資訊竊取惡意軟體。從那位 Context.ai 員工的機器開始，攻擊者取得了 Context.ai 用來整合企業客戶——包括 Vercel——的 OAuth token。
在更早的某個時間點，Vercel 至少有一位員工用自己的 Vercel Google Workspace 帳號註冊了 Context.ai 的「AI Office Suite」，並在 OAuth 同意畫面上點了「允許全部」。那一下點擊——當時感覺不過就是讓 AI 工具順利運作的一點摩擦——給了 Context.ai 讀取該員工 Google Workspace、郵件、文件以及所有外接第三方服務的權限。
當攻擊者接管那位員工的 Google 帳號時，他們也繼承了那份同意。從 Vercel 的 Google Workspace 內部，他們橫向移動進入 Vercel 的內部環境，把沒有被標為「敏感」的環境變數拉了出來，從中抽出可用的 Supabase、Datadog 與 Authkit 憑證。Vercel 真正標為敏感的環境變數仍然加密完好，但「不敏感」的那些，結果包含了足以造成實際損害的金鑰。
為什麼這是一種新型態的入侵
供應鏈攻擊我們見過。SolarWinds、3CX、CircleCI 路徑大致相同：入侵供應商，順著信任關係進入客戶。Vercel 事件真正新的地方，是「供應商的形狀」。
Context.ai 不是建置系統，也不是 IT 監控代理，它是一款 AI 生產力工具。它的 OAuth 範圍設計上就是要讀取一切，因為 AI 要「在你所有工作場景中幫忙」。這份讀取範圍一旦被滲透，就剛好是攻擊者想要的：廣泛、無差別、長期有效的企業 Google Workspace 存取權。傳統的 SaaS 資安審查流程，是針對範圍狹窄、用途明確的工具設計的，它並沒有被調整來處理那種「價值主張就是廣泛存取」的工具。
這正是資安研究者過去兩年一直在警告的 OAuth 風險。Vercel 事件是這個風險第一次在大規模、公開、且以整個開發者生態圈都熟悉的公司身上兌現。
「非敏感」環境變數的迷思
另一個比較安靜、但一樣重要的教訓是：被標為「非敏感」的環境變數，實際上並不非敏感。Vercel 這個案例中，攻擊者從平台自家分類器標為安全的環境變數裡，拉出了可用的憑證。
我工作過的每一個工程組織，幾乎都有這個毛病的某種版本。API 金鑰漏進 debug 設定、服務 URL 裡嵌了 token、「測試環境」的憑證結果有生產環境權限。你配置面板上的標籤只是一個標籤，它不會強制現實。
我的觀點
Vercel 事件會在未來幾年的資安簡報裡被反覆講述，但它常會被講錯。簡單的敘事是「一個員工下載 Roblox 外掛就害死了大型雲端商」。這種敘事讓受害者看起來草率，解法看起來很簡單：好好訓練員工就好。更困難、但也更真實的敘事是：現代 AI 工具在結構上與企業 OAuth 模型並不相容，而任何使用者訓練都修不了一個被設計成「用最大權限換最大幫助」的同意畫面。
接下來三十天裡，每一個工程組織都應該做三件具體的事。第一，稽核企業 Google Workspace 與 Microsoft 365 租戶裡所有「允許全部」的 OAuth 授權，並撤銷所有沒有明確業務用途的授權。第二，不要再相信部署平台上的「敏感」標籤意味著「加密」——把每一個環境變數都當成潛在憑證來審查。第三，為 AI 生產力工具制定一份與一般 SaaS 政策不同的政策，因為威脅模型不一樣。
如果什麼都不做，Vercel 不會是這種形狀事件裡的最後一個，它會是後面一長串裡的第一個。