資料集中據報包含什麼

資料涵蓋期間據稱從 2022 年 1 月至 2026 年 6 月，類型包括：

• Stripe 客戶物件與聯絡資料
• Charges、Payment Intents、Checkout Sessions、發票、退款與爭議款項
• 出款與餘額交易紀錄
• 訂閱、產品與價格資料
• 付款相關中繼資料，例如卡片品牌、末四碼、到期日、資金類型、發卡國家與付款指紋

目前報導沒有顯示資料集中包含完整卡號。這會降低部分直接盜刷風險，但不代表事件可以被視為低風險：即時 API 憑證一旦落入他人手中，加上詳細的客戶與交易資料，仍可能造成資料存取、付款濫用與針對性詐騙。

研究人員據報找到 650 把仍可使用的 sk_live 秘密金鑰，以及 9 把受限金鑰。在受影響帳戶中，573 個可收款、531 個具備出款能力，519 個同時具備兩種能力。

為什麼一把即時金鑰就可能造成嚴重後果

Stripe 秘密金鑰是 API 憑證，不只是帳戶識別碼。它實際能做什麼，取決於金鑰權限與商戶帳戶設定；但只要憑證遭到竊取，就可能被用來讀取商戶資源，甚至進行未授權的付款操作。

報導中的測試顯示，一把仍有效的金鑰就能用於：

• 讀取客戶清單
• 建立詐騙用付款連結
• 發起測試扣款

這些能力可能進一步導致客戶資料枚舉、付款濫用、未授權退款、精準釣魚，以及與付款相關的社交工程。具備出款權限的帳戶，還需要額外確認出款設定與收款銀行帳戶資料是否遭到更改。

真正棘手之處在於速度：伺服器端秘密一旦外洩，企業可能在察覺異常前，就已經從單純的秘密管理失誤，演變成即時的付款詐騙與事件調查。

為何研究人員認為不是 Stripe 基礎設施遭到攻破

研究人員對公開資料進行離線分析後指出，檔案中的 Stripe 格式物件與目錄結構，符合透過 API 端點匯出資料的特徵。他們在檢視過程中沒有使用外洩金鑰驗證，也沒有進入受影響商戶的即時環境。

換句話說，目前證據較支持「攻擊者取得商戶持有的有效憑證，再透過 Stripe 的合法 API 讀取資料」，而非 Stripe 核心系統遭到入侵。可能的憑證外洩途徑包括：

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

不過，659 個商戶憑證最初是如何被竊取，目前尚未確定。上述只是合理的外洩路徑，不能視為整批資料已確認的單一來源。

相關資料發布與數字落差

Hudson Rock 的相關報告將另一批論壇發布資料歸因於同一名行為者。該批資料據稱包含 669 個供應商資料夾與 1,033 把遭入侵的 API 金鑰，宣稱容量為 33 GB；但相關下載檔案據報小於這個數字。行為者另聲稱手上還有約 20,000 把遭入侵的 Stripe API 金鑰，並暗示未來可能發布更多批次。

這些數字不應直接相加，或合併成一個已確認的總量。659 個商戶帳戶、669 個供應商資料夾與 1,033 把金鑰之間的差異，可能來自不同資料集、同一帳戶擁有多把金鑰、重複資料，或不同的計算方式。至於 20,000 把金鑰，仍只是行為者未經驗證的說法。

受影響商戶最多的國家

現有報導列出的主要所在地包括：

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

這些數字反映目前報告中的商戶分布，仍應搭配資料集範圍尚在評估中的前提解讀。

使用 Stripe 的企業現在應該怎麼做

1. 立即輪替即時秘密金鑰

撤銷並重新建立所有可能出現在原始碼、日誌、備份、端點遙測資料、容器映像或公開基礎設施中的即時秘密金鑰。不要等到發現詐騙活動後，才處理可能已經外洩的憑證。

2. 稽核 API 與付款活動

