コンテンツにスキップ
← インシデント一覧に戻る

横浜DeNAベイスターズ、クラウドファンディング支援者情報が流出のおそれ — CAMPFIREのGitHubアカウント侵害の影響が球団の企画に波及

項目内容
発生日2026年4月(CAMPFIREへの不正アクセス)
公表日2026年5月28日
対象組織・業界横浜DeNAベイスターズ/プロスポーツ
事象クラウドファンディングプラットフォームの侵害に伴う支援者情報の流出のおそれ
起点CAMPFIREのシステム管理用GitHubアカウントへの不正アクセス
情報源Security NEXT(2026年5月28日)

横浜DeNAベイスターズは2026年5月28日、クラウドファンディングプラットフォーム「CAMPFIRE」で実施した「日本一優勝パレード2024」プロジェクトの支援者情報が流出した可能性があると公表しました。

原因は、CAMPFIREのシステム管理用GitHubアカウントが不正アクセスを受けたことにあります。この侵害については、CAMPFIRE側が2026年4月28日に公表しており(本アーカイブでも別記事として扱っています)、球団の公表はその影響が自らの企画に及んでいたことを支援者に知らせるものです。

対象となるのは、同プロジェクトの支援者のうち、特定期間にPayPal・コンビニ払い・口座送金で決済または返金を受けた人物です。流出の可能性がある情報として、氏名、住所、電話番号、メールアドレス、口座情報などが挙げられています。件数は公表されていません。

  • 2026年4月: CAMPFIREのシステム管理用GitHubアカウントに不正アクセスが発生
  • 2026年4月28日: CAMPFIREが不正アクセスを公表
  • CAMPFIREが関係者への個別連絡を実施
  • 2026年5月28日: 横浜DeNAベイスターズが、自球団のプロジェクト支援者に影響が及ぶ可能性を公表

現時点で、不正利用などの被害報告は寄せられていないとされています。

原因は球団側のシステムではなく、利用していたクラウドファンディングプラットフォームの侵害です。CAMPFIREの公表によれば、システム管理用のGitHubアカウントに第三者による不正アクセスが発生し、ソースコードが閲覧されたほか、外部からデータベースに対して内部処理が実行された痕跡が確認されています。

球団側に設定不備や運用上の過失があったことを示す情報は公表されていません。

以下は公表された事実からの技術的な仮説であり、球団・CAMPFIREのいずれかが公表したものではありません。

決済手段によって対象範囲が分かれている点が、本件の構造を示していると考えられます。対象がPayPal・コンビニ払い・口座送金の利用者に限定されているという説明からは、これらの決済手段では返金や入金確認のためにプラットフォーム側が支援者の口座情報・連絡先を保持する必要があり、カード決済とは保持されるデータの範囲が異なっていた可能性が考えられます。つまり、侵害の深さではなく、プラットフォームがどの支援者についてどこまでのデータを保持していたかが、影響範囲を分けたという見方です。

球団の立場から見れば、この分岐は自らの管理下にありません。どの決済手段でどのデータが保持され、どこに保管されるかは、プラットフォームの実装で決まります。いずれも推測であり、公表された事実は対象となる決済手段と情報項目までです。

1. 「自社システムを持たない」は「攻撃面がない」ではない

Section titled “1. 「自社システムを持たない」は「攻撃面がない」ではない”

クラウドファンディングは、企画側がシステムを構築せずに資金調達と支援者管理を行える仕組みです。サーバもDBも自前で持たないため、一見すると攻撃面は存在しないように見えます。しかし実際には、支援者の氏名・住所・電話番号・口座情報という最も機微なデータが、自社の外側に集約されている状態です。攻撃面は消えたのではなく、契約先に移動しています。そして移動した先の防御水準は、こちらから見えません。

2. プロジェクト終了後も、データは残り続ける

Section titled “2. プロジェクト終了後も、データは残り続ける”

本件の対象は2024年の優勝パレードに関する企画の支援者です。企画そのものは終了していますが、支援者データはプラットフォーム上に残っており、2026年の侵害で影響を受けました。企画の終了と、データの終了は別です。外部プラットフォームを使う際は、企画終了後のデータ保持期間・削除手続きを事前に確認し、必要なら契約で定めておく必要があります。「終わったプロジェクト」が説明責任を伴って戻ってくることは、実際に起こります。

3. 支援者への説明主体は、プラットフォームと企画者の両方になる

Section titled “3. 支援者への説明主体は、プラットフォームと企画者の両方になる”

CAMPFIREは関係者への個別連絡を実施しています。それに加えて球団も自ら公表しました。この二重の公表は冗長ではありません。支援者にとっては「ベイスターズのパレードを応援した」という文脈で記憶されている取引であり、プラットフォーム名からの連絡だけでは自分事として認識されにくい面があります。利用者が誰との取引だと認識しているかを基準に、説明の主体を決めるべきです。

ヤグラの視点 — 攻撃面の拡張:契約で外に出したのは業務であって、責任ではない

Section titled “ヤグラの視点 — 攻撃面の拡張:契約で外に出したのは業務であって、責任ではない”

外部プラットフォームの利用は、コストと構築期間の観点で合理的な判断です。ファンクラブ、EC、予約、クラウドファンディング、フォーム——いま多くの組織が、顧客接点の相当部分を自社の外側で運用しています。この記事で言いたいのは「外部サービスを使うな」ではありません。使うことで、防御の対象が自社ネットワークの外側へ広がった事実を、資産管理に反映できているかという話です。

具体的には、次の3点を平時に把握しているかどうかで、事故時の初動が変わります。

  • どのサービスに、誰の、どの項目のデータを預けているか(決済手段ごとに保持項目が異なることは、本件が示したとおりです)
  • そのサービスからのインシデント通知が、自組織のどこに届くか(担当者個人のメールアドレスに届いて止まる構成は珍しくありません)
  • 通知を受けてから、自組織として何を公表するか(プラットフォームが公表したから自分たちは黙っていてよい、とはなりません)

とくに2点目は軽視されがちです。委託先・プラットフォームからの第一報が、退職済み担当者のアドレスや共有メールボックスの奥で滞留すると、公表の遅れがそのまま組織の説明責任になります。外部サービスの棚卸しは、サービス名とアカウントの一覧を作るだけでは足りず、「そこから悪い知らせが来たとき、誰の画面に出るか」まで含めて設計する必要があります。

なお、プラットフォーム側で起きた侵害を利用企業が技術的に検知することはできません。できるのは、自組織の攻撃面の地図に外部サービスを載せておくことと、通知が来た瞬間に動ける体制を用意しておくことです。自組織のログ側で言えば、外部サービスと連携するAPIキー・Webhook・管理者アカウントの異常な利用を継続的に監視できるかが、隣接するリスクへの備えになります。(関連: ヤグラ AI SOC

CAMPFIREによる調査が継続しており、実際にデータが持ち出されたか、対象件数はどの程度かに関する続報が注視されます。球団は支援者に対し、今後の悪用への注意を呼びかけています。氏名・住所・電話番号・メールアドレスが流出した可能性がある以上、球団やCAMPFIREを装った連絡による二次的な詐欺への警戒が必要です。

日時内容
2026-05-28初稿公開(公表日時点)