🔥

CAMPFIRE 22.5万人情報漏えい — GitHub不正アクセスから何を学ぶか

に公開
GitHub
Security
incident
pat
Supply Chain
tech

はじめに

2026年4月24日、クラウドファンディング国内最大手の 株式会社CAMPFIRE が、最大 22万5846人分 の個人情報が漏えいした可能性があると発表しました。プロジェクト実行者の口座情報や支援者の住所など、極めてセンシティブな情報が対象です。

事件の起点は GitHubアカウントへの不正アクセス。「GitHubが侵害されただけでなぜ顧客情報が？」と思った方は多いのではないでしょうか。本記事では、公開情報から事件の経緯と攻撃の流れを整理しつつ、エンジニアとして組織を守るために今すぐ見直すべきポイントをまとめます。

何が起きたか — タイムライン

CAMPFIREが段階的に公表してきたプレスリリースをもとに、時系列を整理します。

日付 公表内容
2026年4月2日 22:50頃 GitHubアカウントへの不正アクセスが発生
2026年4月3日 第一報：ソースコードの一部が閲覧された可能性を公表
2026年4月14日 第二報：取引先1先と開発関係者413名分の氏名・メールアドレスが閲覧可能だったことを確認
2026年4月21日 顧客情報管理システムへの不正アクセス痕跡を確認
2026年4月22日 第三報：データベースへのアクセス痕跡を公表
2026年4月24日 最大22万5846人分の個人情報漏えいの可能性を発表
2026年4月28日 専用問い合わせ窓口の設置予定

つまり初報から最終発表まで 約3週間で被害規模が約500倍以上に膨らんだ ということです。インシデント対応において、初動の見立てがいかにアテにならないかを示す典型例と言えます。

漏えいの可能性がある情報

4月24日の発表によれば、対象は大きく3つのカテゴリに分かれます。

(1) プロジェクト実行者：約12万929件

  • 対象期間：2021年2月以降にCAMPFIREでクラウドファンディングを実行した方
  • 含まれる情報：氏名、住所、電話番号、金融機関口座情報 など

プロジェクト実行者は、調達した資金を受け取るために口座情報をプラットフォームに登録します。ここが流出した影響は支援者よりも深刻です。

(2) 支援者：約13万155件

以下のいずれかに該当する支援者が対象です。

  • 2021年1月以降にPayPal決済を利用した方
  • 2022年1月〜2023年1月に後払いサービス「こんど払い」を利用した方
  • 2022年1月〜2026年3月にCAMPFIREから口座送金で返金を受け取った方

含まれる情報：氏名、住所、口座情報など。

(3) 登録ユーザー：1,282件

  • 対象期間：2025年3月5日までに登録したユーザー
  • 含まれる情報：氏名

含まれていないとされる情報

  • クレジットカード情報 は対象外
  • 現時点で 不正利用の被害やデータダウンロードの形跡は確認されていない

ただし「形跡が確認されていない」ことと「されていない」ことは違います。攻撃者がログを消した可能性、別経路で持ち出した可能性は残るため、対象者は当面、口座取引の監視や不審メールへの警戒を続ける必要があります。

攻撃の流れ — GitHubから顧客DBへ

公開情報を整理すると、攻撃の流れは概ね以下のように推定されます。

[1] GitHubアカウント侵害
       ↓ （ソースコード閲覧）
[2] リポジトリ内の認証情報・接続情報を取得
       ↓
[3] 顧客情報管理システムへ横展開
       ↓
[4] DBから個人情報を参照可能な状態に

CAMPFIREが第二報で 「漏えいした認証情報の無効化・再発行」 や 「個人用アクセストークンへの依存を見直し、権限を限定した認証方式への移行」 を再発防止策として挙げていることから、攻撃の起点は 個人用アクセストークン（Personal Access Token, PAT）の漏えい であった可能性が高いとみられます。

Classic PATが抱える構造的なリスク

GitHubのPATには2種類あります。

