小編精選 - 技術文章翻譯 · 04月25日

如果你的專案受到 Vercel 資安外洩事件影響，該怎麼做

Vercel 證實於 2026 年 4 月 19 日發生了一起影響客戶環境變數的安全事件。以下是用簡單易懂的語言解釋事件經過、您是否受到影響以及保護帳戶的具體步驟。無需任何安全專業知識。

簡而言之： 2026 年 4 月 19 日，Vercel 揭露了一起安全事件。攻擊者攻破了名為 Context.ai 的第三方 AI 工具，並利用該權限控制了一名 Vercel 員工的 Google Workspace 帳戶，也存取了未標記為「敏感」的環境變數。如果您在 Vercel 上部署了服務（尤其是您的 API 金鑰、資料庫 URL 或令牌未明確標記為敏感），則需要輪流使用它們。本指南將按步驟詳細介紹特定操作方法，無需任何安全背景知識。

如果您在 Vercel 上部署了任何應用程式，那麼您很可能已經被入侵了！

在過去48小時裡，你可能已經關注了相關新聞，並感受到了一種淡淡的恐慌，不知所措。簡而言之，答案是肯定的，你最好採取行動。而本指南旨在提供更詳細的解答：所需的操作其實很簡單，耗時不多，而且無需你具備DevOps工程師或安全研究員的專業知識。

本文是一份面向開發者、獨立創始人、小型團隊以及所有在 Vercel 上建置或曾經建置過應用，現在想知道“輪換密鑰”究竟是什麼意思的人的實用指南。讓我們從實際發生的情況開始。

Vercel 漏洞事件始末（簡單易懂版）

2026年4月19日，Vercel發布安全公告，揭露攻擊者已入侵其部分內部系統。但攻擊並非始於Vercel，而是從規模較小的公司發起，而這正是整個故事最引人入勝之處。

以下是此次安全漏洞實際發生的詳細步驟：

一位Vercel員工使用其Vercel Google Workspace帳號註冊了一款名為Context.ai的生產力工具，這是一款由人工智慧驅動的辦公室套件。註冊時，他們授予該應用程式存取其Google帳戶的廣泛權限。

Context.ai 本身也遭到了攻擊。根據CyberScoop 報告，最初的感染始於 2026 年 2 月，當時一名 Context.ai 員工在搜尋 Roblox 遊戲漏洞時，其電腦感染了 Lumma Stealer 惡意軟體。該惡意軟體竊取了包括 OAuth 令牌在內的憑證。

攻擊者利用被盜的 OAuth 令牌入侵了 Vercel 員工的 Google Workspace 帳戶。這完全繞過了多重身份驗證，因為一旦頒發了 OAuth 令牌，就不需要重新驗證。

攻擊者利用該Google帳號橫向入侵了Vercel的內部系統：管理工具、問題追蹤系統和內部環境。一旦進入系統，他們就能讀取Vercel控制面板中未標記為「敏感」的客戶環境變數。

一名自稱是 ShinyHunters 組織成員的威脅行為者在網路犯罪論壇上發帖，試圖以 200 萬美元的價格出售被盜資料。 Vercel 已聯繫 Mandiant、CrowdStrike 和執法部門進行調查。

大多數人忽略的關鍵細節是：這與Vercel缺乏安全感無關。

Vercel 會對靜態儲存的敏感環境變數進行加密，這些變數已被證實是安全的。這次洩漏的是一些未明確標記為敏感的變數，這意味著攻擊者一旦入侵系統，就可以讀取這些明文值。如果您曾經在未勾選敏感標記的情況下向 Vercel 加入 API 金鑰、資料庫 URL 或令牌，那麼這些資訊可能已經落入不法分子之手。

我是否受到Vercel資料外洩事件的影響？

簡而言之：你可能沒事，但要做好最壞的打算並採取相應的措施。

Vercel公司表示，這起資料外洩事件僅影響了“部分客戶”，並表示已直接聯繫了這些客戶。如果您尚未收到Vercel公司關於此事的電子郵件，則您可能不在已確認受影響的客戶群中。

但是——這一點很重要——無論如何，出於以下兩個原因，您應該將您的憑證視為可能已洩露：

調查仍在進行中。 Vercel表示，他們“將繼續調查是否以及哪些資料被竊取”，如果出現更多證據，將會聯繫客戶。

OAuth信任鏈非常深。根據趨勢科技的技術分析，這次攻擊利用了2024年6月左右頒發的OAuth令牌，並且直到2026年4月才被發現，這意味著在披露之前，攻擊者可能已經存取了系統數月之久。

實用原則：如果您在 Vercel 中設定了未明確標記為「敏感」且包含真實憑證的環境變數，請務必輪換這些變數。輪換的成本很低，而不輪換已洩漏的密鑰則可能造成災難性後果。

如何立即保護您的Vercel帳戶安全（按順序）

以下是今天需要採取的行動，按優先順序排列。如果您完成了前四項，就已規避了 80% 的風險。

