GitHub 内部リポ 3,800 件流出インシデント徹底解説 ─ 悪意ある VS Code 拡張・TeamPCP・Mini Shai-Hulud と我々が今日打つべき対策

本サイトは Google AdSense による広告が表示される場合があります。本記事は Cyber Security News（2026-05-20 報道）を起点に、The Hacker News、BleepingComputer、Help Net Security、Wiz Research、GitGuardian など複数の一次・二次情報を横断確認し、運営者（現役 IT エンジニア・15 年以上の業界経験）が日本語で再構成したものです。情報は 2026 年 5 月 20 日時点で公開済みのもののみを採用し、未公表事項は明示的に「不明」と記しています。最新情報は GitHub Blog の続報をご確認ください。

Tech Notes · Security Incident · 2026.05.20

GitHub が、自社の内部リポジトリ約 3,800 件が外部に流出したインシデントを 2026 年 5 月 20 日に確認した^[1]。攻撃の入口は、社員が業務マシンに入れた 悪意ある Visual Studio Code 拡張機能。脅威アクター「TeamPCP」が犯行声明を出し、5 万ドル以上での売却を提示している^[2]。GitHub は「お客様の公開リポジトリやエンタープライズデータには影響なし」と発表したが、本件は IDE 拡張という新しい攻撃面の存在感を一段引き上げた点で、社内ハーニング全体の見直しを迫るものだ。本記事では、5/20 時点で確定している事実、TeamPCP の Mini Shai-Hulud ワーム、同月の関連事案（CISA・SailPoint・Grafana・CVE-2026-3854）、そして今日エンジニアリングチームが取るべき具体的対策までを 16 章で整理する。読了 22 分。

user@sinyblog:~/article ❯ 01_tldr.md60 秒ダイジェスト：確定している事実だけ

未確認情報を切り捨てて、5/20 時点で複数の一次・二次ソースで確定している事実だけを並べる。

1. 検知：2026 年 5 月 19 日。公表：5 月 20 日。GitHub 社員のデバイスに「悪意ある VS Code 拡張」が混入し、そこから内部リポジトリへのアクセス・データ持ち出しが発生した^[1][2]。
2. 影響範囲：GitHub-internal リポジトリ約 3,800 件。公開リポジトリや顧客（Enterprise）データへの影響は、GitHub 調査時点で確認されていない^[3]。
3. 犯行声明：脅威アクター「TeamPCP」。地下フォーラムで売却を提示しており、最低価格は 5 万ドル。買い手が付かなければ無償リークすると主張^[2]。
4. 悪意拡張の具体名は未公表。GitHub は拡張のバージョンを Marketplace から取り下げたとしつつ、その識別子・名称を 5/20 時点で公開していない^[4]。
5. GitHub 対応：拡張削除 → 端末隔離 → 重大度の高い認証情報を一晩でローテーション → 継続ログ解析。詳細インシデントレポートは後日公表予定^[1]。

user@sinyblog:~/article ❯ 02_facts.md何が起きたのか — 事実関係の整理

事実関係を 5W1H で整理する。

GitHub 公式の声明はやや短く、攻撃の詳細メカニズムには踏み込んでいない。確認できる主要なクオートは次の 2 つだ^[4][1]。

We removed the malicious extension version, isolated the endpoint, and began incident response immediately.

GitHub Official Statement, via BleepingComputer / [4]

While we currently have no evidence of impact to customer information stored outside of GitHub's internal repositories (such as our customers' enterprises, organizations, and repositories), we are closely monitoring our infrastructure for follow-on activity.

GitHub Official Statement, via Cyber Security News / [1]

つまり、現時点での「顧客への影響なし」は「未だ証拠が見つかっていない（no evidence）」という慎重な表現であって、「影響ゼロ」と断言したものではない。継続調査の対象であることに留意しておく必要がある。

user@sinyblog:~/article ❯ 03_vscode-vector.md攻撃ベクトル：「悪意ある VS Code 拡張」とは何か

