外洩資料涉及幾大規模？

較詳細的分析指，資料集涉及：

• 659 個商戶帳戶
• 650 條仍然有效的 sk_live 秘密密鑰
• 估計 688,363 個客戶紀錄
• 分布於 42 個國家
• 約 35 GB 資料，合共 17,654 個檔案

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

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

相關紀錄日期由 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 建置日誌
• 配置錯誤的網頁伺服器
• 自動掃描環境變數及其他保護不足的秘密資料

截至相關報道發布時，研究人員尚未把資訊竊取程式感染，與資料集內列出的特定商戶網域直接連繫起來，因此密鑰最初是如何外洩，仍未有定論。

這個區分對事故應變相當重要：如果是 Stripe 基礎設施被攻破，代表可能出現平台層面的安全事故；今次證據則較指向大量個別商戶密鑰先被洩露，再被用來存取各自獲授權的帳戶。

一條有效密鑰可以做到甚麼？

研究人員表示，只需一條有效密鑰，便能在 17 小時內讀取某商戶的客戶名單、建立虛假的 Payment Link，並進行一次測試扣款。

這項示範說明，具備廣泛權限而又仍然有效的秘密密鑰，應立即視為帳戶安全事故。攻擊者未必需要先攻破 Stripe；如果密鑰本身已授權讀取客戶資料及操作支付功能，便可能直接濫用這些權限。

視乎密鑰權限及商戶帳戶設定，未經授權的存取可能涉及支付紀錄外洩，以及建立支付連結、扣款、退款和出款等操作。雖然報告指資料集包含多類交易紀錄，但現有資料並未證實每一個列出的帳戶都曾發生詐騙活動。

只掃描 GitHub，點解仍然唔夠？

事件亦突顯，單靠掃描公開程式碼庫，並不足以全面保護支付憑證。研究人員指出，密鑰可能出現在 GitHub Actions 日誌、歷史建置產物、公開 .env 檔案、備份、配置錯誤的伺服器等位置，而這些地方未必涵蓋在一般程式碼庫掃描範圍內。

另有報道指，研究人員在公開程式碼、GitHub Actions 日誌及配置錯誤的伺服器中，發現超過 50,000 條 Stripe 秘密資料。這個數字反映更廣泛的憑證暴露問題，並不代表當中每一條都已確認屬於 8 月 18 日公布的資料集。

對企業而言，將秘密資料從目前的程式碼庫刪除，並不等於密鑰已經失效。副本可能仍存在於提交歷史、建置日誌、產物、備份或已部署的系統內。只要懷疑密鑰曾經外洩，就應撤銷或輪換，同時檢查相關系統及存取紀錄。

Stripe 商戶應立即採取甚麼措施？

如商戶可能有憑證外洩，應先控制風險：

1. 立即撤銷或輪換可能外洩的有效秘密密鑰。 單純刪除檔案或程式碼庫內的紀錄，並不會令密鑰失效。
2. 檢查 Stripe API 及帳戶活動。 留意不熟悉的 IP 位址、客戶名單存取、資料匯出、Payment Link 建立、扣款嘗試、退款及出款活動。
3. 核對出款銀行帳戶資料及近期更改。 如有需要，暫時加強轉帳監察或設置額外控制。
4. 以受限制密鑰取代權限過大的密鑰。 只授予應用程式實際需要的 API 操作權限。
5. 把秘密資料放入受管理的密鑰儲存系統。 避免將其留在原始碼、環境檔案、日誌或未受保護的備份內。
6. 搜尋歷史程式碼庫、CI/CD 日誌、建置產物、伺服器及備份。 不要只檢查最新的公開程式碼。

目前證據支持這是一宗嚴重的商戶憑證外洩事件，並帶來顯著的客戶及支付資料風險；但未足以指稱 Stripe 核心基礎設施已被攻破。由於不同報道的數字存在落差，659 個帳戶、650 條有效密鑰，以及 Hudson Rock 所指的 669 個供應商和 1,033 條密鑰，應理解為不同資料集或發布階段的估算，而不是一份單一、最終確認的清單。