1. 開啟 Vercel，找出所有未標記為「敏感」的環境變數。

前往 Vercel 控制面板，開啟每個專案，並查看「環境變數」標籤。任何未設定“敏感”標誌的變數都應視為已暴露。

Vercel 也推出了儀錶板更新，提供了一個概覽頁面，顯示所有專案中的環境變數。使用它可以更快地進行審計。

2. 如何安全輪換鑰匙

這一步最容易讓人出錯。輪換憑證意味著在頒發憑證的服務端產生一個新的憑證，然後更新 Vercel 以使用新憑證。不要直接刪除 Vercel 中的變數，就想當然地認為舊憑證已失效或停用。在您明確撤銷之前，它在服務端仍然有效。

運算順序：

登入頒發憑證的服務（AWS、OpenAI、Supabase、GitHub、Stripe 等）。
產生新密鑰
使用新值更新 Vercel 環境變數
這次將變數標記為「敏感」。
重新部署專案以取得新值
返回發卡機構並撤銷舊密鑰。

3. 依爆炸半徑排序

您可能擁有數十個憑證。請根據它們解鎖的功能，按以下順序輪換使用：

一級（關鍵）：雲端提供者金鑰（AWS 存取金鑰、GCP 服務帳戶、Azure 令牌）、資料庫憑證（Supabase 服務角色金鑰、Postgres URL、MongoDB 連線字串）、付款金鑰（Stripe、支付處理器）、原始碼控制權杖（GitHub PAT、部署金鑰）。

二級（高）：第三方 SaaS API 金鑰（OpenAI、Anthropic、Firecrawl、SendGrid、Resend、分析工具）、電子郵件簽署金鑰、webhook 金鑰。

3 級（中）：內部服務令牌、功能標誌、非憑證配置值。

理由如下：Stripe 金鑰落入不法分子手中可能導致帳戶資金被盜，而功能標誌值則不會。請據此進行分類處理。

4. 檢查活動日誌，查看是否有任何可疑之處。

在每個服務中，查看過去 30 天的存取日誌。您需要尋找以下內容：

來自您無法辨識的 IP 位址的 API 呼叫
來自團隊成員不在家的國家的活動
建立或刪除未經您授權的資源
您未新增的新 Webhook、部署金鑰或 OAuth 應用程式

對於 AWS，請查看CloudTrail 。對於 GCP，請查看審計日誌。對於 GitHub，請查看組織審計日誌。對於 Vercel 本身，請查看控制面板中的活動日誌。

5. 撤銷與您的 Google 或 Microsoft 帳戶關聯的任何第三方 AI 或 SaaS 應用程式。

這是導致此次安全漏洞的具體途徑。請前往“Google 帳戶”→“安全性”→“與第三方應用的連接”，並檢查所有擁有存取權限的應用程式。撤銷任何您不再使用的應用，尤其是那些擁有廣泛權限的應用（「允許所有權限」是一個危險信號）。

如果您使用 Microsoft 365，請對 Microsoft 365 執行相同的操作；對於您的 GitHub 帳戶的 OAuth 應用程式，也請執行相同的操作。

6. 為 Vercel（以及其他重要的地方）啟用密碼或身份驗證器應用程式

Vercel 支援密碼金鑰和驗證器應用的多因素身份驗證 (MFA)。如果您仍在使用基於簡訊的雙重認證 (2FA)，則安全性較低。簡訊驗證碼可能會被 SIM 卡替換而失效。硬體金鑰或身份驗證器應用顯然更勝一籌。

這並不能保護你免受基於 OAuth 令牌的攻擊（這就是這裡發生的事情），但它會提高其他所有類型攻擊的成本。

7. 今後所有新的環境變數都應使用「敏感」標誌。

今後，請將「敏感」標誌視為必填項，而非可選項。根據Vercel 的文件，敏感變數在靜態儲存時會進行加密，設定後無法透過控制面板讀取。這正是此次洩漏事件中暴露的變數所缺乏的保護。

Vercel 還宣布他們正在更新預設設置，使新變數自動敏感，但在該功能推出之前，請手動操作。

即使你沒有直接被擊中，這仍然很重要

這則新聞之所以得到廣泛報道，包括TechCrunch 、 The Hacker News 、 Help Net Security 、Hacker News 首頁等，顯示這種攻擊模式是未來攻擊的範本。

此次安全漏洞利用了現代軟體團隊將各種第三方工具連接到其身分提供者這一事實，而每一次連接都可能成為安全漏洞的途徑。

同樣的攻擊模式可以針對任何平台。本案例中的受害者使用的是 Context.ai，這是一個人工智慧生產力工具。下個月，受害者可能就會使用其他人工智慧工具、筆記應用程式或日曆插件。如果您的團隊中有任何員工使用其公司 Google 或 Microsoft 帳戶向某個小型第三方應用程式授予了廣泛的 OAuth 權限，那麼您就面臨著與 Vercel 相同的安全風險。

確保系統安全的最佳實踐

