Stripeの加盟店APIキー流出、68万8363人の顧客情報が危険にさらされる

2026年8月18日、オンライン上のサイバー犯罪フォーラムに、Stripeを利用する659加盟店のAPI認証情報と顧客・決済データを含む、約35GBのアーカイブが無料公開されたと報告されました。攻撃者は「Satanic」と名乗り、約1万7654個のファイルを公開。データは42カ国の推定68万8363人の顧客に関連するとされています。ただし、これらは報道に基づく推定であり、攻撃者が主張する一部のより大きな数字は独立検証されていません。

何が含まれていたのか

報告されたデータの対象期間は、2022年1月から2026年6月までです。含まれていたとされる情報は、次のようなStripeの顧客・決済オブジェクトでした。

• Stripeの顧客オブジェクトと顧客の連絡先情報
• 決済（Charges）、Payment Intents、Checkoutセッション
• 請求書、返金、異議申し立て（dispute）
• 売上の振込、残高取引
• サブスクリプション、商品、価格情報
• カードブランド、下4桁、有効期限、資金種別、発行国、決済フィンガープリントなどの決済関連メタデータ

報道からは、カード番号全桁がアーカイブに含まれていたとは確認されていません。直接的なカード情報盗難の一部は抑えられるものの、API認証情報と詳細な顧客・取引データが公開されたことによるリスクがなくなるわけではありません。

研究者は、稼働中の sk_live 秘密鍵650個と、制限付きキー9個を確認したとしています。影響を受けたアカウントのうち、573件は支払いを受け付けることができ、531件は入金処理を実行でき、519件はその両方に対応していたと報告されています。

1本のライブキーでも不正利用につながる理由

Stripeの秘密鍵は、単なるアカウント識別子ではなく、APIを操作するための認証情報です。実際にアクセスできる範囲は、キーの権限や加盟店側の設定によって異なります。しかし、漏えいしたキーが有効であれば、顧客情報や決済情報へのアクセス、不正な決済操作につながる可能性があります。

報告された検証では、1本の有効なキーを使って、次の操作が可能だったとされています。

• 顧客リストへのアクセス
• 不正な決済リンクの作成
• テスト決済の実行

このほか、顧客情報の一覧化、不正決済、無断返金、標的型フィッシング、決済を口実にしたソーシャルエンジニアリングなども想定されます。入金機能を持つアカウントでは、入金設定や送金先の詳細が改ざんされていないかも確認が必要です。

重要なのは、サーバー側の認証情報が漏れると、加盟店が異常に気づく前に、秘密情報の管理ミスが実際の不正調査へ発展し得る点です。

Stripe本体の侵害と判断されていない理由

公開されたファイルをオフラインで調査した研究者は、Stripe形式のオブジェクトやディレクトリ構成が、正規のAPIエンドポイントから取得されたデータのエクスポートと整合すると説明しています。一方、研究者自身が流出キーで認証したり、加盟店の本番環境へアクセスしたりしたわけではありません。

現時点の証拠からは、Stripeの中核インフラが侵害されたというより、各加盟店が保管していた秘密鍵が盗まれ、その鍵を使って正規API経由でデータが取得された可能性が高いとみられています。

考えられる漏えい経路には、次のようなものがあります。

• 開発者や管理者の端末に侵入するインフォスティーラー
• 公開リポジトリやGitの過去履歴
• 公開された .env ファイルやサーバー設定
• クラウドストレージ、バックアップ、コンテナイメージ
• CI/CDシステムやGitHub Actionsのログ
• 設定不備のあるサーバーや、公開変数を探す自動スキャン

ただし、659加盟店の認証情報が最初にどの経路から盗まれたのかは確定していません。上記は考えられる露出経路であり、今回のデータ全体に共通する単一の原因と確認されたわけではありません。

関連する公開情報と「2万キー」報道の注意点

Hudson Rockの報告では、同じ攻撃者による関連フォーラム投稿も確認されています。こちらは669のベンダーフォルダーと、侵害されたとされるAPIキー1033個を含み、容量は33GBと広告されていました。リンク先のダウンロードデータは、広告された容量より小さかったと報告されています。

攻撃者はさらに、約2万個の侵害済みStripe APIキーを保有しており、今後も追加公開すると主張しました。しかし、この2万個という数字は攻撃者自身の未検証の主張です。

659の加盟店アカウント、669のベンダーフォルダー、1033個のキーという数字は、異なるデータセットや集計方法、1アカウントに複数のキーが存在する可能性によって生じた差と考えられます。これらを合算して、確定した総数とみなすことはできません。

報告された影響の大きい国

報道で示された加盟店数の上位は、次の通りです。

• 米国：212社
• 英国：81社
• フランス：57社
• カナダ：38社
• ブラジル：30社
• オーストラリア：27社

これらは報告されたデータ上の加盟店分布であり、データセット全体の範囲はなお確認中です。

Stripeを利用する企業が今すぐ行うべきこと

1. ライブ秘密鍵をローテーションする

ソースコード、ログ、バックアップ、エンドポイントのテレメトリー、コンテナイメージ、公開インフラなどに登場した可能性のあるライブ秘密鍵は、すべて無効化して交換します。不正利用の証拠を待つのではなく、漏えいの可能性がある時点で対応してください。

2. API操作と決済状況を監査する

APIやセキュリティのログを確認し、見慣れない呼び出し、作成された決済リンク、テスト決済や不正な請求、想定外の返金、権限変更、不審な送信元IPアドレスがないか調べます。調査に備え、関連ログは保存して時系列を再構成できるようにします。

3. 入金設定を確認する

入金設定、接続済み銀行口座、入金先の詳細を確認します。不審な変更があれば、Stripeや金融機関へ速やかに連絡し、社内のインシデント対応・報告手順に従ってください。

4. 広範なキーを制限付きキーに置き換える

各サービスに必要なAPI操作だけを許可する、権限を絞ったキーを使用します。本番環境、開発環境、運用担当者の役割を分離し、1本の強力な秘密鍵を複数アプリケーションで共有しないことが重要です。

5. 秘密情報が残る場所をすべて検索する

現在のリポジトリだけでなく、Git履歴、CI/CDの出力、GitHub Actionsのログ、.env ファイル、コンテナレイヤー、クラウドストレージ、ドキュメント、バックアップも検索し、sk_live の値が残っていないか確認します。過去のコードにしか存在しないキーでも、見つけた場合は無効化・交換してください。

6. GitHubのシークレットスキャンだけに依存しない

GitHubでは、公開リポジトリのシークレットスキャンが自動的に実行されます。一方、組織が所有するプライベートおよび内部リポジトリでは、対象プランでGitHub Secret Protectionを有効にする必要があります。

また、スキャンで検出できるのは対象範囲にある秘密情報です。ログ、バックアップ、端末のテレメトリー、すでにダウンロードされたアーカイブなど、GitHubの外部へコピーされた情報までは回収できません。シークレットスキャンは、集中管理、短い認証情報の有効期間、アクセス制御、継続的な監視を補完する仕組みとして位置づけるべきです。

加盟店側の秘密情報管理が焦点に

今回の報告から最も明確に読み取れるのは、決済プラットフォームの安全性が、加盟店側の認証情報管理にも大きく左右されるということです。Stripeのインフラ侵害は確認されていませんが、漏えいしたライブAPIキーが顧客情報へのアクセスや決済不正の足がかりになり得ることは示されています。

本番環境の秘密鍵は、影響の大きい認証情報として扱う必要があります。コードやログに残さず、権限を最小限に絞り、迅速にローテーションし、予期しないAPI操作や入金イベントを見逃さない体制を整えることが重要です。