CAMPFIREへの不正アクセス（GitHub個人用アクセストークン漏えいから業務用クラウドへ侵害、口座情報を含む225,846件の漏えいのおそれ）
公表日
クラウドファンディングの「CAMPFIRE」が不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。を受け、プロジェクトの実施者や支援者など最大225,846件の個人情報が漏えいしたおそれがあります。外部へ持ち出された跡は確認されていませんが、銀行口座の情報も対象に含まれています。
対象者は？
CAMPFIREのプロジェクトオーナー（実施者）、支援者、パートナーの一部です。対象は期間や支払い方法ごとに決まっていて、たとえば支援者はPayPalなどで支払った方や、口座への送金で返金を受けた方が含まれます。CAMPFIREのシステムで運営されていた日本サッカー協会（JFA）のクラウドファンディングの支援者も、対象に含まれる可能性があります。氏名・住所・電話番号・メールアドレス・口座情報が対象で、クレジットカード情報は含まれていません。
対象の方には、件名「【重要：CAMPFIRE】お客様情報漏えい可能性に関するお詫びとご報告」のメールが個別に送られています。対象の期間や区分は公式のお知らせで確認でき、専用のお問い合わせ窓口（0120-188-070）もあります。
いますぐできること
- CAMPFIREを名乗るメールやSMSのリンクは開かず、公式サイトや公式アプリから確認する
- 登録していた銀行口座の入出金に、身に覚えのないものがないか確認する
- 口座情報や暗証番号を聞き出そうとする電話・メールには答えない
何が起きたのか
2026年4月2日の夜、CAMPFIREのシステムを管理するためのGitHub（プログラムを保管するサービス）のアカウントに、第三者が不正にアクセスしました。会社は翌日の未明に気づいて遮断し、同じ日に公表しました。その後、4月20日に社内の業務用クラウドでも不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。が見つかり、データベースにアクセスされた跡が確認されました。会社は4月24日に、個人情報が漏えいしたおそれがあると発表しました。
なぜ起きたのか・なぜ広がったのか
従業員が発行したGitHubに入るための鍵のような情報が、個人の開発に使っていたサーバーに意図せず置かれ、第三者に使われました。犯人はGitHubの中で見られた情報から、社内の業務用クラウドに入るための情報も探し出し、その一部に入り込みました。最初に気づいてからクラウドの不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。が見つかるまでに17日かかっています。一部の場所では操作の記録（ログ）が取られていなかったため、データが見られた可能性を否定できない状態になっています。
いまの状況2026-06-02 時点
2026年5月30日に外部の専門機関による調査が終わりました。個人情報を含むデータのファイルが外へ送られた跡は見つかっていませんが、閲覧された可能性は否定できないとしています。クラウドファンディングのサービスは別の環境で動いており、改ざんなどは確認されていません。個人情報保護委員会へ報告し、警察にも相談したと公表しています。再発防止として、パスワードや鍵などの秘密情報の管理、権限の見直し、記録の取り方の改善など6つの分野の対策を3か月で整えるとしています。
企業として考えたいこと
社員が仕事用のパスワードや鍵となる情報を、個人のパソコンやサーバーに置いていないと言い切れるでしょうか。もし1つが漏れたとき、そこからどこまで入られてしまうかを把握しているでしょうか。
技術的な要約
2026年4月2日22時50分頃、CAMPFIREのシステム管理用GitHubアカウントが第三者に不正アクセスされ、同社は4月3日未明に検知・遮断して同日公表した。起点は、従業員が発行したGitHubの個人用アクセストークン（PAT）が個人開発で使っていたサーバー上に意図せずアップロードされ、不正利用されたことである。攻撃者はGitHub上で閲覧できた情報から社内業務用クラウド環境の認証情報を探し出して一部の管理領域に侵入し、同社は4月20日にクラウド側の不正アクセスを検知、4月21日にデータベースへのアクセスと内部処理の痕跡を確認した。4月24日にプロジェクトオーナー・支援者等の氏名・住所・電話番号・メールアドレス・口座情報について重複除外後225,846件の漏えいのおそれ（口座情報ありは区分合計で82,465件）を公表、4月27日に内訳を精査した。5月30日にフォレンジック調査が完了し、6月2日の調査結果では個人情報を含むデータファイルの外部転送痕跡はないが、一部領域でログが取得されておらず閲覧の可能性は否定できないとした。クレジットカード情報は対象外で、サービス提供基盤は別環境のため改ざん等は確認されていない。
攻撃の分類
- 侵入口
- 認証情報窃取・流用公表で確認公式（6/2調査結果）：『従業員が発行したGitHub認証情報が、個人開発で利用していたサーバー上に意図せずアップロードされ、第三者に不正利用された』。第二報（4/14）の再発防止策に『個人用アクセストークンへの依存の見直し』とあり、漏えいした認証情報はGitHubの個人用アクセストークン（PAT）と読める（classic/fine-grained の別、スコープ、有効期限は非公表）。攻撃者はGitHubで閲覧可能になった情報をもとに『社内業務用クラウド環境に関連する認証情報』を探索・取得し、そのクラウドの一部管理領域に侵入した（2段階の侵害）。クラウド事業者名（AWS/GCP等）、認証情報の種類（アクセスキー、サービスアカウントキー等）、それがリポジトリ内のどこ（コード、設定ファイル、CI設定、Issue等）にあったかは非公表。個人開発サーバーがどのように露出していたか（公開リポジトリ、公開Webサーバー、マルウェア感染等）も非公表。
- 脆弱性
- CVE 非公表公表で確認GitHub 個人用アクセストークン（従業員発行）ソフトウェアの脆弱性ではなく認証情報管理の不備。業務用のPATが個人開発サーバーに置かれ、第三者が取得・利用した（公式）。対応としてPATから権限を限定した認証方式へ移行、組織の既定アクセス権限を見直し。CVE 非公表公表で確認GitHubリポジトリ内に存在した業務用クラウドの認証情報・APIキーGitHub上の情報から業務用クラウドの認証情報が探索・取得された（公式）。6/2では、攻撃者に取得されたものとして『特定クラウド環境の認証情報・APIキー』を挙げる。4/6には『優先度の高いコード脆弱性』を修正し権限の強いシステムユーザーの権限を整備したとするが、コード脆弱性の内容は非公表。
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- なし サービス提供基盤は社内業務用クラウドとは別環境で運用されており、CAMPFIREのサービス停止・改ざんは公表されていない。社内業務用クラウドの利用は安全確認のため一時停止（6/2公表）。波及先のJFAは、4/25開始予定だった『SAMURAI BLUE 祭』支援のクラウドファンディングを延期した（報道）。
- データ
- おそれ上限 225,846確定 —件氏名住所電話メール口座従業員情報取引先情報いずれも『漏えいのおそれ』で、流出確定ではない。6/2調査結果：個人情報を含むデータファイルの外部転送痕跡はなく、攻撃目的は各種認証情報の取得との見解だが、一部ログ未取得の領域があり閲覧可能性は否定できない。探索の過程で個人情報を含む1件のデータがクエリ結果として出力された。【4/24公表】オーナー120,929件（口座あり66,013）、支援者130,155件（口座あり16,452）、パートナー1,282件（氏名のみ）、区分合計252,366件・重複除外225,846件。口座ありの区分合計82,465件（66,013＋16,452、当方計算。『約8.2万件』はこの値）。【4/27精査・6/2】オーナー（4/9までの利用者の一部）108,784件（口座あり53,868→6/2では53,869）、支援者118,010件（口座あり4,307。2021/1/1〜2026/4/19のPayPal決済、2022/1/3〜2023/4/24のこんど払い、2022/1/6〜2026/3/5の口座送金返金）、パートナー（2025/3/5までの登録）1,282件（氏名）、区分不明（2020年中にマイページで口座情報を編集）10,521件（口座情報のみ）。重複除外225,846件は変わらず。口座ありの区分合計は68,697件（6/2値、当方計算、区分間重複の可能性あり）。別途、GitHub上で閲覧可能だった開発業務従事者（退職者・業務委託先含む）413名の氏名・メール、取引先1社の氏名・連絡先（4/14公表）。クレジットカード情報は含まれない。
- 波及先
- 1 団体
- 日本サッカー協会（JFA）：CAMPFIREのシステム上で運営する『JFAクラウドファンディング』の支援者情報が対象に含まれる可能性があるとして4/25に謝罪、『SAMURAI BLUE 祭』のクラウドファンディングを延期（報道）
- 金銭影響
- —
- サプライチェーン
- CAMPFIREのクラウドファンディング基盤を利用して自団体のクラウドファンディングを運営していたJFAが、自団体の支援者情報も漏えいのおそれの対象に含まれるとして公表・謝罪した（JFA公表、報道で確認）。他にCAMPFIRE基盤を使う提携事業者への波及は公表されていない。なお本件はソフトウェアサプライチェーン攻撃ではなく、同時期のnpm（axios等）サプライチェーン攻撃との関係は、本調査で参照できた公式発表・報道では言及されていない。
時系列
技術解説
攻撃の構造：個人用トークン → リポジトリ → クラウド認証情報の2段階侵害 事実
公式発表に基づくと、侵害は2段階で進んだ。第1段階は、従業員が発行したGitHubの認証情報（第二報の対策記述から個人用アクセストークンと読める）が、業務と無関係な個人開発用サーバーに意図せずアップロードされ、第三者に取得されたこと。攻撃者は4月2日22時50分頃、このトークンでシステム管理用のGitHub組織にアクセスし、ソースコード等を閲覧した。第2段階では、GitHub上で閲覧できた情報から社内業務用クラウド環境の認証情報を探索・取得し、そのクラウドの一部管理領域に侵入した。6/2の調査結果は、攻撃者が取得したものとして『特定クラウド環境の認証情報・APIキー』『個人情報を含まない一部データファイル』『テーブル名・構成情報』を挙げ、攻撃目的は各種認証情報の取得だったとの見解を示している。顧客サービスの提供基盤は別環境で、改ざん等は確認されていない。クラウド事業者名・認証情報の種類・リポジトリ内での所在は公表されていない。
検知から17日後にクラウド侵害が見つかった 解釈
4月3日未明の検知時、同社はGitHubの関連アカウントを除外し認証情報を差し替え、第1報では『個人情報や機密情報の流出は確認されていない』とした。しかしクラウド側の不正アクセスを検知したのは4月20日、データベースへのアクセス痕跡の確認は4月21日で、第1報の説明は約3週間後に大きく覆った。公表資料はクラウドへの侵入が4月3日より前か後かを明らかにしていない。もし後であれば、GitHub上に残っていたクラウド認証情報が初動で失効されていなかったことになり、前であれば、初動時点でリポジトリ内のシークレットを起点とした横展開の調査が及んでいなかったことになる。いずれにせよ、ソース管理基盤の侵害を『ソースコードの閲覧』として扱い、リポジトリ内のすべてのシークレットを漏えい済みとみなして即時ローテーションしなかったことが、被害範囲確定の遅れにつながったと解釈できる。
件数の推移と『おそれ』の中身 事実
4月24日の第四報はオーナー120,929件（口座あり66,013）、支援者130,155件（口座あり16,452）、パートナー1,282件、重複除外225,846件とした。口座ありの区分合計は82,465件で、報道等の『口座情報約8.2万件』はこの値に当たる。4月27日の第五報では対象期間を精査し、オーナー108,784件（口座あり53,868）、支援者118,010件（口座あり4,307）に縮小する一方、2020年中に口座情報を編集した区分不明の10,521件（口座情報のみ）を追加したが、重複除外225,846件は変えていない。6/2の最終的な結論は、個人情報を含むデータファイルの外部転送痕跡はないが、一部領域でログが取得されておらず操作を直接確認できないため閲覧の可能性は否定できない、というもの。探索の過程で個人情報を含む1件のデータがクエリ結果として出力されたことも明記された。漏えい確定ではなく、ログの欠落によって『おそれ』を否定しきれない構図である。
なぜ個人開発サーバーに業務トークンがあったのか（推測） 解釈
公式は『意図せずアップロード』と述べるのみで、具体的な経路は示していない。よくあるパターンとしては、業務端末と個人開発で同じホームディレクトリや設定（~/.gitconfig、~/.git-credentials、GH_TOKEN を書いた .env やシェル設定、gh CLI の hosts.yml）を共有したまま dotfiles やプロジェクト一式を個人サーバーへ同期・デプロイした、あるいは個人プロジェクトのCIやデプロイ設定に業務用PATを流用した、といった経路が考えられる。classic PATは発行ユーザーが所属する全Organizationに対し同じスコープで作用するため、個人用途で使ったトークンがそのまま業務Organizationの鍵になる。同社が対策として『個人用アクセストークンへの依存を見直し、権限を限定した認証方式へ移行』『組織内の既定アクセス権限の見直し』を挙げていることは、この性質が被害を広げたことを示唆する。いずれも推測であり、トークン種別やスコープは公表されていない。
公表の評価：第1報から6月の調査結果まで7本 解釈
CAMPFIREは4/3第1報、4/14第二報、4/22第三報、4/24第四報、4/27第五報、4/28窓口開設、6/2調査結果と、判明事項を段階的に公表した。4/24以降は対象期間・区分・口座情報の有無まで件数を開示し、6/2には日付つきの経緯、侵入経路、攻撃者が取得したもの、ログが欠けていた事実、6領域の再発防止策を示しており、開示の具体性は高い。一方、第1報の『個人情報や機密情報の流出は確認されていない』という表現は、調査が及んでいない段階での否定的な言い回しで、後にクラウド侵害が判明したことで結果的に安心材料として機能してしまった。また個人情報保護委員会への報告は明記されているが、警察への相談は4/24の発表にのみ記載があり、6/2の調査結果には記載がない。
対応
- 封じ込め
- 4/3未明に関連アカウントをGitHub組織から除外し認証情報を差し替え。4/6に優先度の高いコード脆弱性を修正、高権限システムユーザーの権限を整備。4/20にクラウド側の不正利用アカウント・リソースを停止・無効化、不正作成リソースを削除。社内業務用クラウドの利用を安全確認のため一時停止。4/21に外部専門機関へ支援要請、5/30フォレンジック完了。体制面では認証情報の利用ルール見直し、PATから権限を限定した認証方式への移行、組織既定権限の見直し、監査ログ・アラート強化、トリアージ体制整備、脆弱性診断ツール導入。再発防止策として、秘密情報管理、権限・認証・認可、情報の所在・配置ルール、検知・防御の自動化とログ最適化、開発環境の防護柵、コード脆弱性の早期検知の6領域を3か月で整備し、外部専門機関の評価を受けるとした。
- 公表の仕方
- 4/3第1報（GitHub不正アクセス、個人情報流出は未確認）→4/14第二報（従業員等413名・取引先1社の情報が閲覧可能）→4/22第三報（顧客情報管理システムに痕跡）→4/24第四報（225,846件の漏えい可能性、対象者へ個別メール）→4/27第五報（範囲の詳細）→4/28専用窓口→6/2調査結果（侵入経路・調査結論・再発防止策）。対象者には件名『【重要：CAMPFIRE】お客様情報漏えい可能性に関するお詫びとご報告』のメールを送付。
- 当局対応
- 個人情報保護委員会：4/14に報告、4/24に続報提出
- 警察：4/24時点で相談中と公表
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 業務用GitHub PATが個人の開発環境に持ち出され、外部に露出した | Organization設定でclassic PATのアクセスを禁止し、fine-grained PATは承認制・対象リポジトリ限定・有効期限90日以内に制限する。CIや自動化はGitHub App（インストール単位の短命トークン）またはOIDCに置き換え、人の長期トークンを業務経路から外す。SAML SSOを必須にしてトークンをSSO認可制にし、退職・異動時に一括失効できるようにする。 |
| リポジトリ内のクラウド認証情報・APIキーが、GitHub侵害からクラウド侵害への踏み台になった | GitHub Secret ScanningとPush Protectionを全リポジトリで有効化し、gitleaks/trufflehogで履歴も含めて定期スキャンする。クラウド認証はGitHub Actions OIDC→AWS IAMロール/GCP Workload Identity Federationに移行し、長期アクセスキーやサービスアカウントキーをリポジトリ・Secretsに置かない。 |
| 初動でリポジトリ内シークレットを『漏えい済み』として扱わず、クラウド侵害の検知が17日後になった | ソース管理基盤の侵害時のランブックに『アクセス可能だった全リポジトリ（履歴・Actions Secrets・Issue/Wiki含む）のシークレット棚卸し→即時ローテーション→各クラウドの監査ログ（CloudTrail等）で該当キーの使用履歴を遡及調査』を初動24時間以内の必須手順として組み込む。GitHub監査ログ（git.clone、repo.download_zip、トークン認証元IP）をSIEMに常時転送する。 |
| 一部領域でログが取得されておらず、閲覧の有無を確定できなかった | 顧客データを扱うDB・データウェアハウス・管理コンソールのデータアクセスログ（例：CloudTrailデータイベント、Cloud Audit LogsのData Access、DB監査ログ）を有効化し、改ざんされない別アカウントのストレージに1年以上保持する。保持状況を年1回の机上演習で確認する。 |
| 1つの認証情報で業務用クラウドの広い範囲を操作できた | 業務用クラウドの管理権限を用途別ロールに分割し、本番データへのアクセスはJust-In-Timeの昇格（承認つき・時間制限）に限定する。個人情報を含むテーブルは別プロジェクト/アカウントに分離し、クエリ件数・エクスポートに対するアラートを設定する。 |
| 顧客データを取引先（JFA等）向け基盤と共有しており、波及先の公表対応が必要になった | プラットフォームを他団体に提供する場合、テナント別の対象者抽出ができるデータ設計にし、契約に通知期限（例：把握から72時間以内）と連絡窓口を明記しておく。 |
自組織などでの確認項目
- あなたの会社のエンジニアが個人PCや個人サーバーに業務用GitHubトークンを置いていないと、何をもって言えるか。Organizationの設定でclassic PATを禁止しているか。
- GitHub Organizationが侵害されたと仮定したとき、リポジトリ・Actions Secrets・Issueに含まれるクラウド認証情報を何時間で洗い出し、すべて失効できるか。その手順書はあるか。
- 顧客データのDBに対する『誰が・いつ・何件読んだか』のログは取得・保全されているか。ログがなければ、漏えいの有無を否定できず『おそれ』として全件公表することになるが、その覚悟はあるか。
- 初報で『個人情報の流出は確認されていない』と書くべきか。調査が及んでいない範囲をどう表現すれば、後から覆っても信頼を失わないか。
未解明点
- 漏えいしたGitHub認証情報の種類（classic/fine-grained PAT、スコープ、有効期限、SSO認可の有無）と、個人開発サーバー上でどのように露出・取得されたか
- 業務用クラウドの事業者名、取得された認証情報の種類（アクセスキー、サービスアカウントキー等）とリポジトリ内での所在
- 業務用クラウドへの侵入が4/3の検知・認証情報差し替えより前か後か（GitHub上のクラウド認証情報を初動で失効しなかったのか）
- ログが取得されていなかった領域の範囲と理由
- 攻撃者の正体・目的（各種認証情報の取得が目的との見解の根拠）、他社への同種攻撃との関連
- ScanNetSecurityが報じた5/11付『個人情報漏えい可能性の経緯と対応状況について』の公表内容（本調査では原文を確認できず）
出典
- 1CAMPFIRE2026-04-03公式本文確認済
- 2CAMPFIRE2026-04-14公式本文確認済
- 3CAMPFIRE2026-04-22公式本文確認済
- 4CAMPFIRE2026-04-24公式本文確認済
- 5CAMPFIRE2026-04-27公式本文確認済
- 6CAMPFIRE2026-04-28公式本文確認済
- 7CAMPFIRE2026-06-02公式本文確認済
- 8ScanNetSecurity2026-04-20報道本文確認済
- 9ScanNetSecurity2026-05-12報道本文確認済
- 10ScanNetSecurity2026-06-11報道本文確認済
- 11セキュリティ対策Lab（Rocket Boys）2026-04-08報道本文確認済
- 12セキュリティ対策Lab（Rocket Boys）2026-04-27報道本文確認済
- 13セキュリティ対策Lab（Rocket Boys）2026-06-04報道本文確認済
- 14セキュリティ対策Lab（Rocket Boys）2026-04-24報道本文確認済
- 15innovaTopia2026-05-01報道本文確認済
- 16電ファミニコゲーマー2026-06-02報道本文確認済
- 17日本サッカー協会2026-04-25公式未確認
- 18ScanNetSecurity2026-05-22報道本文確認済