ラッコ株式会社、Stripe 本番APIキーへ不正アクセス、詳細調査中

ラッコ株式会社は2026年8月25日、同社が利用する決済サービス「Stripe」の本番環境APIキーに第三者からの不正アクセスがあり、API経由で決済ログが不正に参照されたと判断したことを公表しました。

同社サービス以外のIPアドレスから、通常は使用しないログ参照APIなどへのアクセスが確認されています。APIから参照可能だった決済ログには、メールアドレス、カード番号下4桁、カードブランド、有効期限、カード名義、請求先住所、電話番号、決済金額、通貨、決済ステータスが含まれていました。

ただし、これらの情報が第三者によって実際に取得されたか、対象件数が何件かは現時点で確定していません。カード番号全桁とセキュリティコードは、当該APIから参照できる情報には含まれていません。

また、不正決済、返金、送金、出金などの金銭的被害や、ラッコが運営する各サービスそのものへの不正アクセスは確認されていません。

Stripe APIキー不正利用のサマリー

• 【確認済み】ラッコ株式会社は2026年8月25日、Stripe本番環境APIキーに対する不正アクセスを公表しました。
• 【確認済み】同社サービス以外のIPアドレスから、通常利用しないログ参照APIなどへのアクセスが確認されています。
• 【確認済み】同社は第三者による不正なログ参照が行われたと判断しています。
• 【確認済み】参照可能だった情報には、メールアドレス、カード番号下4桁、カードブランド、有効期限、カード名義、請求先住所、電話番号、決済情報が含まれます。
• 【未確定】第三者が実際に取得した情報の内容と対象件数は調査中です。
• 【確認済み】カード番号全桁とセキュリティコードは当該APIから参照できません。
• 【確認済み】現時点で不正決済、返金、送金、出金などの金銭的被害は確認されていません。
• 【確認済み】ラッコ各サービスそのものへの不正アクセスも確認されていません。
• 【確認済み】Stripeからの通知は8月22日9時03分、ラッコ側での感知は8月24日10時01分、該当APIキーの停止は同日12時22分です。
• 【確認済み】APIキーのローテーション、アクセス元IP制限、不要な旧キーの削除を実施しています。
• 【未確定】APIキーがどの経路から漏えいしたのかは公表されていません。
• 【未確認】個人情報保護委員会や警察への報告について、公表文では確認できませんでした。

項目	内容
公表日	2026年8月25日
対象組織	ラッコ株式会社
対象サービス	決済サービスStripeの本番環境API
インシデント	Stripe本番APIキーの不正利用、決済ログの不正参照
Stripeからの通知	2026年8月22日9時03分
自社での感知	2026年8月24日10時01分
APIキー停止	2026年8月24日12時22分
侵入・漏えい経路	調査中、確認できず
参照可能だった情報	メールアドレス、カード番号下4桁、カードブランド、有効期限、カード名義、請求先住所、電話番号、決済金額、通貨、決済ステータス
実際に取得された情報	調査中
対象件数	調査中
カード番号全桁・セキュリティコード	当該APIから参照不可
金銭的被害	現時点で確認されず
ラッコ各サービスへの不正アクセス	現時点で確認されず
対応	キー停止・ローテーション、IP制限、利用状況確認、不要キー削除、Stripeへログ調査依頼
個人情報保護委員会への報告	公表文では確認できず

Stripe本番APIキーを使った通常外のアクセスを確認

ラッコ株式会社によると、Stripeの本番環境APIキーに対して、同社サービス以外のIPアドレスからアクセスがありました。

さらに、通常のサービス運用では使用していないログ参照APIなどが実行されていたことから、同社は第三者による不正なログ参照が行われたと判断しています。

今回確認されたのは、ラッコのWebサービスへログインして画面を操作するタイプの不正アクセスではありません。

決済サービスとのシステム連携に使用する本番APIキーが第三者に利用され、正規のAPI認証を通じてStripe側の情報へアクセスされた事案です。

APIキーが漏えいすると、攻撃者は利用者のアカウントを奪わなくても、キーに付与されている権限の範囲内でAPIを呼び出せる場合があります。このため、APIキーはパスワードや秘密鍵と同様の認証情報として管理する必要があります。

決済ログに個人情報、実際の取得件数は未確定

当該APIを通じて参照可能だった決済ログには、次の情報が含まれていました。

メールアドレス、カード番号下4桁、カードブランド、カード有効期限、カード名義、請求先住所、電話番号、決済金額、通貨、決済ステータスです。

一方、ラッコは「参照可能だった情報」と「第三者が実際に取得した情報」を明確に分けています。

現時点では、第三者がどの情報を実際に取得したのか、対象件数が何件なのかは確認できていません。

そのため、参照可能だった全項目が流出した、あるいはStripeを利用した全顧客の情報が漏えいしたと断定することはできません。

カード番号全桁とセキュリティコードについては、当該APIから参照できる情報には含まれていません。

不正決済や出金などの金銭被害は確認されず

ラッコは、現時点で不正な決済、返金、送金、出金、その他の金銭的被害を確認していないとしています。

また、ラッコが運営する各サービスへの不正アクセスや、サービス利用への影響も確認されていません。

ただし、調査は継続中です。

同社はStripeへ、問題となったAPIキーを使用したすべてのリクエスト、取得された顧客・決済情報と件数、決済・送金・出金・返金・連結アカウント作成など金銭的影響につながる操作の有無について詳細なログ調査を依頼しています。

Stripe上でラッコ側が直接確認できるログの保持期間が限られるため、影響が及ぶ可能性のある期間を含めてStripe側へ調査を依頼したと説明しています。