項目 Classic PAT Fine-grained PAT
リリース時期 古くから提供 2022年〜（GAは2025年）
スコープ粒度 粗い（repo で全リポジトリ） リポジトリ単位・権限単位で詳細指定可能
対象範囲 所属する全Org・全リポジトリ 単一のユーザーまたはOrgに限定
有効期限 無期限も設定可能 最大1年（必須）
監査・ポリシー 限定的 Org承認フローあり

Classic PATは、repo スコープを付けると その人がアクセスできる全リポジトリへの読み書き権限を1つのトークンで持ってしまう という構造的な弱点があります。CIでの自動化や個人開発のスクリプトで気軽に発行されたClassic PATが、実は本番環境のソースコードへのフルアクセス権を持っている、というケースは珍しくありません。

漏えい元は今回明示されていませんが、PATが平文でメモやチャット、ローカルの設定ファイルに残っていれば、端末マルウェア感染やフィッシング、二次的な情報源（スクリーンショット、画面共有、過去のチケット）などから抜き取られる可能性は十分にあります。

なぜ「ソースコード閲覧」で顧客DBまで届くのか

「GitHubはコードを置く場所であって、個人情報は置いてない」と思いがちですが、現実のリポジトリにはコード以外の情報も大量に存在します。

  • 環境変数のサンプル（.env.example）に書かれた接続先ホスト名
  • インフラ構成図やシーケンス図、設計ドキュメント
  • マイグレーションファイル（DB構造そのもの）
  • Issue・PRのコメント（障害対応の手順、踏み台ホストの名前など）
  • 過去のコミット履歴に誤って混入した秘密情報
  • CI/CDワークフロー定義（接続先・ロール名・Secrets参照キー）

特に最後の「過去のコミットへの秘密情報混入」は厄介です。git rm してコミットしても、履歴を書き換えない限り コミット履歴をたどれば誰でも閲覧できてしまう ためです。トークンをコミットしてしまった場合、そのトークン自体を即時失効させない限り、そのリポジトリへのアクセス権を持つ人物には永久に渡り続けます。

つまり「ソースコードを見られた」は、現代の開発組織においては 「インフラの地図と鍵束の一部を見られた」 に近いということです。

過去のCAMPFIREの事案

CAMPFIREは過去にも個人情報関連のインシデントを起こしています。

  • 2020年2月：アンケートフォームの不具合により、回答後に表示される特定リンクから他者の回答（最大884名分のメールアドレス等）が閲覧可能になっていた

2020年の事案は技術的には軽微なものでしたが、今回は規模も性質もまったく違います。同社は2024年に「安全性向上に関する取り組み」も公表しており、それでも今回の侵害が発生したことを考えると、「やっている」と「やり切れている」のあいだには深い谷がある ことを再認識させられます。

エンジニアが今すぐ見直すべき5つのポイント

CAMPFIREの事案は他人事ではありません。GitHubを業務で使っている組織なら、以下を点検しましょう。

1. Classic PATの棚卸しと廃止

組織内で発行されているClassic PATを洗い出します。GitHub Enterprise / Organizationの監査ログ（personal_access_token 関連イベント）から把握できます。

# GitHub CLI で自分のPATを確認（Webからのほうが確実です）
gh auth status

# Org管理者は Settings > Personal access tokens から組織で使われているPATを確認

棚卸ししたPATは、原則として以下に置き換えます。

  • CI/CDでの利用 → GitHub Actionsの GITHUB_TOKEN または GitHub Apps
  • 外部サービスからの利用 → Fine-grained PAT（最小権限・短期有効期限）
  • 個人の自動化 → Fine-grained PAT、または gh CLI のOAuth Device Flow

2. クラウド側の認証は OIDC 連携へ

GitHub Actions から AWS / GCP / Azure を操作する場合、長期クレデンシャルをSecretsに置かない のが鉄則です。OpenID Connect（OIDC）連携を使えば、ワークフロー実行ごとに短期トークンを発行できます。

# AWS との OIDC 連携の例
permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-role
          aws-region: ap-northeast-1