檢查 API 和安全性日誌，尋找不熟悉的呼叫、新建立的付款連結、測試或未授權扣款、異常退款、權限變更，以及不尋常的來源 IP 位址。保留相關日誌，以便建立事件時間線。

3. 核對出款設定

確認出款設定、已連結的銀行帳戶資料與出款目的地。若發現可疑變更，應依照企業適用的事件應變與通報程序，盡快聯絡 Stripe 及相關金融機構。

4. 以受限金鑰取代廣泛權限憑證

為每項服務使用僅涵蓋必要 API 操作的受限金鑰。生產環境、開發環境與營運角色應彼此分離，避免把同一把高權限秘密散布到多個應用程式。

5. 搜尋所有可能保存秘密的地方

檢查目前與歷史儲存庫、Git 歷史、CI/CD 輸出、GitHub Actions 日誌、.env 檔案、容器映像層、雲端儲存、文件與備份中的 sk_live 值。即使該金鑰已不在目前版本的程式碼中，只要曾經出現，也應撤銷並重新建立。

6. 不要把 GitHub 秘密掃描當成唯一防線

GitHub 表示，公開儲存庫會自動執行秘密掃描；組織擁有的私有與內部儲存庫，則需要在符合資格的方案中啟用 GitHub Secret Protection。 但掃描無法找回已被複製到日誌、備份、端點遙測資料或已下載檔案中的秘密。因此，企業仍需要集中式秘密管理、較短的憑證有效期、權限控管與持續監控，讓秘密掃描成為其中一層，而不是完整的防護方案。

給商戶的核心教訓

這起事件最清楚的警訊是：支付平台的安全性，也取決於商戶自身的憑證管理。現有報導沒有證實 Stripe 基礎設施遭到攻破，但已說明外洩的即時 API 金鑰如何成為客戶資料遭存取與付款濫用的入口。企業應把生產環境秘密視為高影響力憑證：不要放進程式碼或日誌、限制其權限、快速輪替，並調查每一筆異常 API 或出款活動。

資料集中據報包含什麼

資料涵蓋期間據稱從 2022 年 1 月至 2026 年 6 月，類型包括：

• Stripe 客戶物件與聯絡資料
• Charges、Payment Intents、Checkout Sessions、發票、退款與爭議款項
• 出款與餘額交易紀錄
• 訂閱、產品與價格資料
• 付款相關中繼資料，例如卡片品牌、末四碼、到期日、資金類型、發卡國家與付款指紋

目前報導沒有顯示資料集中包含完整卡號。這會降低部分直接盜刷風險，但不代表事件可以被視為低風險：即時 API 憑證一旦落入他人手中，加上詳細的客戶與交易資料，仍可能造成資料存取、付款濫用與針對性詐騙。

研究人員據報找到 650 把仍可使用的 sk_live 秘密金鑰，以及 9 把受限金鑰。在受影響帳戶中，573 個可收款、531 個具備出款能力，519 個同時具備兩種能力。

為什麼一把即時金鑰就可能造成嚴重後果

Stripe 秘密金鑰是 API 憑證，不只是帳戶識別碼。它實際能做什麼，取決於金鑰權限與商戶帳戶設定；但只要憑證遭到竊取，就可能被用來讀取商戶資源，甚至進行未授權的付款操作。

報導中的測試顯示，一把仍有效的金鑰就能用於：

• 讀取客戶清單
• 建立詐騙用付款連結
• 發起測試扣款

這些能力可能進一步導致客戶資料枚舉、付款濫用、未授權退款、精準釣魚，以及與付款相關的社交工程。具備出款權限的帳戶，還需要額外確認出款設定與收款銀行帳戶資料是否遭到更改。

真正棘手之處在於速度：伺服器端秘密一旦外洩，企業可能在察覺異常前，就已經從單純的秘密管理失誤，演變成即時的付款詐騙與事件調查。

為何研究人員認為不是 Stripe 基礎設施遭到攻破

