CAMPFIRE 漏洩の原因公表 — 業務 PAT が「個人開発サーバ」経由で流出、組織が打てる手

「個人開発サーバ」が業務トークンの埋蔵金になる構造 #

CAMPFIRE は 2026 年 6 月 3 日、22 万件超の情報漏洩を引き起こした不正アクセスの原因が「従業員が業務で発行した GitHub 認証情報を、個人開発で利用していたサーバへ意図せずアップロードしてしまったこと」だったと公表した。先に公表されていた「システム管理用 GitHub アカウント経由の侵入」の上流が、ここで初めて姿を現した形だ。

攻撃者から見ると、この構造は教科書通りだ。個人 VPS や自宅サーバには、フロントエンドの実験や副業案件のために業務リポジトリを 念のため clone していることが多く、.env や ~/.config/gh/hosts.yml、git config --global credential.helper store が残す .git-credentials に業務組織の Personal Access Token がそのまま転がる。Shodan で脆弱な SSH や開発用 Web を広く拾えば、年に数件はこの埋蔵金に当たる。狙いを定めて入る攻撃ではなく、広く撒いて引っかかったところに本丸がぶら下がっている タイプの侵害だ。

個人開発を禁止しても解決しない、止めるべきは「PAT の個人運用」 #

「個人開発を禁止すれば済む」というのは粗い対策だ。エンジニアの副業・自己研鑽は採用市場での競争力に直結し、CISO が一律禁止しても抜け道は無限にある。止めるべきは PAT そのものの個人運用だ。Classic PAT は権限が組織の全リポジトリに及び、しかも無期限に発行できてしまうので一度漏れれば壊滅的になる。

組織側で打てる手は明確で、Fine-grained PAT か OIDC で発行元と寿命を絞り、Personal Access Token Approval を有効化して最大有効期限を 30 日に・SSO 必須に絞っておけば、流出時のブラスト半径は桁で縮む。加えて Secret Scanning と push protection を .git-credentials 系のパスにも効かせ、業務 PAT が個人サーバの公開リポジトリ・公開ファイルに転がった瞬間に GitHub 側で無効化する経路を作っておく。

CAMPFIRE 事件は、攻撃者が会社の本丸ではなく 従業員の個人開発環境 から入ってくる時代の典型例として記録される。守るべきは社内 LAN だけではない。