這種防守姿態與多年來的最佳實踐相同，但大多數球隊並沒有嚴格執行：

將所有第三方 OAuth 應用程式視為潛在攻擊者
僅授予應用程式正常運作所需的最小權限，切勿「允許所有權限」。
每季審核並撤銷未使用的應用程式連接
定期輪換憑證。生產密鑰至少每 90 天輪換一次，高風險密鑰至少每 30 天輪換一次。
始終對靜態資料進行加密。將所有憑證標記為敏感資訊。
監控存取日誌，查看是否有你未執行的操作。

Ozigi如何應對Vercel資料外洩事件（因為我們也受到了影響）

簡單說明一下，因為我們的 Ozigi 部署在 Vercel 平台上。是的，我們也是受影響的客戶之一。以下是我們揭露資訊後 24 小時內採取的措施，大致與上述步驟一致：

我們輪換了Vercel環境中的所有憑證，首先是Supabase服務角色密鑰、Google Cloud Vertex AI憑證和Dodo Payments密鑰。現在所有這些憑證都被標記為敏感資訊。

我們審查了 Google Workspace 連接，並撤銷了所有不再使用的第三方應用程式，包括兩個我們忘記已連接的應用程式。

我們檢查了 Supabase、Vercel 和 GCP 上的活動日誌，尋找異常情況。目前尚未發現任何可疑之處，但我們會繼續監控。

我們正在將有效期較長的憑證遷移到Doppler中進行集中管理和自動輪換，而不是直接在 Vercel 的控制面板中進行管理。

和許多小型團隊一樣，我們的安全態勢不夠嚴密。

說實話，大多數小型團隊之所以沒有在金鑰管理上投入足夠的資源，正是因為他們覺得「這件事還沒發生」。而這次事件促使他們開始著手解決這個問題。

常見問題解答

如果鑰匙已經被偷了，輪換使用鑰匙真的有用嗎？

是的，而且這是你能做的最重要的事。被盜憑證只有在有效期間才有價值。一旦你在來源服務上輪調並撤銷舊金鑰，被盜憑證就失效了。你每等一個小時，攻擊者就可能利用它一個小時。

Vercel 中的「標記為敏感資訊」是什麼意思？

這是一個針對每個環境變數的標誌，它指示 Vercel 對靜態值進行加密，以防止透過控制面板或 API 讀取該值。一旦標記為敏感，您可以更新或刪除該變數，但無法查看其當前值。正是這個標誌阻止了這次資料外洩事件中受影響變數的讀取。

我需要旋轉所有按鍵，還是只需要旋轉 Vercel 上的所有按鍵？

首先關注 Vercel。儲存在其他地方（例如單獨的金鑰管理員、不同的託管平台或本機.env檔案中）的金鑰不受此事件影響。儘管如此，這也提醒我們應該全面檢查憑證的安全性——許多團隊發現他們已經多年沒有輪換核心憑證了。

我現在應該多久輪換一次 API 金鑰？

行業標準是生產密鑰每 30-90 天更新一次，具體取決於敏感程度。支付和雲端服務提供者金鑰的更新週期應接近 30 天。第三方 SaaS 金鑰的更新周期可達 90 天。內部服務令牌理想情況下應該是有效期較短的憑證，其生存時間 (TTL) 為 1-24 小時，並由 HashiCorp Vault 等工具動態產生。

有沒有什麼工具可以自動完成這個動作？

是的，有好幾種選擇。 Doppler 和Infisical對小型團隊和個人創辦人來說最容易上手。 HashiCorp Vault和AWS Secrets Manager是企業級選項，但設定成本更高。 GitGuardian會掃描你的程式碼倉庫，尋找暴露的金鑰，並且可以觸發自動輪調工作流程。

OAuth令牌和API金鑰有什麼差別？

API 金鑰是一種靜態憑證，只需產生一次即可直接使用。 OAuth 令牌由身分提供者（例如 Google、Microsoft）在使用者授權第三方應用程式後頒發，代表對該使用者帳戶的授權存取權限。 Vercel 資料外洩事件正是利用了 OAuth 令牌。由於 OAuth 令牌一旦頒發無需重新驗證，攻擊者便可繞過多因素身份驗證 (MFA)。

我應該停止使用人工智慧生產力工具嗎？

不，但你應該仔細審核它們。問題不在於人工智慧工具本身，而是任何獲得企業身分系統廣泛權限的第三方應用程式。對待日曆插件、CRM整合或分析連接器，也要像對待人工智慧工具一樣進行嚴格審查。

如何知道我的帳號資訊是否在暗網上出售？

你通常不會直接察覺。一些服務（例如 GitHub 和 AWS）具有自動監控功能，如果洩漏的憑證出現在已知來源中，就會被標記出來。像Have I Been Pwned 這樣的工具會監控電子郵件地址，而像Hudson Rock這樣的企業安全工具則會追蹤被資訊竊取者盜用的憑證。對於小型團隊來說，坦白說，最好的方法是主動輪換帳戶並做好最壞的打算，而不是事後才去檢測。