VS Code 拡張機能は、エディタの機能を拡張する小さなプログラムだ。多くは TypeScript / JavaScript で書かれており、インストール時に VS Code プロセスの権限でローカルマシン上のファイル・コマンド・ネットワークにアクセスできる。サンドボックスは存在しない。これは Chrome 拡張に近い感覚で扱われがちだが、実態は「Marketplace 経由で配布される、フル権限のローカル実行プログラム」と言ってよい^[5]。

典型的な悪意拡張の動作パターンを並べると、以下のような流れになる。

1. 正規拡張に酷似した名前・アイコンを使って Marketplace に登録される（タイポスクワッティング）
2. あるいは正規拡張のメンテナアカウントを乗っ取り、悪意ある新バージョンを push する
3. インストール直後の activate() ハンドラ、または特定イベント（ファイルオープン等）で潜伏ロジックを実行
4. ローカルの ~/.npmrc、~/.gitconfig、Git Credential Manager、ブラウザ保管シークレット、OS キーチェーン等から認証情報を収集
5. 抽出したトークンで GitHub / npm / PyPI 等の API を直接叩き、追加データを引き出す or 増殖する

user@sinyblog:~/article ❯ 04_teampcp.mdTeamPCP とは誰か — 2026 年の被害一覧

TeamPCP は 2026 年に入って急速に観測量が増えた、ソフトウェア供給網への攻撃に特化した金銭目的のグループだ。Wiz、StepSecurity、ReversingLabs、Trend Micro など複数の研究機関が独立して追跡している^[5][6]。直近の主な犠牲対象を時系列で並べる。

「OSS をひとつ攻めて 1 万ダウンロード」ではなく、「定番の人気パッケージや Actions、VS Code 拡張を片端から落としてエコシステム全体を巻き込む」という規模感が TeamPCP の特徴だ。GitHub 自身も例外ではなかった、というのが今回示されたことになる。

user@sinyblog:~/article ❯ 05_mini-shai-hulud.mdMini Shai-Hulud ワーム — 自己増殖する供給網マルウェア

TeamPCP の主力武器が「Mini Shai-Hulud」と呼ばれるワーム型マルウェアだ。Wiz と StepSecurity の解析を要約すると、その挙動はおおむね以下のようになる^[5]。

1. npm / PyPI / VS Code 拡張のいずれかにインストール時実行コードとして仕込まれる
2. 起動後、追加ペイロードを「孤立した（orphaned）GitHub commit」から取得。検出回避のためにブランチではなくコミット単位でホストされる
3. bun パッケージマネージャを使って二次ペイロードを実行（Node.js 直実行よりログに残りにくい）
4. GitHub トークン、SSH 鍵、クラウド資格情報、ブラウザ保管シークレットなどを収集
5. 取得したトークンで 「そのトークンが触れる別パッケージ」に汚染をプッシュし、自己増殖する
6. 抽出データは攻撃者が新規作成した公開リポジトリにダンプ（侵入の足跡を別のリポジトリ側に分散）

研究者が確認している IoC（侵害指標）には、Dune シリーズに由来する独特の命名パターンがある^[5]。

# Wiz が観測した IoC（Mini Shai-Hulud）
Python backdoor path : ~/.local/share/kitty/cat.py
C2 trigger string    : firedalazer
SHA-256              : fb5c97557230a27460fdab01fafcfabeaa49590bafd5b6ef30501aa9e0a51142
C2 domain            : m-kosche.com  (185.95.159.32)

# 攻撃者が好む Dead-drop ブランチ／コミット名（Dune シリーズ）
atreides, cogitor, fedaykin, fremen, futar, gesserit, ghola,
harkonnen, heighliner, kanly, kralizec, lasgun, laza, melange,
mentat, navigator, ornithopter, phibian, powindah, prana,
prescient, sandworm, sardaukar, sayyadina, sietch, siridar,
slig, stillsuit, thumper, tleilaxu

user@sinyblog:~/article ❯ 06_attack-chain.md想定される攻撃チェーン — 拡張から内部リポ流出まで

GitHub は端末侵害後の挙動詳細を公開していないため、ここからは TeamPCP の既知の TTPs（戦術・技術・手順）と一致する範囲での推定になる^[5]。確定情報と推定の境界を太字で明示する。