外洩資料涉及幾大規模？

較詳細的分析指，資料集涉及：

• 659 個商戶帳戶
• 650 條仍然有效的 sk_live 秘密密鑰
• 估計 688,363 個客戶紀錄
• 分布於 42 個國家
• 約 35 GB 資料，合共 17,654 個檔案

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

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

相關紀錄日期由 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 建置日誌
• 配置錯誤的網頁伺服器
• 自動掃描環境變數及其他保護不足的秘密資料

截至相關報道發布時，研究人員尚未把資訊竊取程式感染，與資料集內列出的特定商戶網域直接連繫起來，因此密鑰最初是如何外洩，仍未有定論。

這個區分對事故應變相當重要：如果是 Stripe 基礎設施被攻破，代表可能出現平台層面的安全事故；今次證據則較指向大量個別商戶密鑰先被洩露，再被用來存取各自獲授權的帳戶。

一條有效密鑰可以做到甚麼？

研究人員表示，只需一條有效密鑰，便能在 17 小時內讀取某商戶的客戶名單、建立虛假的 Payment Link，並進行一次測試扣款。

這項示範說明，具備廣泛權限而又仍然有效的秘密密鑰，應立即視為帳戶安全事故。攻擊者未必需要先攻破 Stripe；如果密鑰本身已授權讀取客戶資料及操作支付功能，便可能直接濫用這些權限。

視乎密鑰權限及商戶帳戶設定，未經授權的存取可能涉及支付紀錄外洩，以及建立支付連結、扣款、退款和出款等操作。雖然報告指資料集包含多類交易紀錄，但現有資料並未證實每一個列出的帳戶都曾發生詐騙活動。

只掃描 GitHub，點解仍然唔夠？

事件亦突顯，單靠掃描公開程式碼庫，並不足以全面保護支付憑證。研究人員指出，密鑰可能出現在 GitHub Actions 日誌、歷史建置產物、公開 .env 檔案、備份、配置錯誤的伺服器等位置，而這些地方未必涵蓋在一般程式碼庫掃描範圍內。

另有報道指，研究人員在公開程式碼、GitHub Actions 日誌及配置錯誤的伺服器中，發現超過 50,000 條 Stripe 秘密資料。這個數字反映更廣泛的憑證暴露問題，並不代表當中每一條都已確認屬於 8 月 18 日公布的資料集。

對企業而言，將秘密資料從目前的程式碼庫刪除，並不等於密鑰已經失效。副本可能仍存在於提交歷史、建置日誌、產物、備份或已部署的系統內。只要懷疑密鑰曾經外洩，就應撤銷或輪換，同時檢查相關系統及存取紀錄。

Stripe 商戶應立即採取甚麼措施？

如商戶可能有憑證外洩，應先控制風險：

1. 立即撤銷或輪換可能外洩的有效秘密密鑰。 單純刪除檔案或程式碼庫內的紀錄，並不會令密鑰失效。
2. 檢查 Stripe API 及帳戶活動。 留意不熟悉的 IP 位址、客戶名單存取、資料匯出、Payment Link 建立、扣款嘗試、退款及出款活動。
3. 核對出款銀行帳戶資料及近期更改。 如有需要，暫時加強轉帳監察或設置額外控制。
4. 以受限制密鑰取代權限過大的密鑰。 只授予應用程式實際需要的 API 操作權限。
5. 把秘密資料放入受管理的密鑰儲存系統。 避免將其留在原始碼、環境檔案、日誌或未受保護的備份內。
6. 搜尋歷史程式碼庫、CI/CD 日誌、建置產物、伺服器及備份。 不要只檢查最新的公開程式碼。

目前證據支持這是一宗嚴重的商戶憑證外洩事件，並帶來顯著的客戶及支付資料風險；但未足以指稱 Stripe 核心基礎設施已被攻破。由於不同報道的數字存在落差，659 個帳戶、650 條有效密鑰，以及 Hudson Rock 所指的 669 個供應商和 1,033 條密鑰，應理解為不同資料集或發布階段的估算，而不是一份單一、最終確認的清單。