「クラファンサイトのアカウントから情報が漏れたらしいけど、自分の口座番号は大丈夫?」
「GitHubアカウントが乗っ取られただけで、なぜ22万人もの個人情報が抜かれるの?」
ボス!CAMPFIREの口座情報まで漏れたって本当でしゅか?
支援した友達に「フィッシング気をつけて」って連絡したほうがいいでしゅか?
落ち着け、チップス。事の発端はGitHubアカウント1つの侵害だ。
そこから本番DBに辿り着かれた経路を理解すれば、自社にも応用できる教訓が見えるな。
2026年4月24日、クラウドファンディング大手のCAMPFIREが、GitHubアカウントへの不正アクセスを起点に最大22万5,846件の個人情報が漏洩した可能性を公表しました。
口座情報を含む件数は8万2,465件にのぼります。
本記事では事件の経緯と、GitHubアカウントから本番システムまで侵害が拡大したメカニズム、そして同種の攻撃を防ぐためのポイントを整理します。
- 4月2日のGitHubアカウント侵害が起点となり、約3週間かけて本番DBへの侵害が判明
- 最大22万5,846件、うち8万2,465件には金融機関の口座情報が含まれる
- ソースコードに残った認証情報が侵害拡大の典型パターン、開発者アカウントこそMFA必須
支援者として登録した方は、まずフィッシング対策と他サービスでのパスワード使い回し確認から始めてください。
事件の全体像を時系列で追えば、自社のSaaS連携アカウントを見直す動機になるはずです。
目次
1.事件の全体像と漏洩した情報の中身
事件は3週間かけて段階的に被害が拡大しました。
侵入の入口は、たった1つの管理用GitHubアカウントです。
3週間で更新され続けた被害の規模
当初の発表では「ソースコードが閲覧された可能性」とされていました。
しかし、4月14日には413名分の個人情報の閲覧、4月22日には本番データベースへのアクセス痕跡、そして4月24日には最終的に22万件超の漏洩可能性へと被害が広がりました。
漏洩した情報の内訳は以下のとおりです。
| 対象 | 件数 | 主な情報 |
|---|
| プロジェクト実行者(2021年2月以降) | 約12万929件 | 氏名、住所、電話番号、口座情報 |
| PayPal決済の支援者(2021年1月〜2023年1月) | 約13万155件 | 氏名、決済関連情報 |
| サポーター登録者(2025年3月5日まで) | 1,282件 | 氏名 |
このうち口座情報を含むのは8万2,465件です。
クレジットカード情報は対象外でしたが、振込口座が紐づくユーザーへのフィッシング・なりすまし詐欺リスクは相当高いと見るべきです。
引用元: ITmedia NEWS
えっ、最初は「ソースが見られた」だけだったのに、3週間で22万件まで増えるんでしゅか…!
ふふふ。だから初動の「閲覧された可能性」だけを信じてはいけないのだ。
侵害は氷山の一角であることが多い。継続調査で本当の規模が見えてくる。
2.GitHubアカウントが本番DBへの入口になった理由
「ソースコードリポジトリが、なぜ顧客DBに繋がるのか?」
この疑問が事件の核心です。
ソースコードに残る認証情報という落とし穴
GitHubのプライベートリポジトリには、開発者が便宜的にコミットしたDB接続情報、APIキー、IAMアクセスキーなどが残っていることが珍しくありません。
カスペルスキーの調査でも、GitHub上のトークン漏洩は世界規模で繰り返し発生しています。
侵害発生時に攻撃者がまず探すのは以下のような情報です。
- 環境変数やconfigファイルに直書きされたDBパスワード
- 過去のコミット履歴に残ったAPIキーやアクセストークン
- VPNやステージング環境への接続スクリプト
- CI/CDパイプライン用の長期有効なクレデンシャル
CAMPFIREでは、4月21日に本番DBへのアクセス痕跡が確認されています。
つまり、GitHub上で得た情報を起点に内部システムへ横展開された可能性が高いと考えられます。
引用元: Kaspersky Daily
守るべきは「開発者アカウント」という最重要資産
IPAは不正ログイン対策として多要素認証(MFA)の徹底を呼びかけています。
とくに開発者のGitHubアカウントは「本番システムへの鍵束」と考えるべきで、エンドユーザー向けより厳格な保護が必要です。
最低限実施すべき対策は以下のとおりです。
- 組織配下の全開発者にハードウェアキーまたはパスキー方式のMFAを必須化
- 個人アクセストークン(PAT)に有効期限を設定し、定期ローテーション
- シークレットスキャン(GitHub Secret Scanning等)でコミット内の機密情報を自動検知
- 本番DBクレデンシャルはVault系ツールで一元管理し、ソースコードから排除
引用元: IPA 不正ログイン対策特集
うちの開発チームでも、Slackに「APIキー貼ってー」って言ってる人、いるでしゅ…
それは即やめさせろ。
シークレットの取り扱いは、文化として定着させない限り事故が止まらん。
まとめ
CAMPFIREの事案は、GitHubアカウント1つの侵害が顧客22万人規模のデータ漏洩に発展した典型例です。
口座情報まで含む被害は、フィッシング詐欺の二次被害につながりやすく、利用者側の警戒も欠かせません。
企業側で問われるのは、開発者アカウントの保護を「IT資産の中核」として再設計できているかという点です。
シークレット管理とMFA徹底は、もはやエンジニア任せにしてよい話ではありません。経営層が監督すべきガバナンステーマです。