Stripe 秘密金鑰是 API 憑證,不只是帳戶識別碼。它實際能做什麼,取決於金鑰權限與商戶帳戶設定;但只要憑證遭到竊取,就可能被用來讀取商戶資源,甚至進行未授權的付款操作。
報導中的測試顯示,一把仍有效的金鑰就能用於:
真正棘手之處在於速度:伺服器端秘密一旦外洩,企業可能在察覺異常前,就已經從單純的秘密管理失誤,演變成即時的付款詐騙與事件調查。
換句話說,目前證據較支持「攻擊者取得商戶持有的有效憑證,再透過 Stripe 的合法 API 讀取資料」,而非 Stripe 核心系統遭到入侵。可能的憑證外洩途徑包括:
.env 檔案與伺服器設定Hudson Rock 的相關報告將另一批論壇發布資料歸因於同一名行為者。該批資料據稱包含 669 個供應商資料夾與 1,033 把遭入侵的 API 金鑰,宣稱容量為 33 GB;但相關下載檔案據報小於這個數字。行為者另聲稱手上還有約 20,000 把遭入侵的 Stripe API 金鑰,並暗示未來可能發布更多批次。
這些數字不應直接相加,或合併成一個已確認的總量。659 個商戶帳戶、669 個供應商資料夾與 1,033 把金鑰之間的差異,可能來自不同資料集、同一帳戶擁有多把金鑰、重複資料,或不同的計算方式。至於 20,000 把金鑰,仍只是行為者未經驗證的說法。
現有報導列出的主要所在地包括:
撤銷並重新建立所有可能出現在原始碼、日誌、備份、端點遙測資料、容器映像或公開基礎設施中的即時秘密金鑰。不要等到發現詐騙活動後,才處理可能已經外洩的憑證。
檢查 API 和安全性日誌,尋找不熟悉的呼叫、新建立的付款連結、測試或未授權扣款、異常退款、權限變更,以及不尋常的來源 IP 位址。保留相關日誌,以便建立事件時間線。
確認出款設定、已連結的銀行帳戶資料與出款目的地。若發現可疑變更,應依照企業適用的事件應變與通報程序,盡快聯絡 Stripe 及相關金融機構。
為每項服務使用僅涵蓋必要 API 操作的受限金鑰。生產環境、開發環境與營運角色應彼此分離,避免把同一把高權限秘密散布到多個應用程式。
檢查目前與歷史儲存庫、Git 歷史、CI/CD 輸出、GitHub Actions 日誌、.env 檔案、容器映像層、雲端儲存、文件與備份中的 sk_live 值。即使該金鑰已不在目前版本的程式碼中,只要曾經出現,也應撤銷並重新建立。
GitHub 表示,公開儲存庫會自動執行秘密掃描;組織擁有的私有與內部儲存庫,則需要在符合資格的方案中啟用 GitHub Secret Protection。 但掃描無法找回已被複製到日誌、備份、端點遙測資料或已下載檔案中的秘密。因此,企業仍需要集中式秘密管理、較短的憑證有效期、權限控管與持續監控,讓秘密掃描成為其中一層,而不是完整的防護方案。