これだけで「漏えいすると致命的なクラウドの長期キー」をリポジトリから消せます。

3. シークレットスキャンとプッシュ保護の有効化

GitHubの Secret Scanning と Push Protection は、無料リポジトリでも有効化できるようになりました。コミット時にトークンらしき文字列を検出してブロックします。

  • Settings > Code security > Secret scanning：ON
  • Push protection：ON
  • Secret scanning for partner patterns：ON

すでに過去のコミットに混入している可能性があるなら、gitleaks や trufflehog で履歴全体をスキャンします。

# gitleaks による履歴スキャン
gitleaks detect --source . --log-opts="--all"

# trufflehog による履歴 + 検証付きスキャン
trufflehog git file://. --only-verified

検出されたらトークン自体を即座に失効させます。コミットを消してもダメで、必ず発行元（GitHub、AWS、Stripe等）でローテーションするのが原則です。

4. 二要素認証と Device の信頼境界

PATが漏えいしてもアカウント自体に2FAがかかっていれば被害は限定できます。Organizationでは以下を強制します。

  • Require two-factor authentication for everyone in the organization：ON
  • Require SSO（GitHub Enterprise Cloudの場合）
  • IP allow list：可能ならON

PATは2FAをバイパスしてしまう経路です。だからこそ、PAT発行ポリシーを絞り込む必要があります。

5. サードパーティ統合と Webhook の点検

GitHubの Settings > Applications > Authorized OAuth Apps / GitHub Apps を見て、心当たりのない連携や、退職者が連携した個人ツールが残っていないか定期的に棚卸しします。攻撃者はPATだけでなく OAuth Appの認可 を経路にすることもあります。

インシデント対応のリアルな教訓

今回のCAMPFIREの対応からは、運用面での学びも多くあります。

段階的な公表は信頼を毀損しうる

  • 4月3日：「ソースコードが閲覧された可能性」
  • 4月14日：「413名の個人情報が閲覧可能だった」
  • 4月22日：「DBへの不正アクセス痕跡」
  • 4月24日：「最大22.5万人分」

各段階の公表は誠実な対応である一方、「結局どこまで広がるんだ」という不安を毎回利用者に与える という側面もあります。インシデント対応は「最初に最悪のシナリオまで保守的に開示し、調査が進むにつれて絞り込む」ほうが、ステークホルダーへの心理的負担は小さいことが多いです。

これは責めるべきものではなく、調査が進まない限り言えないことは確かにあります。ただ、自社で対応する側に回ったときは、「次に何が判明したらどう公表を更新するか」を最初に決めておく ことの重要性を意識したいところです。

ソースコード閲覧 ＝ インフラ調査開始

「ソースコードを見られた可能性がある」と判明した時点で、もう顧客DBが侵害されている前提で動く べきです。

  • 全PAT・トークン・SSH鍵の即時ローテーション
  • 過去N日分のDB監査ログ・クラウド監査ログの精査
  • 接続元IPの異常検知（普段使われない国・時間帯）
  • リポジトリに含まれるすべてのSecretsの再発行

これを 判明から24時間以内 に走らせきれるかどうかが、被害を「ソースコード閲覧で済む」か「DBまで抜かれる」かの分かれ目になります。

まとめ

CAMPFIREの事案は、GitHubアカウント1つの侵害が顧客22.5万人分の個人情報漏えいに直結しうることを示しました。

  • GitHubは「コード置き場」ではなく インフラの地図と鍵束 が眠る場所
  • Classic PATは構造的にスコープが粗く、漏えい時の被害が大きい
  • Fine-grained PAT / GitHub Apps / OIDC 連携 への移行が現代のベースライン
  • インシデント発覚時は「ソースコード閲覧」を最終ゴールとせず、DB侵害前提で動く

自分の組織で同じ事が起きたら、明日の朝まで何時間で全PATをローテーションできるでしょうか。一度そのシナリオで走ってみることを強くおすすめします。

参考記事・データ

Discussion