1. 確定：GitHub 社員が悪意ある VS Code 拡張をインストール（5/19 以前）
2. 推定：拡張の activate() で Mini Shai-Hulud 系のドロッパーが実行され、~/.local/share/kitty/cat.py 相当の Python ベースのバックドアを設置
3. 推定：GitHub Credential Manager / OS キーチェーン / ~/.gitconfig から GitHub セッショントークンや SSH 鍵を取得
4. 推定：取得した認証情報を使い、社員アカウントの権限の範囲で内部リポジトリ群を git clone（API 経由のアーカイブダウンロードを使う変種もある）
5. 確定：合計 約 3,800 リポジトリ分のデータが攻撃者の手元に渡る
6. 確定：GitHub が侵害を検知（5/19）し、拡張削除・端末隔離・主要シークレットローテーションを実施

user@sinyblog:~/article ❯ 07_timeline.mdGitHub の対応タイムライン

公開情報から再構成したタイムライン^[1][4]。

注目したいのは 「シークレットを一晩でローテーションした」という記述だ^[1]。GitHub 規模で「高影響度のものから順に」回す運用は事前準備なしには不可能で、平時から「全てのシークレットには所有者と回転手順が定義されている」状態を維持していた、と読める。インシデント対応の質という観点では、ここは参考にしたい部分だ。

user@sinyblog:~/article ❯ 08_scope.md流出範囲と「顧客データに影響なし」の現在地

「3,800 リポジトリ流出」と「顧客に影響なし」は両立しうるのか、という疑問を多くの読者が持つはずだ。GitHub の声明を読み解くと、以下のような構造になっている^[3]。

• GitHub-internal リポジトリ：GitHub 社員が業務用に使う、GitHub 社自身の社内プロジェクト。社内ツール、運用スクリプト、自社サービスの実装などが含まれる。ここは持ち出された可能性が高い。
• 顧客リポジトリ（Enterprise / Org / 個人）：GitHub.com 上にユーザーがホストしている公開・非公開リポジトリ群。影響の証拠は現時点で発見されていない。
• GitHub プロダクト自体のソースコード：GitHub.com のサービス本体のコードが含まれているかは明示されていない。一般論として「内部リポ」と表現されるものには本番サービスのコードも含まれうるが、本件で具体的に何が含まれていたかは未公開。

user@sinyblog:~/article ❯ 09_other-incidents.md同月の関連事案 — CISA・SailPoint・Grafana・CVE-2026-3854

本件は単体の事故というより、2026 年 4〜5 月の「GitHub をめぐる連続インシデントの一部」として位置づけたほうが状況把握しやすい。同時期の主要事案を並べる。

1 か月の間に、製品脆弱性（CVE）／第三者統合経由／誤公開／Actions 設定不備／IDE 拡張と、性質の異なる 5 件が立て続けに起きた。「GitHub 上のソースコードはどう守るか」が本気で問われている時期だと捉えてよい。

user@sinyblog:~/article ❯ 10_ide-attack-surface.mdなぜ「IDE 拡張」が新しい攻撃面になっているのか

本件を抽象化すると、「開発者の IDE 拡張は、CI／本番より監視が薄い場所で、強い権限のローカルコード実行が許される」という構造的弱点を突かれた、ということになる。整理すると 4 つの理由がある。

1. サンドボックスがない：VS Code 拡張は Node.js プロセスとして動作し、ファイル・ネットワーク・サブプロセス起動の制限を受けない^[5]。
2. Marketplace の審査は形式的：自動スキャンと簡易なレビューが中心で、難読化された悪意コードは検知が難しい。npm の事情とほぼ同じ。
3. 更新が「黙って」走る：自動更新が既定で有効な拡張は、メンテナアカウントが乗っ取られた瞬間に全ユーザーが影響を受ける。ユーザーは新バージョンが入ったことに気づきにくい。
4. EDR の死角になりやすい：開発機の Code.exe や node.exe はもともと多種多様な振る舞いをするため、EDR のヒューリスティックでは異常に見えづらい。

user@sinyblog:~/article ❯ 11_extension-hardening.md対策①：VS Code 拡張のハードニング

個人と組織それぞれが今日から取れる対策を列挙する。「気合で気をつける」ではなく、設定と自動化で強制するのがコツだ。

個人開発者ができること

