GitHubから情報漏洩する5つの経路【2026年】削除しても履歴に残る理由と今日できる対策
TL;DR
GitHubで情報漏洩が起きる主な原因は「認証情報の窃取」か「うっかりコミット」のどちらかです。攻撃経路は5つあり、大企業でも同じ理由でやられています。
今日やること：
.gitignoreに.envを追加するgit logで機密情報がすでに履歴に入っていないか確認する- GitHub Settings で不要なOAuth連携を削除する
この3つだけで、防げる事故のほとんどは防げます。
マネーフォワードのGitHub不正アクセス（2026年5月）
2026年5月1日、株式会社マネーフォワードはこう発表した。
「GitHubの認証情報が漏えいし、第三者による不正なアクセスが発生し、GitHub内のリポジトリがコピーされたことが判明しました」
最初に公表された流出可能性のある情報は、マネーフォワード ビジネスカードに関わる370件のカード保持者名とカード番号の下4桁だった。
その後の調査が続き、2026年6月23日の最終報告では流出した可能性のある件数は約6.3万件に拡大。顧客・取引先・従業員のメールアドレス、住所、固有識別子などが対象になった。銀行口座連携機能は一時停止を余儀なくされた。
原因は「個人情報が含まれたファイルが本来の管理手順から外れ、誤ってGitHub上に保管されていた」こと。
GitHubはコードだけを置く場所ではなくなっている。そこに個人情報が含まれたファイルが入った瞬間、認証情報が漏洩すれば大規模な情報流出につながる。
GitHubで情報漏洩が起きる5つの経路
経路① 認証情報の窃取→リポジトリへの不正アクセス
「リポジトリ」って何？ GitHubにおけるプロジェクトの保管場所です。コード・設定ファイル・ドキュメントをまとめて入れる「フォルダ」のようなものだと思ってください。「プライベートリポジトリ」は自分（または招待したメンバー）だけが見られる非公開の保管場所です。
マネーフォワードのケースがまさにこれです。攻撃の流れはシンプルです。
- 何らかの方法でGitHubの認証情報（トークン・パスワード）が盗まれる
- 攻撃者がその認証情報でGitHub APIを呼び出す
- プライベートリポジトリにアクセスしてコードとファイルをコピーする
「トークン」って何？ パスワードの代わりに使う長い文字列です。GitHubでは、CI/CDツールやスクリプトからGitHubを操作するために「Personal Access Token（PAT）」を発行します。このトークンが盗まれると、パスワードを知らなくてもリポジトリにフルアクセスできます。
認証情報の漏洩経路は後述する経路②〜⑤のどれかです。一度認証情報が盗まれると、そこからはプライベートリポジトリへのフルアクセスに直結します。
2022年のHeroku/Travis CI事件では、HerokuのOAuthトークンが盗まれ、そのトークンを持つユーザーのGitHubプライベートリポジトリに攻撃者がアクセスしました。GitHubの公式声明によれば、攻撃者はリポジトリのコードをダウンロードしました。
経路② サプライチェーン攻撃（開発ツール経由）
2026年5月、GitHub自身が内部リポジトリ約3,800件を侵害されました。
経緯はこうです。
- 攻撃グループ「TeamPCP」がTanStackのnpmパッケージに悪意あるコードを仕込む
- そのコードが Nx Console 18.95.0（VS Code公式拡張機能）に混入、公式マーケットプレイスに約18分間掲載される
- GitHubの社員がこの拡張機能をインストール
- 拡張機能がGitHub CLIのトークンを含む認証情報を窃取
- 攻撃者がそのトークンでGitHubの内部リポジトリにアクセスし、コードを持ち出した
悪意ある拡張機能が掲載されていたのは18分。それでも被害は発生しました。
問題の本質：VS Codeの拡張機能やnpmパッケージは「信頼済み」として実行されます。そこに悪意あるコードが入れば、開発者端末に保存されているすべての認証情報（GitHub・AWS・npmトークンなど）が一度に盗まれうる。
経路③ .envファイル・個人情報ファイルのうっかりコミット（最多発）
マネーフォワードの原因が「本来の管理手順から外れ誤ってGitHub上に保管されていた」こと、つまりこの経路です。
同月の2026年4月には、クラウドファンディングサービス「CAMPFIRE」もGitHub経由で約22.5万人分の個人情報流出の可能性を発表しました。
「コミット」って何？ ファイルの変更を「保存した記録」として積み重ねていく操作です。
git addでステージに上げてgit commitで確定させると、その時点のファイルの状態がgitの歴史として永遠に残ります。GitHubにgit pushすることで、その記録がサーバー上に公開されます。
.envって何？ 環境変数（データベースの接続先・APIキー・パスワードなど）を書いておく設定ファイルです。プログラムを動かすために必要な「秘密の情報」をここにまとめておくのが慣習で、コードベースとは分離して管理するのが鉄則です。
典型的な事故のパターン：
# 本来コミットしてはいけないファイルの例
.env # DB接続文字列・APIキー
config.json # 各種サービスの認証情報
customer_data.csv # 顧客情報のテストデータ
backup.sql # DBダンプ（個人情報含む場合がある）これらのファイルを git add . で一緒にコミットしてしまい、GitHubにpushすると即座にリポジトリに入ります。プライベートリポジトリでも、認証情報が漏洩した瞬間にすべてが見られる状態になります。
「消したのにまだ残っている」落とし穴
さらに厄介なのは、削除してもgitのコミット履歴に残り続けることです。
git rm customer_data.csv
git commit -m "誤ってコミットしたファイルを削除"このコミットではファイルは見えなくなります。しかし、git log（コミット履歴の一覧）を辿れば、過去のコミットの中にファイルの内容が丸ごと残り続けます。GitHubのUIでも「History」から参照できてしまいます。
ファイルを消したから安心、というのは誤解です。履歴から完全に消すには専用の作業（git filter-repo等）が要ります。それより先に、APIキーや認証情報を無効化して新しいものを発行することが最優先です。
「APIキー」って何？ 外部サービス（OpenAI・Stripe・SendGridなど）を自分のプログラムから呼び出すための「合言葉」です。これが盗まれると、自分のアカウントで勝手に外部サービスを呼ばれ、料金が発生したり、アカウントが停止されたりします。
経路④ パブリックリポジトリの誤設定
「プライベートにしていたつもりが、パブリックになっていた」というミスも実在します。
発生しやすい状況：
- 個人アカウントでフォークしたときに可視性設定を間違えた
- GitHubのOrganization設定で「デフォルトをパブリック」になっていた
「フォーク」って何？ 他の人のリポジトリを自分のアカウントにコピーする操作です。オープンソースの改変や学習に使います。フォークしたリポジトリは、元のリポジトリとは別に可視性（公開・非公開）を設定できますが、ここの設定ミスが起きます。
パブリックになった瞬間、GitHubを監視しているスキャナーが自動的にコードを解析し、APIキーや個人情報を収集します。気づいてプライベートに戻しても、数分以内にデータが収集されている可能性があります。
経路⑤ ツール・ブラウザ経由のゼロデイ攻撃
2026年6月3日、VS Codeのゼロデイ脆弱性が公開されました。
細工したリンクをクリックさせるだけでGitHubのOAuthトークンが盗まれるという内容で、研究者のAmmar Askarが発見・公開しました。このトークンは「クリックした特定のリポジトリだけ」でなく、そのユーザーがアクセスできるすべてのリポジトリへの操作権を持っています。
“The token is not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to.”
パッチはまだ提供されていない（2026年6月時点）。
2026年の主要インシデントまとめ
| 時期 | 対象 | 規模 | 主な経路 |
|---|---|---|---|
| 2026年4月 | CAMPFIRE（日本） | 約22.5万人 | 誤ったコミット |
| 2026年5月 | マネーフォワード（日本） | 約6.3万件 | 誤ったコミット→認証情報漏洩 |
| 2026年5月 | GitHub（自社内部） | 約3,800リポジトリ | サプライチェーン（悪意ある拡張機能） |
今すぐできる3つの対策
① 不要なOAuth連携を削除する
GitHub Settings → Applications で、使っていないCIツール・デプロイツールの連携を今すぐ削除します。Herokuやかつて使ったCI/CDツールが残っていることが多いです。
「OAuth連携」って何？ 「GitHubでログイン」したサービスに、GitHubへの操作権限を渡す仕組みです。使わなくなったサービスの権限が残っていると、そのサービスが侵害されたとき自分のリポジトリまで巻き込まれます。
② .gitignore に機密ファイルを追加する
# .gitignore に必ず入れる
.env
.env.local
.env.*.local
*.csv # テストデータを除外する場合
config/secrets.yml
.gitignoreって何？ gitの管理対象から外すファイルのリストです。ここに書いたファイルはgit add .をしても自動的に無視されます。プロジェクト作成時に最初に設定するのが鉄則です。
プロジェクト作成時に設定しておくのが鉄則。既存のプロジェクトも今すぐ確認してください。
③ すでにコミットしていないか確認する
# .env がgit履歴に入っていないか確認
git log --all --full-history -- "**/.env"
# 特定の文字列（メールアドレスなど）が履歴に含まれていないか
git log -S "gmail.com" --all過去のコミット履歴に機密情報が含まれていた場合は、ファイルを削除するより先にAPIキーや認証情報を無効化して新しいキーを発行することが最優先です。履歴から消す作業は後でできます。盗まれた情報を使った攻撃は今すぐ始まりうる。
まとめ
マネーフォワードの事件が示すのは「悪意ある攻撃者に狙われた大企業の話」ではないということです。
「本来入れてはいけないファイルが誤ってGitHubに入った」 + 「認証情報が漏洩した」、この2つが重なれば、サービス規模に関係なく同じ事態が起きます。
GitHubで何が起きているかを知り、.gitignore の設定とOAuth連携の棚卸しを今日やる。それだけで、防げる事故のほとんどは防げます。