Stripe商戶API密鑰外洩：659個商戶帳戶、約68.8萬名客戶資料被公開

這宗事件較準確的理解，不是「Stripe平台被黑」，而是大量商戶自行保管的API憑證疑遭取得，再被用來透過Stripe的正常API讀取資料。據報，2026年8月18日，一名使用「Satanic」化名的威脅行動者在網上資料交易論壇免費公開一個約35GB的壓縮檔，內含17,654個檔案，涉及659個商戶帳戶，以及估計688,363名、來自42個國家的客戶資料。上述規模屬報道及研究估算，部分較大的聲稱仍未獲獨立核實。

資料庫內據報有甚麼

相關資料據報涵蓋2022年1月至2026年6月的紀錄，包括：

• Stripe客戶物件及客戶聯絡資料
• Charges、Payment Intents、Checkout Sessions、發票、退款及爭議交易
• 出款紀錄及餘額交易
• 訂閱、產品及價格資料
• 付款相關metadata，例如卡種、卡號末四位、有效期、資金類型、發卡國家及付款指紋

目前報道沒有顯示資料庫含有完整卡號，因此未必能直接進行某些形式的信用卡盜用。不過，API憑證連同詳細客戶及交易資料一旦外洩，仍足以造成嚴重的資料私隱及付款濫用風險。

研究人員據報在資料中發現650條有效的 sk_live 秘密密鑰及9條受限密鑰。在受影響帳戶中，573個可以收款、531個具備出款能力，519個同時具備收款及出款能力。

一條有效密鑰，點解已經可以好大鑊？

Stripe秘密密鑰並不是普通的識別碼，而是API憑證。它實際可以做甚麼，取決於密鑰權限及商戶帳戶設定；但一旦伺服器端密鑰落入他人手上，攻擊者可能直接接觸商戶的Stripe資源，甚至進行未經授權的付款操作。

報道所引述的測試顯示，單是一條仍然有效的密鑰，已可用來：

• 讀取客戶名單
• 建立欺詐性付款連結
• 進行測試扣款

潛在後果包括大量查詢及收集客戶資料、濫用付款功能、未經授權退款、針對性釣魚，以及利用付款紀錄進行社交工程。具備出款權限的帳戶，亦需要額外核查出款設定及收款銀行資料是否曾被更改。

最實際的問題是速度：一條外洩的伺服器端密鑰，可以令一次秘密管理失誤，在商戶察覺異常之前，已經演變成即時的詐騙及事故應變事件。

點解研究人員認為唔似Stripe核心系統被入侵？

現有證據顯示，攻擊者較可能使用有效的商戶憑證，透過合法Stripe API讀取資料。研究人員離線檢視公開檔案後表示，當中的Stripe格式物件及資料夾結構，與透過API端點匯出的資料相符；在檢視過程中，他們沒有使用外洩密鑰登入，也沒有進入受影響商戶的實時環境。

因此，控制失效點較可能位於商戶保存或處理秘密的位置，而不是Stripe的核心基礎設施。可能的外洩途徑包括：

• 開發人員或管理員裝置感染資訊竊取程式（infostealer）
• 公開程式碼庫及歷史Git資料
• 外露的 .env 檔案及伺服器設定
• 雲端儲存、備份及容器映像檔
• CI/CD系統及GitHub Actions記錄
• 設定錯誤的伺服器，或針對外露環境變數的自動掃描

不過，659個商戶憑證最初究竟由哪條途徑被盜取，目前仍未確定。以上是合理的可能來源，並非已證實所有資料都來自同一個初始入侵點。

另一宗相關公開事件，數字唔可以直接相加

Hudson Rock的報告將另一宗論壇資料公開事件歸因於同一名行動者。該批資料據報包括669個供應商資料夾及1,033條被入侵API密鑰，論壇標示容量為33GB，但相關下載檔案據報只有較小容量。行動者另外聲稱手上仍有約20,000條被入侵Stripe API密鑰，並暗示日後可能再公開其他批次。

這些數字不應被合併成一個已獲確認的總數。659個商戶帳戶、669個供應商資料夾及1,033條密鑰之間的差異，可能與不同資料集、同一帳戶持有多條密鑰，或不同統計方法有關。至於「20,000條」密鑰，仍然只是行動者未經證實的聲稱。

哪些地方的商戶較多？

現有報道列出的主要受影響地區包括：

• 美國：212個商戶
• 英國：81個
• 法國：57個
• 加拿大：38個
• 巴西：30個
• 澳洲：27個

這些數字反映目前報道所見的商戶分布，不能視為整個資料集的最終地理範圍，因為事件規模仍在評估中。

使用Stripe的企業而家要做甚麼？

1. 即刻輪換所有可能外洩的有效密鑰

撤銷並重新建立所有可能出現在原始碼、日誌、備份、端點遙測資料、容器映像檔或公開基礎設施中的有效秘密密鑰。不要等到發現可疑交易，先至處理可能已外洩的憑證。

2. 審查API及付款活動

檢查API和安全日誌，留意不熟悉的API呼叫、新建立的付款連結、測試或未授權扣款、異常退款、權限變更，以及來自可疑IP位址的活動。同時保留相關日誌，方便建立完整時間線及進行取證。

3. 核實出款設定

逐一檢查出款設定、已連接的銀行帳戶資料及出款目的地。如發現可疑變更，應盡快聯絡Stripe及相關金融機構，並按照適用的事故應變及通報程序處理。

4. 用受限密鑰取代過度寬鬆的憑證

為每個服務使用只具備必要API操作權限的受限密鑰。生產環境、開發環境及不同操作角色應分開管理，避免多個應用程式共用一條權限過大的秘密密鑰。

5. 搜查所有可能長期留低秘密的地方

搜尋目前及歷史程式碼庫、Git歷史、CI/CD輸出、GitHub Actions日誌、.env檔案、容器層、雲端儲存、技術文件及備份中的 sk_live 字串。任何被發現的憑證都應撤銷及更換，即使它已經不在目前版本的程式碼內。

6. 唔好以為GitHub掃描就包晒

GitHub表示，公開程式碼庫會自動進行Secret Scanning；但由組織擁有的私人及內部程式碼庫，則要在符合資格的方案上啟用GitHub Secret Protection。 更重要的是，掃描無法處理已經複製到日誌、備份、端點遙測資料，或已被下載的檔案中的秘密。因此，Secret Scanning只能作為其中一層防線，不能取代集中式秘密管理、較短的憑證有效期、存取控制及持續監察。

商戶最應記住的一課

現有報道沒有證實Stripe基礎設施被入侵，但事件清楚顯示，支付平台的安全性亦取決於商戶如何管理生產環境憑證。一條外洩的有效API密鑰，可能迅速變成客戶資料外洩、付款濫用甚至出款風險。對商戶而言，生產秘密應按高影響力憑證管理：不要放入程式碼或日誌、限制權限、盡快輪換，並調查每一宗異常API或出款活動。