• 不要な拡張を消す：使っていないものは攻撃面でしかない。半年単位で棚卸し。
• パブリッシャの素性を確認：Marketplace 上の Publisher のドメイン認証（verified バッジ）有無、リポジトリ実体、公開期間、ダウンロード推移を見る。
• 自動更新を任意で無効化：重要な拡張は固定バージョン運用に。"extensions.autoUpdate": false と "extensions.autoCheckUpdates": false を settings.json に設定。
• 怪しい権限要求を疑う：単純な構文ハイライト拡張が、明らかに無関係なネットワーク権限を要求するなら、依存に何か入っている可能性。

組織として強制したいこと

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false,
  "extensions.ignoreRecommendations": true,
  "security.workspace.trust.enabled": true,
  "security.workspace.trust.untrustedFiles": "prompt"
}

• 拡張アロウリスト：エンタープライズ管理機能（Group Policy / MDM）で許可拡張だけインストール可能にする。
• SBOM 化：開発機上の VS Code 拡張一覧を MDM 経由で収集し、IDE 拡張版のソフトウェア部品表（SBOM）として持つ。
• 悪意拡張の即時遮断：今回のように Marketplace から削除された拡張は、社員端末から能動的にアンインストールする運用へ。
• Dev Container / Codespaces 活用：開発作業を使い捨てコンテナや GitHub Codespaces に閉じ込めることで、ローカル機の認証情報を拡張から隔離できる。

user@sinyblog:~/article ❯ 12_token-hardening.md対策②：トークン・シークレット管理の見直し

本件で攻撃者が直接狙ったのはローカルに置かれた認証情報であり、ここを締めれば「拡張に侵入されても被害が広がらない」状態に近づく^[5]。優先順位の高いものから挙げる。

1. 従来型の Classic PAT を廃止し、Fine-grained PAT へ移行：リポジトリ単位・権限単位でスコープを絞れる。repo 全権の PAT は組織ポリシーで禁止する。
2. 長寿命トークンを短寿命トークンへ：GitHub App や OIDC ベースの Workload Identity Federation を使い、CI のたびに発行・廃棄するモデルへ。GitHub Actions ↔ クラウド間は OIDC が標準解。
3. シークレットの所有者と回転手順を全件で定義：これがあるから GitHub は「一晩で重大度順にローテーション」できた^[1]。社内で同じ運用に追随する。
4. ローカル ~/.git-credentials をやめる：プレーンテキスト保管は最初に狙われる。Git Credential Manager のキーチェーン連携、または GitHub CLI の OAuth デバイスフローへ。
5. Secret Scanning Push Protection を有効化：誤って commit したシークレットを push 時点でブロック。GitHub Advanced Security 利用組織は既定で有効化推奨。
6. クラウド側の侵入想定：「鍵が漏れた前提」で IAM 条件付きポリシー（IP、ワークロード ID、デバイスポスチャ）を組む。

user@sinyblog:~/article ❯ 13_actions-hardening.md対策③：GitHub Actions と CI/CD の安全化

同月の Grafana Labs 事案^[11] は別アクターによるものだが、ロジックは TeamPCP 系と地続きだ。Actions まわりで踏むと痛い地雷を並べる。

• pull_request_target を使う場面を最小化：このトリガーはフォーク元コードを書き込み権限付きシークレット付きで実行する。本当に必要な箇所だけに限定し、フォーク PR から取り込んだコードを直接実行しない。
• サードパーティ Actions のピン留め：uses: foo/bar@v3 ではなく、uses: foo/bar@<sha>（コミット SHA）で固定。タグ書き換え攻撃を遮断。
• GITHUB_TOKEN 権限の最小化：ジョブ別に permissions: を contents: read 等まで絞る。デフォルトの「write 全部」運用は禁止に。
• OIDC でクラウドへ：AWS / GCP / Azure 側を OIDC で連携し、長寿命キーを GitHub Secrets に置かない。
• 環境保護ルール：本番 deploy 環境では reviewer 必須・wait timer・ブランチ制限を設定し、悪意ある PR が CD に到達することを防ぐ。

user@sinyblog:~/article ❯ 14_hunting.md対策④：IoC ハンティングと検知