研究人員對公開資料進行離線分析後指出，檔案中的 Stripe 格式物件與目錄結構，符合透過 API 端點匯出資料的特徵。他們在檢視過程中沒有使用外洩金鑰驗證，也沒有進入受影響商戶的即時環境。

換句話說，目前證據較支持「攻擊者取得商戶持有的有效憑證，再透過 Stripe 的合法 API 讀取資料」，而非 Stripe 核心系統遭到入侵。可能的憑證外洩途徑包括：

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

不過，659 個商戶憑證最初是如何被竊取，目前尚未確定。上述只是合理的外洩路徑，不能視為整批資料已確認的單一來源。

相關資料發布與數字落差

Hudson Rock 的相關報告將另一批論壇發布資料歸因於同一名行為者。該批資料據稱包含 669 個供應商資料夾與 1,033 把遭入侵的 API 金鑰，宣稱容量為 33 GB；但相關下載檔案據報小於這個數字。行為者另聲稱手上還有約 20,000 把遭入侵的 Stripe API 金鑰，並暗示未來可能發布更多批次。

這些數字不應直接相加，或合併成一個已確認的總量。659 個商戶帳戶、669 個供應商資料夾與 1,033 把金鑰之間的差異，可能來自不同資料集、同一帳戶擁有多把金鑰、重複資料，或不同的計算方式。至於 20,000 把金鑰，仍只是行為者未經驗證的說法。

受影響商戶最多的國家

現有報導列出的主要所在地包括：

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

這些數字反映目前報告中的商戶分布，仍應搭配資料集範圍尚在評估中的前提解讀。

使用 Stripe 的企業現在應該怎麼做

1. 立即輪替即時秘密金鑰

撤銷並重新建立所有可能出現在原始碼、日誌、備份、端點遙測資料、容器映像或公開基礎設施中的即時秘密金鑰。不要等到發現詐騙活動後，才處理可能已經外洩的憑證。

2. 稽核 API 與付款活動

檢查 API 和安全性日誌，尋找不熟悉的呼叫、新建立的付款連結、測試或未授權扣款、異常退款、權限變更，以及不尋常的來源 IP 位址。保留相關日誌，以便建立事件時間線。

3. 核對出款設定

確認出款設定、已連結的銀行帳戶資料與出款目的地。若發現可疑變更，應依照企業適用的事件應變與通報程序，盡快聯絡 Stripe 及相關金融機構。

4. 以受限金鑰取代廣泛權限憑證

為每項服務使用僅涵蓋必要 API 操作的受限金鑰。生產環境、開發環境與營運角色應彼此分離，避免把同一把高權限秘密散布到多個應用程式。

5. 搜尋所有可能保存秘密的地方

檢查目前與歷史儲存庫、Git 歷史、CI/CD 輸出、GitHub Actions 日誌、.env 檔案、容器映像層、雲端儲存、文件與備份中的 sk_live 值。即使該金鑰已不在目前版本的程式碼中，只要曾經出現，也應撤銷並重新建立。

6. 不要把 GitHub 秘密掃描當成唯一防線

GitHub 表示，公開儲存庫會自動執行秘密掃描；組織擁有的私有與內部儲存庫，則需要在符合資格的方案中啟用 GitHub Secret Protection。 但掃描無法找回已被複製到日誌、備份、端點遙測資料或已下載檔案中的秘密。因此，企業仍需要集中式秘密管理、較短的憑證有效期、權限控管與持續監控，讓秘密掃描成為其中一層，而不是完整的防護方案。

給商戶的核心教訓

這起事件最清楚的警訊是：支付平台的安全性，也取決於商戶自身的憑證管理。現有報導沒有證實 Stripe 基礎設施遭到攻破，但已說明外洩的即時 API 金鑰如何成為客戶資料遭存取與付款濫用的入口。企業應把生產環境秘密視為高影響力憑證：不要放進程式碼或日誌、限制其權限、快速輪替，並調查每一筆異常 API 或出款活動。