GitHubが悪意のあるVSCode拡張機能を通じて3,800のリポジトリへの侵害を確認

5日前原文(bleepingcomputer.com)

概要

GitHub の内部リポジトリ約3,800件が 不正アクセス 被害
VS Code拡張機能 がマルウェア化し、従業員端末を経由して侵入
顧客データへの影響は 現時点で確認されていない
ハッカーグループ TeamPCP が情報窃取を主張し、5万ドル以上で販売を試み
VS Code拡張機能 のセキュリティリスクが再び注目

GitHub内部リポジトリ流出事件の概要

GitHub従業員 が悪意ある VS Code拡張機能 をインストールしたことによるインシデント
拡張機能は VS Code Marketplace から削除済み、感染端末も隔離
GitHubによると、 流出対象は社内リポジトリのみ で、外部顧客データへの影響は未確認
攻撃者は約 3,800リポジトリ の流出を主張、GitHubの調査結果とも一致
TeamPCP がサイバー犯罪フォーラムで「約4,000リポジトリ」の販売を掲示
- 最低価格 5万ドル 以上での売却を希望
- 販売できなければ無料公開も示唆

TeamPCPとサプライチェーン攻撃の経緯

TeamPCP は過去にもGitHubやPyPI、NPM、Dockerなど 開発者プラットフォーム への攻撃に関与
「Mini Shai-Hulud」キャンペーンでは OpenAI従業員 も被害
サプライチェーン攻撃 による開発現場の脆弱性露呈

VS Code拡張機能のセキュリティリスク

VS Code拡張機能 は公式Marketplaceからインストール可能
過去にも数百万インストール規模の マルウェア拡張機能 が発見・削除
- 開発者認証情報や 機密データ の窃取事例
- XMRig 仮想通貨マイナーやランサムウェア機能付き拡張も流通
- 2024年1月には AIコーディング支援 を偽装した拡張が中国サーバーへデータ送信

GitHubの規模と影響範囲

GitHubは 4百万以上の組織 （Fortune 100の90%含む）、 1億8千万超の開発者 が利用
4億2千万件超 のリポジトリを管理
サプライチェーン攻撃による 広範な波及リスク

セキュリティ検証と自動ペンテストツールの課題

自動化ペンテストツールは「攻撃者がネットワークを移動できるか」のみ検証
脅威ブロック、検知ルール、クラウド設定 など多面的な検証が必要
実際のセキュリティギャップを把握するための 包括的バリデーション の重要性

まとめ

VS Code拡張機能 のインストール時は公式性や信頼性の確認が必須
サプライチェーン攻撃 への警戒と多層的なセキュリティ対策の強化が急務
GitHubのような 基盤サービス に対する攻撃は、開発エコシステム全体に影響

Hackerたちの意見

前のスレッド: GitHubが内部リポジトリへの不正アクセスを調査中 - https://news.ycombinator.com/item?id=48201316 - 2026年5月（321件のコメント）

どの拡張機能なの？教えてくれないの？

└

NX ConsoleのVS Code拡張が怪しいって噂があるね。 https://github.com/nrwl/nx-console/security/advisories/GHSA-... https://www.stepsecurity.io/blog/nx-console-vs-code-extensio...

└

数日前、Twig拡張機能のアップデートがあることに気づいたんだ。UIがアップデートバンドルに新しい実行可能コードが含まれているって警告してたから、インストールはしなかったし、その日はDrupalのビューを触ってなかったから拡張機能も無効にした。新しいアップデートの内容を調べる時間もなかったしね。再び拡張機能のページに戻ったら、もう削除されてた。リンクはここだよ: https://open-vsx.org/extension/whatwedo/twig 何があったかは言わないけど、whatwedo.twigだったかもしれないし、そうじゃないかもしれない。追記: Cursor / VS Code用の良いTwigフォーマッターのおすすめがあったら教えて！

でも、ダウンしなかったよ！進展だね！

└

それ、ジンクスにしないで！

└

うまく動いてるけど、何をしてるのかは分からないね。

└

デプロイする時間がない！法医学調査中は誰も動いちゃダメだ！

もしかして見落としてることがあるのかもしれないけど… 3,800個のリポジトリ？そんなに多いとは思わなかった！

└

GitHubみたいな組織にしては3800は少ないね。全てのリポジトリが侵害されてるわけじゃないってことがほぼ確実で良かった。

└

私には少なく感じる。数年前にフォーチュンの高い企業で働いてたけど、もっと多かったよ。

└

私がいた組織は15000以上のリポジトリがあった。

└

個人的には100以上持ってるよ。特にクイックプロトタイプや研究、テンプレートのインスタンスから作ったものだから、18年と何百人もの従業員がいると、簡単に何千もできちゃうんだよね。

└

ここでのジョークを見逃してるのかな…彼らは数億のリポジトリを持ってるのに。

└

他の人も言ってるけど、ほんの一部に過ぎないよね。中規模のテック関連の会社にいるけど、1つのGithub組織に7500以上あるよ。2つの組織があるから、合わせて簡単に1万以上だね。もちろん、大半は古くて使えないものやサンドボックス、個人用ツールとかだし、Githubが内部リポジトリを10万以上持ってても驚かないよ。