研究機関が公開している Mini Shai-Hulud の IoC を、自社環境で能動的に探しに行ける形にまとめる^[5][6]。本件の悪意拡張そのものの IoC は未公開だが、TeamPCP の他事案で観測されたものは流用可能と考えてよい。

# Mini Shai-Hulud のバックドアパスを確認
ls -la ~/.local/share/kitty/cat.py 2>/dev/null

# 既知の C2 文字列・ドメインを grep で粗探し
grep -r "firedalazer" ~/.vscode/extensions/ 2>/dev/null
grep -r "m-kosche.com" ~/.vscode/extensions/ 2>/dev/null

# 直近インストールされた拡張を新しい順に確認
code --list-extensions --show-versions \
  | xargs -I{} sh -c 'echo {} ; stat -c "%y" ~/.vscode/extensions/{} 2>/dev/null' \
  | sort -k2

# bun が来歴不明な状態でインストールされていないか確認
which bun && bun --version

• ネットワーク側：m-kosche.com（IP 185.95.159.32）へのアウトバウンドを DNS／プロキシログから検索。1 件でもあれば即隔離・調査。
• SIEM 側：開発者端末からの git clone 量の急増、特に深夜帯の数百リポ一斉クローンは検知対象に。
• クラウド側：直近の Personal Access Token の新規発行と即時利用、未登録 IP からの API コール、想定外のリージョンへのアクセスを CloudTrail / Audit Log で監視。

user@sinyblog:~/article ❯ 15_response-playbook.md「もし自社開発者が同じ拡張を入れていたら」初動フロー

続報で悪意拡張の識別子（Publisher / Name / Version）が公表された場合に、社内で素早く回せるよう想定フローを用意しておく。GitHub が一晩で回せた理由は、平時の準備と訓練だ^[1]。

1. 該当端末の特定：MDM／IDE 拡張インベントリから当該 Publisher.Name@Version をインストールしているマシンを列挙
2. 端末の隔離：当該マシンをネットワークから切り離す（VPN・社内 NW・クラウドアクセスを段階的に剥がす）
3. 認証情報のローテーション：当該ユーザーが持つ GitHub PAT・SSH 鍵・OAuth トークン・クラウド資格情報・社内 SSO セッションをすべて失効化
4. 監査ログのレビュー：直近 30 日の GitHub Audit Log / クラウド Audit Log / プロキシログから当該ユーザーの活動を時系列再構成
5. 横展開チェック：当該ユーザーが触れる範囲のリポジトリ・パッケージ・CI ジョブで、Mini Shai-Hulud パターンの commit／branch が無いか確認
6. 復旧：端末をクリーンインストール／新ハードで再構築。トラブルシュート目的での復旧は避ける
7. 事後レビュー：拡張インストールの審査ゲート・自動更新ポリシー・端末隔離手順を見直し、再発防止策を文書化

user@sinyblog:~/article ❯ 99_summary.mdまとめ：この事案がエコシステムに突きつけた問い

今回の事案を一言で言えば、「GitHub すら、IDE 拡張という新しい攻撃面の前では守りきれなかった」という事実が公になった、ということだ。同時に、3,800 件のリポ流出に対し一晩でシークレットを優先度順にローテーションできた運用力という、もうひとつの側面も見えた。本記事の論点を 3 つに集約する。

1. IDE 拡張は npm／PyPI と同等の供給網アタックサーフェスとして扱う段階に入った。組織のセキュリティガバナンスを「拡張インベントリ＋アロウリスト＋自動更新オフ」のラインまで引き上げる必要がある。
2. 「鍵が漏れた前提」のシークレット運用が、攻撃を受けたあと被害が広がらない決定要因になる。Fine-grained PAT・OIDC・ロケーション／ポスチャ条件・回転手順の全件定義をやりきること。
3. 続報を冷静に待つ。悪意拡張の正式な識別子が公開された段階で、本記事 15 章のプレイブックを即実行できる準備を、今のうちに整えておく。

セキュリティは、攻撃の瞬間にできることは限られる。事故が起きるまでに、どれだけ「事故ったときの動き」を仕込めるかで勝負がつく。今回の GitHub 自身の対応スピードは、その仕込みの大切さを実例として示してくれている。