対象:CAMPFIREでプロジェクトを立ち上げた人・支援した人・返金を受け取った人・パートナーとして登録した人と、GitHubやクラウドを業務で使っている開発者・運用者。本記事は株式会社CAMPFIREの公式発表にもとづく解説で、攻撃手順は扱いません。
利用者が今やること
自分が対象かを確かめる——個別メールの件名で判断できる
同社は2026年4月24日から、対象者の登録メールアドレスに件名「【重要:CAMPFIRE】お客様情報漏えい可能性に関するお詫びとご報告」で個別に連絡しています。対象は次のとおりです。
- 2026年4月9日までに利用したプロジェクトオーナー・コミュニティオーナーの一部
- PayPal決済(2021年1月1日〜2026年4月19日)・こんど払い(2022年1月3日〜2023年4月24日)を使った支援者
- 口座送金で返金を受け取った支援者(2022年1月6日〜2026年3月5日)
- 2025年3月5日までに登録したパートナー
- 2020年にマイページの口座情報を編集した人
メールが見当たらなくても、この条件に当てはまるなら以下を進めてください。
『返金』『振込先の確認』を名乗る連絡のリンクを開かない
漏えいのおそれがあるのは氏名・住所・電話番号・メールアドレス・口座情報です。「返金手続きのため口座を再登録」「支援金の振込先を確認」といった連絡が来ても、本文のリンクは開かず、必要ならブックマークや自分で入力したアドレスからCAMPFIREにログインして確認します。同社は、電話やメールで暗証番号を尋ねることは一切ないとしています(見分け方は フィッシングとは)。
口座の明細を確認する
同社は、漏えいした可能性のある口座情報だけでは、口座から現金を引き出したり振り込んだりはできないと説明しています。そのうえで、明細に身に覚えのない取引があれば、すぐに金融機関か同社の窓口に相談するよう案内しています。ネットバンキングを使っているなら、入出金の通知メールやアプリ通知を有効にしておくと、確認の手間が減ります。
代金引換の不審な郵便物を受け取らない
住所が含まれているため、同社は頼んだ覚えのない代金引換の郵便物を送りつける詐欺にも注意するよう呼びかけています。受け取る前に、差出人と中身に心当たりがあるかを確認してください。
同じパスワードを使っている他のサービスを変える
同社は、他社サービスで同じメールアドレスとパスワードを使っている場合、念のため変更するよう呼びかけています。漏えい対象の項目にパスワードは挙がっていませんが、使い回しを解消する機会にしてください。棚卸しは パスワードマネージャー に任せるのが現実的です。
プロジェクトオーナーは、チームにも同じ注意を回す
法人や団体でプロジェクトを運営している場合、支援金の振込先や審査を装うメールが担当者に届く可能性があります。振込先の変更などはCAMPFIREの管理画面で直接確認する、メールの指示だけで操作しない、というルールをチームで共有しておきます。
困ったときは同社の専用窓口 0120-188-070(10時〜19時、7月以降は平日のみ)、詐欺の被害や懸念があれば警察相談専用電話 #9110に相談できます。
何が起きたのか(CAMPFIREの発表より)
同社は2026年4月3日の第一報から6月2日の調査結果報告まで、複数回に分けて公表しました。以下はすべて同社の公式発表に記載された内容です。
2026年4月2日 22時50分頃
システム管理に使用しているGitHubアカウントに第三者による不正アクセスがあり、一部のソースコードが閲覧された可能性が判明(第一報の記載)。4月3日
GitHubの一部リポジトリへの不審な操作を検知し、関連アカウントの除外と認証情報の差し替えを実施。第一報を公表(この時点で個人情報の流出は確認されていなかった)。4月7日
GitHub認証情報の漏えい原因を特定。4月14日
第二報。GitHubアカウントから、取引先1先の氏名・連絡先と、開発業務の従事者413名の氏名・メールアドレスが閲覧可能だったと公表。個人情報保護委員会へ報告。4月20日
社内業務で利用するクラウド環境への不正アクセスを検知し、不正利用されたアカウントとリソースを停止・無効化。4月22日〜24日
第三報で顧客情報を管理するシステムの一部に不正アクセスの痕跡を公表。第四報(24日)で漏えいのおそれがある範囲(対象ユーザーの重複を除き225,846件)を公表し、対象者への個別連絡を開始。4月27日・28日
第五報で対象範囲の内訳を精査して公表。28日に専用の問い合わせ窓口を開設。5月30日・6月2日
外部専門機関のフォレンジック調査が完了(5月30日)。6月2日に調査結果と再発防止策を公表。
- プロジェクトオーナー・コミュニティオーナーの一部
- 氏名、住所、電話番号、メールアドレス、口座情報。108,784件(口座情報を含むもの53,869件)
- 支援者の一部
- 氏名、住所、電話番号、メールアドレス、口座情報。118,010件(口座情報を含むもの4,307件)
- パートナー
- 氏名。1,282件
- 区分不明(会員登録段階など)
- 2020年にマイページの口座情報を編集した人の口座情報。10,521件
- その他
- 開発業務の従事者に関する氏名とメールアドレス413件が閲覧可能だった
- クレジットカード情報
- 含まれていない
- フォレンジック調査の結果
- 特定のクラウド環境に保管されていた認証情報とAPIキー、個人情報を含まない一部のデータファイル、テーブル名と構成情報が取得された。探索の過程で個人情報を含む1件のデータがクエリ結果として出力された。個人情報を含むデータファイルが外部へ転送された痕跡は確認されていない
- 同社の判断
- 一部にログが取得されておらず操作を直接確認できない領域があるため、閲覧された可能性は否定できない
- 二次被害
- 公表時点で、情報の不正利用による被害は報告されていない
開発者・運用者への教訓:GitHubのトークンから社内クラウドまで
同社の6月2日の報告は、経緯と原因をかなり具体的に公表しています。下の図は、同社の説明にそって経路を並べ、各段階で被害を防ぐ・小さくするための設定を右に置いたものです。
① 従業員が発行したGitHub認証情報
個人開発用のサーバー上に意図せずアップロード
↓→
組織設定で古い形式のトークンを禁止、有効期限の上限
② 組織のリポジトリ
一部ソースコードと、従事者413名の情報が閲覧可能
↓→
既定の権限を最小に、リポジトリに個人情報を置かない
③ GitHub上の情報からクラウドの認証情報へ
↓→
長期のクラウドキーを置かない(短期の認証へ)
④ 社内業務用クラウドの一部管理領域
認証情報・APIキー・テーブル名などが取得された
↓→
監査ログを全領域で取得し、普段と違う操作に通知
⑤ 顧客情報 225,846件(対象ユーザーの重複除外)に漏えいのおそれ
↓→
本番以外にある顧客情報の棚卸し
同社によれば、サービスは今回不正アクセスが確認されたクラウド環境とは別の環境で運用されており、サービス提供基盤への不正利用や改ざんは確認されていません。それでも顧客情報に漏えいのおそれが生じたのは、社内業務用のクラウドから顧客情報にアクセスできたからです。
同社は、当該の認証情報は本来、会社の管理下の環境でだけ扱われ、必要最小限の権限に限定されるべきものだったとし、認証情報の管理と権限設計の仕組み・運用ルールが十分でなかったと説明しています。同社がすでに実施した対策として挙げているのは次のとおりです。
- 個人用アクセストークンへの依存を見直し、権限を限定した認証方式へ移行
- 組織内の既定のアクセス権限の見直し
- 監査ログの取得とアラート通知の強化
- ソースコードの脆弱性診断ツールの導入など
同じことを自分の組織でやるなら、最初の手は次の3つです。
GitHubの組織設定で、個人用アクセストークンの方針を決める
GitHubでは組織のオーナーが、組織の Settings の「Personal access tokens」で次を決められます。
- 古い形式のトークン(personal access token (classic))で組織のリソースにアクセスさせない
- fine-grainedトークン(アクセスできるリポジトリや権限を細かく指定できる新しい形式)を管理者の承認制にする
- トークンの有効期限の上限
業務用のトークンが個人の端末やサーバーに置かれることを完全には防げない以上、置かれても短期間で使えなくなる、アクセスできる範囲も狭い状態にしておくのが現実的な備えです。
クラウドの長期キーをリポジトリの近くに置かない
同社の説明では、第三者はGitHub上で閲覧できた情報をもとにクラウドの認証情報を探索・取得しました。GitHub ActionsからクラウドへデプロイするならOpenID Connect(OIDC)による短期の認証(実行のたびに一時的な認証情報を発行する方式)に切り替え、リポジトリや設定ファイルに長期のアクセスキーを置かないようにします。
まず過去の履歴を含めて秘密情報を洗い出し、見つかったキーは無効化・再発行します。手順は gitleaksでコミット前に秘密情報を検出する で解説しています。秘密情報を含むpushをGitHub側で止める仕組み(push protection)は、公開リポジトリなら無料で、非公開リポジトリでは有償の機能(GitHub Secret Protection)として使えます。
本番環境以外のどこに顧客情報があるかを、1枚の一覧に書き出す
分析用のデータ基盤、社内ツール、サポート用の管理画面、書き出したCSV。本番環境をどれだけ固めても、顧客情報の写しが別の環境にあれば、そこから漏れるおそれがあります。場所ごとに「誰の・どの認証情報で読めるか」「操作ログが残るか」を書き出してください。
同社は、一部にログが取得されていない領域があったため閲覧の可能性を否定できないとしています。操作ログが残っていない場所では、不正な閲覧がなかったことも証明できません。
当サイトの視点:トークンが会社の管理外の端末に置かれることを前提に設計する
同社は、従業員が発行したGitHubの認証情報が、その従業員が個人開発で使っていたサーバー上に意図せずアップロードされたと説明しています。これは特定の誰かの問題ではなく、開発者が会社の外でもコードを書くという、どの組織にもある前提の話です。業務用のトークンが会社の管理外に出ることをゼロにはできません。だから、外に出さない工夫だけでは足りません。外に出ても短時間で無効になり、アクセスできる範囲が狭い設計にしておく必要があります。
韓国のTVINGでも、開発者の接続キー1つから、全ソースコードと本番環境の認証情報にまでたどり着ける状態でした(TVINGの個人情報流出)。同じ年の国内事案に共通する侵入経路は 2026年の情報漏えいは「正規の認証情報」で起きている にまとめています。
出典(公開記録)
本記事の事実関係は、以下の公開情報にもとづきます。公表されていない侵入の手口は推測していません。
- 株式会社CAMPFIRE「GitHubアカウントへの不正アクセス発生に関するお知らせとお詫び」(2026年4月3日) — campfire.co.jp
- 同(第二報)(2026年4月14日) — campfire.co.jp
- 同(第三報)(2026年4月22日) — campfire.co.jp
- 株式会社CAMPFIRE「【重要】弊社システムへの不正アクセスによる個人情報漏えいの可能性に関するお詫びとご報告」(2026年4月24日) — campfire.co.jp
- 株式会社CAMPFIRE「【続報】不正アクセスによる情報漏えい可能性の範囲について」(2026年4月27日) — campfire.co.jp
- 株式会社CAMPFIRE「個人情報漏えい可能性に関する『専用お問い合わせ窓口』開設のお知らせ」(2026年4月28日) — campfire.co.jp
- 株式会社CAMPFIRE「不正アクセス事案にかかる調査結果について」(2026年6月2日) — campfire.co.jp
- GitHub Docs「組織の個人用アクセストークン ポリシーを設定する」 — docs.github.com /「プッシュ保護について」 — docs.github.com /「OpenID Connectを使用したセキュリティ強化について」 — docs.github.com
更新履歴
2026-10-19:対象ユーザーの数を人数としていた表記を、原典のユニーク件数へ訂正。漏えいのおそれと確認済みの事実を区別し、重複のある内訳は合算しない。
2026-09-30:初版。CAMPFIREの2026年4月3日の第一報から6月2日の調査結果報告までの公表内容にもとづく。対象者の件数は6月2日の報告の内訳を採用。
次に読む
- 同じ年の国内事案:メディカ出版(医療者の名簿と著者の口座)
- 便乗詐欺への備え:フィッシングとは / パスワードマネージャーの選び方
- 開発者:gitleaksでコミット前に秘密情報を検出する / 自前Git vs GitHubのセキュリティ / .envとAPIキーの基本
- 同じ型の事案:正規の認証情報で起きる情報漏えい / TVINGの個人情報流出
- 2026年の他の事案:情報漏えい・サイバー攻撃の一覧(国内・海外)