Vercel CEO：攻擊者目標已超Context.ai正系統性竊取雲平臺密鑰
Vercel 首席執行官 Guillermo Rauch 在最新安全通報中表示，公司已完成一輪“深入安全調查”，分析範圍覆蓋近 1 PB 的 Vercel 網絡與 API 日誌，遠超最初由 Context.ai 賬戶入侵引發的內部系統訪問事件。 調查結果顯示，相關攻擊者並非只針對單一 Context.ai 賬戶，而是在更大範圍分發信息竊取類惡意軟件，系統性蒐集包括 Vercel 在內多家雲與開發平臺的賬戶密鑰；一旦獲取密鑰，攻擊者會快速而全面地枚舉所有未標記爲敏感的環境變量，以便進一步橫向移動與擴大訪問範圍。
Rauch 表示，目前 Vercel 已與 Microsoft、AWS、Wiz 等安全與雲服務夥伴深化協作，共享攻擊指標與入侵路徑情報，以保護更大範圍的互聯網開發生態，並已主動通知其他疑似受影響的機構和個人，建議立即輪換 API 密鑰、OAuth 令牌與數據庫憑證，並嚴格區分、加密和標記敏感環境變量，強化零信任與最小權限等安全實踐。
來源：公開信息
ABAB AI 解讀
這次事件的重要性，已經遠遠超出“Vercel 被黑一次”本身，而是暴露了一條完整的“AI 工具→OAuth→雲環境→環境變量→全網擴散”的現代攻擊鏈。攻擊最初來自 Context.ai 用戶側終端被 Lumma Stealer 類惡意軟件感染，竊取了 Google Workspace 與各類 SaaS 憑證；隨後利用 OAuth 授權接管 Vercel 員工賬戶，再從中枚舉未標記爲敏感的環境變量，進而獲取更多雲平臺、代碼倉庫與數據庫的訪問密鑰。 這一鏈條說明，在“到處接第三方 AI/SaaS 工具”的時代，企業的安全邊界正在被用戶側 OAuth 權限與瀏覽器擴展徹底重寫。
從結構上看，攻擊者並沒有先去碰最硬的“加密存儲”，而是優先撿“未標記爲敏感的環境變量”這類軟肋——這些變量往往被開發團隊視作“不那麼重要”，卻在現實中包含了足夠多的 API key、訪問令牌與內部系統地址，可以作爲進一步滲透的跳板。 這暴露的是現代雲開發模式的一個系統性問題：環境變量已經成爲事實上的祕密分發層，但管理和分級策略遠遠落後於其真實敏感性，一旦被高權限賬號訪問，攻擊者就相當於拿到了一份跨雲、跨服務的“鑰匙清單”。
Rauch 強調與 Microsoft、AWS、Wiz 等夥伴協同，本質上是在承認：單一平臺級廠商已經無法獨立應對這種“多雲、多 SaaS、跨 AI 工具”的供應鏈攻擊。攻擊者利用被攻陷的 OAuth 應用和瀏覽器擴展，橫跨多家雲廠商與開發工具，這迫使雲服務商、安全廠商與大型 SaaS 建立更高頻的威脅情報共享與聯合響應機制。 對整個開發者生態而言，這意味着安全基線將被抬升：從簡單的“輪換密鑰”，升級到系統排查第三方 OAuth 授權、瀏覽器擴展以及 AI 工具接入策略，把“能訪問部署和代碼的所有外部應用”當成潛在供應鏈風險來管理。
從更長的技術週期看，這起 Vercel–Context.ai 事件是“AI 工具融入開發流程”後的第一批大規模教訓之一。開發者爲提高效率，把越來越多敏感工作流程（代碼、部署、日誌、工單）接入第三方 AI 產品，而這些產品自身往往運行在更鬆散的安全環境下；一旦其中某一個環節被攻破，攻擊者就能沿着 OAuth 和 API 權限一路向上爬，直達生產環境。 這迫使整個行業重新評估“AI+SaaS 提效”的真實成本：未來真正成熟的做法，必然是在“能幫你寫代碼和看日誌”的工具和“能控制你部署和密鑰的權限”之間畫出更清晰的牆，把安全邊界重新從“企業網絡”移動到“每一段授權與每一個環境變量”的粒度上。