事件涉及哪些資料？

目前最詳細的分析指出，資料集涉及：

• 659 個商戶帳戶
• 650 把仍有效的 sk_live 秘密金鑰
• 約 688,363 筆客戶紀錄
• 分布於 42 個國家的商戶
• 約 35 GB 資料、共 17,654 個檔案

資料據報包含客戶資訊，以及以下交易和帳務紀錄：

• Charges（扣款）
• Payment Intents（付款意圖）
• 發票
• 撥款
• 退款
• 餘額交易

相關紀錄的日期範圍為 2022 年 1 月至 2026 年 6 月。

這起外洩不只涉及個人資料風險，也可能影響支付作業。據報 659 個帳戶中有 519 個同時具備收款及發放款項的能力；若金鑰在外洩後仍未失效，攻擊者可能利用這些權限進行未授權支付，甚至嘗試挪用或改道資金。

受影響商戶數量最多的國家，據報為：

• 美國：212 個帳戶
• 英國：81 個帳戶
• 法國：57 個帳戶

誰發布了資料？

相關資料被歸因於化名為 「Satanic」 的威脅行動者。對方據報在 8 月 18 日於 pwnforums 發帖，並把資料標示為可下載。

不過，不同報告對資料規模的統計並不一致。Hudson Rock 針對相關或初始版本的分析提到，資料包含 669 個供應商資料夾、1,033 把遭入侵的 API 金鑰，並宣稱總量達 33 GB。

這些差異可能源於不同發布階段、計算方式或驗證標準，因此不應直接合併為一個已確認的總數。至於威脅行動者聲稱手上還有約 20,000 把 Stripe API 金鑰、準備分批發布，目前尚未獲獨立驗證。

Hudson Rock 也指出，論壇帖子宣稱資料量為 33 GB，但實際可下載的壓縮檔約為 2.37 GB。這個落差與「尚有其他資料未公開」的說法相符，但本身並不足以證明該說法。

為什麼研究人員不稱它為 Stripe 基礎設施遭入侵？

現有報告顯示，攻擊者可能先取得個別商戶的秘密金鑰，再使用這些金鑰發出一般的 Stripe API 請求。在這種情況下，資料是透過原本便能存取商戶帳戶的憑證取得，而不是利用 Stripe 中央系統的漏洞。研究人員目前沒有發現 Stripe 核心基礎設施遭到攻破的證據。

商戶金鑰可能的外洩途徑包括：

• Infostealer（資訊竊取程式）留下的紀錄
• 公開程式碼提交內容
• 外洩的 .env 環境設定檔
• 不安全的備份
• CI/CD 建置與部署紀錄
• 設定錯誤的網頁伺服器
• 尋找環境變數及其他未妥善保護秘密資訊的自動化掃描

在相關報告發布時，研究人員尚未把特定商戶網域與 infostealer 感染事件直接連結起來，因此金鑰最初是從何處流出的，仍未有定論。

這項區分對事故應變十分重要：若是 Stripe 基礎設施遭入侵，可能代表平台層級的安全事件；但若是商戶金鑰外洩，則更可能是大量不同的秘密憑證分別遭竊，再被用來存取各自控制的帳戶。

一把有效金鑰能做什麼？

研究人員表示，他們在 17 小時內以一把仍有效的金鑰存取某商戶的客戶清單、建立詐騙 Payment Link，並完成一次測試扣款。

這項示範說明，具備廣泛權限的 live secret key 一旦外洩，就應被視為即時的帳戶安全事故。攻擊者不必先突破 Stripe，只要金鑰仍授權存取客戶資料及支付功能，便可能直接濫用這些權限。

潛在影響也不止於資料被讀取。視金鑰權限及商戶帳戶設定而定，未授權人士可能接觸支付紀錄，或操作 Payment Link、扣款、退款及撥款等功能。資料集據報包含多種交易類別，但現有報告並未證明每一個列出的帳戶都已發生詐騙交易。

只掃描 GitHub，為什麼仍不夠？

這起事件凸顯，僅掃描公開程式碼儲存庫，並不足以完整保護支付憑證。研究人員指出，Stripe 金鑰也可能出現在 GitHub Actions 紀錄、歷史建置產物、公開 .env 檔案、備份及設定錯誤的伺服器中；這些位置未必涵蓋在一般儲存庫掃描範圍內。

