たった11分で3,800リポジトリが流出——GitHubを陥落させたVS Code拡張機能サプライチェーン攻撃
はじめに
2026年5月18日、開発者のインフラとも言える GitHub で、大きなセキュリティインシデントが起きました。内部リポジトリ約3,800件が流出し、攻撃者はそのデータを5万ドル以上で地下フォーラムに売り出しています。
この記事では以下のことが分かります。
- 攻撃者がどのようにしてGitHubに侵入したか(侵入経路)
- 「たった11〜18分間の公開」だけで被害が拡大した理由
- GitHubの迅速な対応と、対照的なGrafana Labsの「カナリアトークン」成功例
- 開発者・企業が今すぐできる具体的な対策
「大企業がハッキングされた」で終わらせず、自分たちの日常にもある同じリスクをどう防ぐかという視点で読んでもらえればと思います。
事件の概要
| 項目 | 内容 |
|---|---|
| 検知日時 | 2026年5月18日(UTC) |
| 被害規模 | GitHub内部リポジトリ 約3,800件が流出 |
| 流出内容 | 設計情報・内部コードなど(顧客データや本番インフラへの直接影響は現時点で未確認) |
| 攻撃手法 | サプライチェーン攻撃(VS Code拡張機能の改ざん) |
| 攻撃者 | TeamPCP(別名:UNC6780) |
| 現状 | 盗んだデータを地下フォーラムで5万ドル以上で売り出し中。「買い手がつかなければ無料公開する」と脅迫 |
侵入経路:「毒入りVS Code拡張機能」が仕掛けた罠
標的にされた「Nx Console」
侵入の起点となったのは、VS Code拡張機能の 「Nx Console」v18.95.0 です。Nx Console は Nx モノレポツールの公式 UI で、220万回以上インストールされている、いわゆる「定番」拡張機能です。
攻撃者はこのリリースに悪意のあるコードを仕込み、Marketplace上に公開しました。感染した端末では、バックグラウンドで以下のようなコマンドが実行されます。
# 感染時にバックグラウンドで実行されるペイロードのダウンロード・実行
npx -y github:nrwl/nx#558b09d7
感染の痕跡(IOC: Indicators of Compromise)として、以下のファイルが端末に残ります。
~/.local/share/kitty/cat.py
~/Library/LaunchAgents/com.user.kitty-monitor.plist
/var/tmp/.gh_update_state
/tmp/kitty-*
これらのファイルに心当たりがある場合、感染を疑ってください。
たった「11〜18分間」の恐怖
この悪意あるバージョンがMarketplace上に公開されていたのは、わずか11〜18分間でした。
信じられないほど短い時間ですが、VS Code拡張機能の自動更新が有効になっていたGitHub従業員の端末は、この短時間のうちに感染してしまいました。「有名で信頼できるツールだから安全」という常識が、一瞬で覆された瞬間です。
攻撃者「TeamPCP」とは何者か
今回の攻撃を実行したのは、**TeamPCP(別名:UNC6780)**と呼ばれるグループです。
このグループは今回が初犯ではありません。過去にも開発者が日常的に使うツールを標的にしたサプライチェーン攻撃を繰り返しており、TrivyやLiteLLMなどのOSSツールでも同様の手口が確認されています。
彼らのターゲット選定には明確な戦略があります。「開発者が使うツール」を汚染すれば、そのツールを信頼している企業のエンジニアのマシンを経由して、企業の内部に侵入できるという考え方です。エンドユーザーよりも開発者を狙う方が、より高価値なシステムへのアクセスを得やすいのです。
GitHubの迅速な対応:インシデントレスポンスの模範
被害を受けた側のGitHubの対応は、迅速かつ透明性の高いものでした。
- 端末の即時隔離: 感染が確認された従業員の端末を速やかに隔離
- シークレットの夜通しローテーション: 盗まれた可能性のあるパスワードやAPIキーなどの「合鍵」を全て更新
- 迅速な情報公開: 事態の詳細を隠蔽せず、公式ブログで透明性の高い発表を実施
対照的な成功例:Grafana Labsの「カナリアトークン」
GitHubのインシデントと時期を同じくして、Grafana Labsも攻撃者から侵害を受けていました。しかしGrafana Labsの被害は最小限に抑えられました。その理由が「カナリアトークン」の活用です。
カナリアトークンとは
カナリアトークンとは、システムの内部に仕込む「おとりの鍵データ」です。本物のデータに見せかけたダミーの認証情報やファイルを用意しておき、それが実際にアクセスされた瞬間にアラートが発火する仕組みです。
炭鉱でカナリアを飼って危険なガスを早期検知した故事に由来しています。
【カナリアトークンの仕組み】
1. システム内に「本物に見えるが偽物の認証情報」を配置
2. 正規ユーザーはその認証情報を使わないので通常はアクセスがない
3. 攻撃者がデータを盗み出し使おうとした瞬間 → アラート発火
4. 「侵害された」という事実と「何のデータが盗まれたか」が即座に判明
Grafana Labsはこのカナリアトークンがトリガーされたことで、侵害の事実を即座に検知し、被害の拡大を食い止めることができました。
「6週間で3件」——GitHubインフラを狙う攻撃の連続
今回の事件は孤立した出来事ではありません。過去6週間の間に、GitHubインフラ周辺を標的にした大規模なセキュリティ事件が3件も連続して発生しています。
| 事件 | 概要 |
|---|---|
| CVE-2026-3854 |
git pushコマンドによるサーバー乗っ取りの脆弱性 |
| Grafana Labs GitHub Actions侵害 | GitHub ActionsのCI/CDパイプラインを経由した侵害 |
| 今回のVS Code拡張機能サプライチェーン攻撃 | 本記事の事件 |
GitHubはソフトウェア開発のサプライチェーンの中核を担っています。GitHubへのアクセスは、すなわち世界中の無数のソフトウェアプロジェクトへのアクセスを意味します。攻撃者にとって非常に魅力的なターゲットであることは間違いなく、今後も標的にされ続けると考えておくべきでしょう。
開発者・企業が今すぐできる対策
今回の事件を他人事として終わらせないために、明日から実行できる具体的な対策を挙げます。
1. VS Code拡張機能を棚卸しする
VS Codeの拡張機能メニューを開き、以下を確認:
- インストール済み拡張機能の一覧を見直す
- 使っていない拡張機能をアンインストールする
- 各拡張機能の最終更新日・ダウンロード数・発行元を確認する
- 不審な拡張機能がないかチェックする(今回のIOCリストと照合)
2. 拡張機能の自動更新設定を見直す
VS Codeのデフォルトは自動更新が有効です。組織のポリシーとして、拡張機能の更新を手動にするか、少なくとも更新前に変更内容を確認するステップを設けることを検討してください。
3. IOC(感染兆候)を確認する
以下のコマンドで、自分の端末に今回の感染痕跡がないか確認できます。
# macOSでの確認
ls ~/.local/share/kitty/cat.py 2>/dev/null && echo "INFECTED: cat.py found"
ls ~/Library/LaunchAgents/com.user.kitty-monitor.plist 2>/dev/null && echo "INFECTED: plist found"
ls /var/tmp/.gh_update_state 2>/dev/null && echo "SUSPICIOUS: gh_update_state found"
ls /tmp/kitty-* 2>/dev/null && echo "SUSPICIOUS: kitty temp files found"
4. ゼロトラストの原則で権限を最小化する
「信頼できるツールを使っているから大丈夫」という前提を捨て、**「すべてのツール・すべてのアクセスは潜在的に侵害されうる」**という前提で設計し直すことが重要です。
- CIサービスやツールに付与しているGitHubトークンの権限を最小限にする
- 使用していないPersonal Access Tokenを削除する
- Organization・リポジトリの権限を定期的に棚卸しする
5. カナリアトークンを導入する
Grafana Labsの成功例にならい、重要なシステムにカナリアトークンを仕込んでおきましょう。万が一侵害されたときの早期検知と被害範囲の特定に大きく貢献します。
まとめ
今回のGitHub内部リポジトリ流出事件が教えてくれることは、「攻撃は、私たちが日常的に信頼しているツールを通じてやってくる」という現実です。
220万インストールの実績を持つ拡張機能が11〜18分だけ汚染されただけで、世界最大のコードホスティングプラットフォームの内部データが流出しました。私たちが使うツールの自動更新の裏に、今日もこのような攻撃が潜んでいるかもしれません。
「有名なツールだから大丈夫」「うちは関係ない」は危ないです。侵害される前提で権限を絞ることと、侵害されたらすぐ気づける仕組み(カナリアトークンなど)を用意しておくことが、現実的な対策だと思います。
GitHub のように、起きたあとに隠さず動けることが大事になってきますね。
参考資料
- Investigating unauthorized access to GitHub-owned repositories — GitHub公式ブログ
- GitHub内部リポジトリ不正アクセス事件 最新調査まとめ(2026年5月20日 v2更新)— zephel01
- 【緊急】GitHubが陥落した日 - VS Code拡張機能から始まった3,800リポジトリ流出事件の全貌 — Qiita
- GitHub Confirms Breach of 3,800 Repos via Poisoned VS Code Extension — Coinfomania
- GitHub内部リポジトリ不正アクセス疑惑に備える開発基盤防御の実務 — 株式会社アクト
Discussion