GitHub の社内コードが3,800件流出した ― VS Code拡張を入口にした攻撃の全体像¶

対象 / ポイント

対象: GitHub、VS Code、npm、GitHub Actionsを日常的に使う開発・運用組織。

ポイント:

GitHubは2026年5月20日、社員端末の侵害と社内リポジトリ流出を公式に認めた。
入口は第三者が公開した悪性VS Code拡張で、関連するNx Console侵害の時系列も公表された。
開発者端末の拡張・トークン・CI/CD権限は、ソフトウェア導入と同じ重みで管理する必要がある。

2026年5月20日、GitHubは「社員端末が悪性VS Code拡張で侵害された」と公式ブログで説明した。対象はGitHub内部リポジトリで、攻撃者が主張する約3,800件という数字は同社調査と大きく矛盾しない、としている¹。

この記事の問いは1つだ。なぜ、拡張機能を1つ入れただけで、社内コード流出につながったのか。

攻撃の経路¶

TeamPCPが悪性VS Code拡張を使い、GitHub社員PCを経由して社内リポジトリを流出させた経路

経路は派手ではない。正規の開発ツールに見える拡張が悪性化し、社員端末上で認証情報を盗み、その権限で内部リポジトリへ到達した。

重要なのは、境界防御を正面から突破した事件ではない点だ。開発者の端末そのものが、内部システムへの入口になった。

何が起きたのか¶

GitHubによると、同社は2026年5月18日月曜日に社員端末の侵害を検知・封じ込めた。悪性バージョンは削除され、端末は隔離され、重要なシークレットは同日から翌日にかけて優先度順にローテーションされた¹。

関連して、Nxは2026年5月21日にNx Console v18.95.0の事後報告を公開した。報告では、2026年5月18日12:30から13:09 UTCの間に、攻撃者がVisual Studio MarketplaceとOpen VSXへ悪性のNx Console v18.95.0を公開したと説明している²。

GitHub公式ブログは拡張名を本文で断定していない。一方で、Nxの事後報告とWizの分析は、同時期のTeamPCP関連キャンペーンにNx Console v18.95.0が含まれることを示している³⁴。

ここで分けて読むべきなのは、GitHubが確認した事実と、調査会社・攻撃者側の主張だ。GitHubが確認したのは、社員端末、悪性VS Code拡張、内部リポジトリの持ち出し、約3,800件という攻撃者主張との整合である。

なぜ深刻なのか¶

GitHubは、現時点の評価として影響はGitHub内部リポジトリに限られると説明している。ただし同じ発表の中で、内部リポジトリにはサポート対応の抜粋など顧客由来の情報が含まれる場合があり、影響が判明すれば通知するとしている¹。

つまり、「顧客情報は一切ない」とは読まない方がよい。より正確には、GitHub内部リポジトリ外の顧客情報、たとえば顧客自身のEnterprise・Organization・Repositoryへの影響を示す証拠はないという段階だ。

攻撃者グループTeamPCPは、盗んだとするデータを50,000ドルで売ろうとしていると複数メディアが報じた⁵。この金額や売却状況は攻撃者側の主張を含むため、確定情報ではない。

それでも、内部リポジトリの流出は軽くない。製品コード、運用スクリプト、セキュリティワークフロー、未公開機能の断片が含まれていれば、後続攻撃の材料になる。

なぜ「拡張を入れただけ」で危ないのか¶

VS Code拡張は、開発者の作業環境でコードを実行できる。ワークスペースのファイル、環境変数、ローカルに残ったトークン、SSH鍵、クラウド認証情報などに近い場所で動く。

Wizは、同時期のTeamPCP関連キャンペーンがnpm、GitHub Actions、PyPI、Visual Studio Codeをまたいだ広いサプライチェーン攻撃だったと整理している³。Wizの技術分析では、GitHubトークン、SSH鍵、クラウド認証情報などの収集も観測されている⁴。

この構図では、Marketplaceの審査だけに頼れない。最初は正規でも、後からの更新、メンテナー認証情報の窃取、CI/CDの悪用で別物に変わる。

開発者端末は「個人PC」ではなく、本番環境へ続く認証情報の集積地として扱う必要がある。

今すぐ確認すること¶

まずはVS Code拡張の一覧を、バージョン付きで確認する。

code --list-extensions --show-versions

確認すべき観点は3つに絞る。

2026年5月18日前後に更新された拡張がないか
Nx Console v18.95.0、または現在使っていない拡張が残っていないか
個人発行元・用途不明・権限が広い拡張を放置していないか

Nxは、該当時間帯にNx Consoleを自動更新込みで入れていた場合、端末を侵害済みとして扱い、GitHub、npm、SSH、クラウド、Kubernetes、Vault、.env内の認証情報をローテーションするよう推奨している²。

次に、ローカルの認証情報を棚卸しする。

gh auth status
git config --global --get credential.helper
aws configure list

これらのコマンドは、残っている認証状態を把握する入口にすぎない。不要なトークンは削除し、必要なトークンも最小権限・短命化・デバイス単位の失効手順まで含めて見直す。

まとめ¶

今回の事件は、VS Code拡張だけの話ではない。2026年5月のTeamPCP関連キャンペーンでは、npmパッケージ、GitHub Actions、PyPI、VS Code拡張が同じ攻撃面として扱われていた³。

開発組織に必要なのは「怪しい拡張を入れない」という注意喚起だけでは足りない。拡張の許可リスト、更新遅延、端末隔離、トークンの短命化、CI/CD権限の分離を組み合わせる必要がある。

最後に残る論点は、開発者体験との折り合いだ。拡張や自動更新をすべて禁止すれば開発速度は落ちる。だが、無管理のままなら、次の入口はまた開発者端末になる。

開発ツールの導入は、便利ツールの追加ではなく、社内システムにコードを入れる行為だ。 この前提に切り替えた組織から、次のサプライチェーン攻撃への耐性が変わっていく。