另有報告稱，研究人員在公開程式碼、GitHub Actions 紀錄及設定錯誤的伺服器中，發現超過 50,000 個 Stripe secrets。這個數字反映更廣泛的憑證暴露問題，並不代表這些金鑰都已確認屬於 8 月 18 日公開的資料集。

對企業而言，刪除目前儲存庫中的秘密資訊並不等於金鑰已經安全。副本可能仍留在提交歷史、建置紀錄、產物、備份或已部署系統中。只要金鑰可能外洩，就應予以撤銷或輪替，並同步調查相關系統。

Stripe 商戶現在應採取的措施

商戶若懷疑憑證曾被公開或遭未授權人士取得，應優先控制風險：

1. 立即撤銷或輪替可能外洩的 live secret keys。 只刪除檔案或儲存庫中的內容，並不會讓既有金鑰失效。
2. 檢查 Stripe API 及帳戶活動。 特別留意陌生 IP 位址、客戶清單存取、資料匯出、Payment Link 建立、扣款嘗試、退款及撥款活動。
3. 核對撥款銀行帳戶資料及近期變更。 如有需要，暫時提高轉帳監控或加入額外控制措施。
4. 以受限金鑰取代權限過大的秘密金鑰。 金鑰只應允許應用程式實際需要的 API 操作。
5. 將秘密資訊移至受管理的 secrets vault 或其他安全憑證管理工具。 同時從原始碼、環境檔、紀錄及未受保護的備份中移除。
6. 搜尋歷史儲存庫、CI/CD 紀錄、建置產物、伺服器及備份。 不要只檢查最新版本的公開程式碼。

目前證據支持這是一次嚴重的商戶憑證外洩事件，並帶來大規模客戶資料及支付資料風險；但尚不足以聲稱 Stripe 中央基礎設施已遭攻破。由於不同報告的統計數字存在落差，659 個商戶、650 把 live 金鑰，以及初始發布所稱的 669 個供應商和 1,033 把金鑰，應視為不同資料集或驗證階段的估算，而不是一份已確定的完整清單。

事件涉及哪些資料？

目前最詳細的分析指出，資料集涉及：

• 659 個商戶帳戶
• 650 把仍有效的 sk_live 秘密金鑰
• 約 688,363 筆客戶紀錄
• 分布於 42 個國家的商戶
• 約 35 GB 資料、共 17,654 個檔案

資料據報包含客戶資訊，以及以下交易和帳務紀錄：

• Charges（扣款）
• Payment Intents（付款意圖）
• 發票
• 撥款
• 退款
• 餘額交易

相關紀錄的日期範圍為 2022 年 1 月至 2026 年 6 月。

這起外洩不只涉及個人資料風險，也可能影響支付作業。據報 659 個帳戶中有 519 個同時具備收款及發放款項的能力；若金鑰在外洩後仍未失效，攻擊者可能利用這些權限進行未授權支付，甚至嘗試挪用或改道資金。

受影響商戶數量最多的國家，據報為：

• 美國：212 個帳戶
• 英國：81 個帳戶
• 法國：57 個帳戶

誰發布了資料？

相關資料被歸因於化名為 「Satanic」 的威脅行動者。對方據報在 8 月 18 日於 pwnforums 發帖，並把資料標示為可下載。

不過，不同報告對資料規模的統計並不一致。Hudson Rock 針對相關或初始版本的分析提到，資料包含 669 個供應商資料夾、1,033 把遭入侵的 API 金鑰，並宣稱總量達 33 GB。

這些差異可能源於不同發布階段、計算方式或驗證標準，因此不應直接合併為一個已確認的總數。至於威脅行動者聲稱手上還有約 20,000 把 Stripe API 金鑰、準備分批發布，目前尚未獲獨立驗證。

Hudson Rock 也指出，論壇帖子宣稱資料量為 33 GB，但實際可下載的壓縮檔約為 2.37 GB。這個落差與「尚有其他資料未公開」的說法相符，但本身並不足以證明該說法。

為什麼研究人員不稱它為 Stripe 基礎設施遭入侵？