8月22日にStripeが通知、24日に自社で感知

公表された時系列では、Stripeからラッコへの通知は8月22日9時03分でした。

その後、ラッコが本件を「感知」したのは8月24日10時01分で、漏えいしたAPIキーを停止したのは同日12時22分です。

Stripeからの通知から自社での感知まで約2日ありますが、公表文では、この間にどのような確認や対応が行われていたのか、なぜ8月24日を「感知」としているのかは説明されていません。

このため、通知後に対応が放置されていたと断定することはできません。一方、インシデント対応の検証では、外部サービスからのセキュリティ通知が社内のどの経路で受信され、誰が確認し、どの条件でインシデントとしてエスカレーションするのかも確認ポイントになります。

APIキーが実際にどの経路から漏えいしたのかについても、現時点の公表では明らかになっていません。

ソースコード、リポジトリ、ログ、設定ファイル、開発端末、CI/CD、クラウドのシークレット管理など、どの管理領域から認証情報が露出したのかは今後の調査事項です。

APIキーを停止・ローテーション、IP制限も導入

ラッコは8月24日12時22分に問題となったAPIキーを停止しました。

その後、現在利用しているStripe APIキーをローテーションし、Stripe APIへのアクセス元IPアドレスを制限しました。現在はラッコのサービスサーバーを経由したアクセスだけが可能な状態に変更したとしています。

あわせて、各サービスにおけるStripe APIキーの利用状況を確認し、不要になった旧APIキーを削除しました。

Stripeも公式ドキュメントで、秘密APIキーについて、定期的なローテーション、APIリクエストログの監視、必要最小限の権限に制限したRestricted API Keyの利用、固定IPから利用できる場合のIPアドレス制限を推奨しています。

キーが露出または侵害された場合は、実際に悪用されたか確信できない場合でも直ちにローテーションし、APIログから見覚えのないIPアドレスや通常利用しないAPI呼び出しを確認するよう案内しています。

今回ラッコが実施したキーのローテーション、IP制限、ログ確認は、こうした一般的なAPIキー侵害時の対策と一致します。

「キーを漏らさない」だけでは不十分

APIキー管理では、秘密情報をリポジトリやログへ出さないことが基本です。

しかし、実務上は「漏えいしないこと」を前提にするだけでは十分ではありません。

今回のようにキーが第三者へ渡った場合でも、APIキーに許可する操作を必要最小限に限定し、利用元IPを固定し、異常なAPI呼び出しを監視していれば、侵害時の影響範囲や検知時間を抑えられる可能性があります。

Stripeでは通常の秘密キーとは別に、アクセス可能なリソースや操作を限定するRestricted API Keyを作成できます。

例えば、決済を作成する処理とログを参照する処理が別のシステムであれば、同じ広権限キーを共有するのではなく、それぞれに必要な権限だけを持つキーへ分離する設計が有効です。

キーごとに利用目的を分けることで、不正アクセス時にも「どのシステムのキーが使われたか」を追跡しやすくなります。

本番APIキーの棚卸しと不要キー削除

ラッコは今回、各サービスのStripe APIキー利用状況を確認し、不要になった旧キーを削除しています。

APIキーは一度作成されると、システム改修や担当者変更後も残り続けることがあります。

利用されていない旧キーが有効なまま残っていると、管理者側が存在を認識しない認証経路となり、漏えい時に発見が遅れる可能性があります。

そのため、キーには用途、利用システム、責任者、作成日、最終利用日、ローテーション期限を紐付け、定期的に棚卸しする必要があります。

セキュリティ対策Labでは、開発環境への侵害で本番環境でも使用するAPIキーが窃取された事例についても取り上げています。開発環境と本番環境の認証情報を分離し、シークレットの用途を限定することは、今回のようなAPIキー侵害でも重要な対策になります。

情報システム・開発部門への示唆

今回の事案では、Stripeアカウントそのものへのログイン侵害ではなく、APIキーを使った正規API経由のアクセスが問題となりました。

このタイプの侵害では、Web管理画面の多要素認証を強化していても、APIキーが別経路で流出すれば攻撃を防げない場合があります。

開発・クラウド運用部門では、APIキーをシークレット管理基盤へ格納し、ソースコード、CIログ、エラーログ、チャット、チケットなどへ出力しない運用を徹底する必要があります。

さらに、キーごとの最小権限化、IP制限、環境別のキー分離、定期ローテーション、不要キー削除、APIリクエストログの監視を組み合わせることが重要です。

特に「通常使用しないAPIが呼ばれた」という検知は有効です。APIごとの通常利用パターンを把握し、通常は利用しないエンドポイントへのアクセス、未知のIPアドレス、短時間の大量呼び出しなどをアラート対象にすることで、侵害後の早期検知につながります。

ラッコ株式会社については、現時点でAPIキーの漏えい経路、第三者が実際に取得した情報、対象件数、アクセスが始まった時期が確定していません。

今後の続報では、これらに加え、Stripeから8月22日に通知を受けてから24日の自社感知までの対応経緯、個人情報保護委員会や警察への報告状況も確認ポイントとなります。

出典

• 当社が利用する決済システムに対するセキュリティインシデントについて – ラッコ株式会社
• Best practices for managing secret API keys – Stripe Documentation
• API keys – Stripe Documentation
• 株式会社ワサビ、開発環境への不正アクセスでランサムメッセージ残置-Dockerと自宅ルーターの二重の設定不備が原因 – セキュリティ対策Lab