└

一度、食品小売店で働いたことがあるんだけど、初日には「どれくらい大変なんだろう？」って思ってたんだ。外から見ると、シンプルなウェブサイトに見えるけど、実際には300以上のリポジトリが混ざり合ったものだった。GitHubはこのデータ流出で損失が少なかったし、成長するにつれてシンプルさを保つのって本当に大変なんだよね。

└

Uberは一時期、8000のリポジトリと2000人のエンジニアがいたんだって。 - https://highscalability.com/lessons-learned-from-scaling-ube...

└

自分の経験から言うと、10年か20年も経てば、どんな企業でも廃止されたサービスや、どこにも行かなかったPOCやプロトタイプが入った数百（あるいは数千）の内部リポジトリが溜まっていくよ。人々はそれをアーカイブするのを忘れたり、まだ使われているかどうかわからないから、安全策を取るんだよね。AIのせいでこれがさらに悪化してる。コーディングエージェントがあれば、誰でも自分のアイデアを素早く内部プロトタイプにできちゃうから、実際に製品化される見込みがなくてもね。

VS CodeはElectronで作られてるから、サンドボックス化が面倒なんだよね。Electronには（あった？）SUIDサンドボックスヘルパーがあって、サンドボックス内でSUIDバイナリを簡単には実行できない。Linuxでのサンドボックス化は本当に難しい作業だよ。

└

「ChromeにSUID Rootを与えないとサンドボックスが動かない」ってメッセージを見るのは本当に気分が悪い。ウェブブラウザにSUID Rootを設定するのは、無知なユーザーへの古いジョークだった。最悪のセキュリティミスだよね。

└

podmanはルートレスネームスペースをうまく扱えてるみたいだね。ちょっとパフォーマンスにオーバーヘッドがあるけど、そんなに大したことじゃないよ。

AI Microslopを責めるのは早すぎるかな？

└

これは間違いなくAIのゴミだわ。会社でAI生成のクソみたいなものをプロダクションに押し込むのに疲れた。

GitHubの組織を持っていて、PATトークンの流出（とその後の悪用）を減らすためにどんな変更やコントロールができるか探してるなら、以下のリンクの最後にいくつかリストしたよ。 https://blog.bored.engineer/github-canarytokens-5c9e36ad7ecf...

監査ログのストリーミングを有効にしてね[1]。ソースIPやAPIリクエストを含めて、誰も見ないS3バケットに送るだけでも、インシデント対応チームが後で感謝してくれるよ。
GitHubの組織でSSOの使用を強制することをお勧めするよ[2]。SSOが良いからだけじゃなくて、ユーザーがSSHキー/PATのアクセスを明示的に承認する行動を強いるからね[3]。そうすれば、誰かの週末プロジェクト用に作られたPATが組織のリソースにアクセスすることはなくなるよ。
知っている信頼できるVPN/企業IPのセットからのIPホワイトリストを強制することが一番効果的だよ[4]。これは最も強力なコントロール（導入が一番大変だけど）で、盗まれた資格情報（まだ有効でも）を攻撃者が使うのを防げるから、意図したシステムでのみ使えるようにしておけば、他の可視性やアラートがEDRや関連ツールで得られるはずだよ。
できるなら、個人アクセス・トークンからの組織リソースへのアクセスを制限してね[5]。従来のPATをブロックして、細かいPATに最大の有効期限（例: 3ヶ月）を設けるのは、PATを完全に排除できない場合のリスクを減らす良い方法だよ[6]。
GitHubエンタープライズ（オンプレミス）を使っているなら、ネイティブのGitHub監査ログに加えて生のHTTPアクセスログの収集を設定しておくと、インシデント対応の際に重要になるかもしれないよ[7]。

VSCodeのセキュリティの（欠如）はいつも驚くべきものだよね。何年も前からサンドボックス拡張の要望があったけど、ほとんど進展がないし、問題もたくさん議論されてる（例えば、[1][2]）。大抵の開発者はそんなにバカじゃないから、大きな問題にはなってないのかも。でも、たった一人の開発者と一つの悪い拡張がこういう結果を引き起こすのには十分だよね。Node.jsアプリをサンドボックス化するのが難しいのは分かるけど、どうやらMicrosoftはセキュリティよりもCopilotにずっと力を入れてるみたいだね。 [0] https://github.com/microsoft/vscode/issues/52116 [1] https://news.ycombinator.com/item?id=42979994 [2] https://news.ycombinator.com/item?id=46855527

これがきっかけでMicrosoftがVS Codeの拡張に明示的な権限システムを追加して、開発コンテナのセキュリティを改善してくれることを願ってるよ。

└

期待はしてないけど。この問題は2018年から開いてるからね。 https://github.com/microsoft/vscode/issues/52116

ちょうど数週間前にプライベートリポジトリをSourceHutに移し始めたところなんだ。結構良くて速いよ！パブリックのもCodebergにミラーリングしてる。終わったらそのことについて書くつもり。

ハクソク