現有報告顯示，攻擊者可能先取得個別商戶的秘密金鑰，再使用這些金鑰發出一般的 Stripe API 請求。在這種情況下，資料是透過原本便能存取商戶帳戶的憑證取得，而不是利用 Stripe 中央系統的漏洞。研究人員目前沒有發現 Stripe 核心基礎設施遭到攻破的證據。

商戶金鑰可能的外洩途徑包括：

• Infostealer（資訊竊取程式）留下的紀錄
• 公開程式碼提交內容
• 外洩的 .env 環境設定檔
• 不安全的備份
• CI/CD 建置與部署紀錄
• 設定錯誤的網頁伺服器
• 尋找環境變數及其他未妥善保護秘密資訊的自動化掃描

在相關報告發布時，研究人員尚未把特定商戶網域與 infostealer 感染事件直接連結起來，因此金鑰最初是從何處流出的，仍未有定論。

這項區分對事故應變十分重要：若是 Stripe 基礎設施遭入侵，可能代表平台層級的安全事件；但若是商戶金鑰外洩，則更可能是大量不同的秘密憑證分別遭竊，再被用來存取各自控制的帳戶。

一把有效金鑰能做什麼？

研究人員表示，他們在 17 小時內以一把仍有效的金鑰存取某商戶的客戶清單、建立詐騙 Payment Link，並完成一次測試扣款。

這項示範說明，具備廣泛權限的 live secret key 一旦外洩，就應被視為即時的帳戶安全事故。攻擊者不必先突破 Stripe，只要金鑰仍授權存取客戶資料及支付功能，便可能直接濫用這些權限。

潛在影響也不止於資料被讀取。視金鑰權限及商戶帳戶設定而定，未授權人士可能接觸支付紀錄，或操作 Payment Link、扣款、退款及撥款等功能。資料集據報包含多種交易類別，但現有報告並未證明每一個列出的帳戶都已發生詐騙交易。

只掃描 GitHub，為什麼仍不夠？

這起事件凸顯，僅掃描公開程式碼儲存庫，並不足以完整保護支付憑證。研究人員指出，Stripe 金鑰也可能出現在 GitHub Actions 紀錄、歷史建置產物、公開 .env 檔案、備份及設定錯誤的伺服器中；這些位置未必涵蓋在一般儲存庫掃描範圍內。

另有報告稱，研究人員在公開程式碼、GitHub Actions 紀錄及設定錯誤的伺服器中，發現超過 50,000 個 Stripe secrets。這個數字反映更廣泛的憑證暴露問題，並不代表這些金鑰都已確認屬於 8 月 18 日公開的資料集。

對企業而言，刪除目前儲存庫中的秘密資訊並不等於金鑰已經安全。副本可能仍留在提交歷史、建置紀錄、產物、備份或已部署系統中。只要金鑰可能外洩，就應予以撤銷或輪替，並同步調查相關系統。

Stripe 商戶現在應採取的措施

商戶若懷疑憑證曾被公開或遭未授權人士取得，應優先控制風險：

1. 立即撤銷或輪替可能外洩的 live secret keys。 只刪除檔案或儲存庫中的內容，並不會讓既有金鑰失效。
2. 檢查 Stripe API 及帳戶活動。 特別留意陌生 IP 位址、客戶清單存取、資料匯出、Payment Link 建立、扣款嘗試、退款及撥款活動。
3. 核對撥款銀行帳戶資料及近期變更。 如有需要，暫時提高轉帳監控或加入額外控制措施。
4. 以受限金鑰取代權限過大的秘密金鑰。 金鑰只應允許應用程式實際需要的 API 操作。
5. 將秘密資訊移至受管理的 secrets vault 或其他安全憑證管理工具。 同時從原始碼、環境檔、紀錄及未受保護的備份中移除。
6. 搜尋歷史儲存庫、CI/CD 紀錄、建置產物、伺服器及備份。 不要只檢查最新版本的公開程式碼。

目前證據支持這是一次嚴重的商戶憑證外洩事件，並帶來大規模客戶資料及支付資料風險；但尚不足以聲稱 Stripe 中央基礎設施已遭攻破。由於不同報告的統計數字存在落差，659 個商戶、650 把 live 金鑰，以及初始發布所稱的 669 個供應商和 1,033 把金鑰，應視為不同資料集或驗證階段的估算，而不是一份已確定的完整清單。