GitHub内部repo不正アクセス公表｜悪性エディタ拡張とgh token流出で今日やること

先に結論

GitHub の今回の公表で先に読むべきなのは、customer repo に広がった事故かどうか ではありません。影響端末があるなら、そこで触れた credential を今日中に回すべき事故かどうか です。

現時点で GitHub は、確認している流出先を GitHub-owned repositories に限定しています。customer enterprises、organizations、repositories への直接影響の証拠はないという説明です。

ただし、Nx Console 側の advisory はかなり重いです。悪性拡張が gh token、Actions secrets、SSH key、cloud credential まで広く狙ったと明示しています。影響端末があるなら、「GitHub に直接被害が広がったか」を待つ理由はありません。

CI/CD 側の恒久対策まで整理したいなら、GitHub Actions security roadmap 2026 で何が変わる？CI/CD セキュリティ選定ガイド も先に見ておくとつながります。

まず切り分けたいのは GitHub の公表内容と Nx advisory の範囲

この件は、2つの情報を混ぜると判断を誤ります。

GitHub の security notice は、5月18日に employee device compromise を検知し、GitHub-owned repositories の情報流出を調査中だと説明しています。critical secrets は優先度順に rotation を進めたとも明記しました。

一方で Nx Console advisory は、悪性拡張 18.95.0 の公開時間、IoC、窃取対象 credential、削除対象ファイル、今すぐやる remediation を具体的に書いています。

要するに、GitHub の公表は影響範囲の説明 で、Nx advisory は現場作業の手順書 です。

customer repo への直接影響が未確認という GitHub の文言は大事です。ただ、それは端末由来の credential rotation を後回しにしてよい、という意味ではありません。

何が起きたのか

GitHub は、poisoned VS Code extension を経由した employee device compromise を起点に incident response を始めたと説明しています。

現時点の評価では、活動は GitHub 内部リポジトリの流出に限られているとしています。攻撃者が主張する約3,800リポジトリという数字は、方向感としては調査と整合すると述べています。

一方で Nx Console advisory は、侵害版 18.95.0 が Visual Studio Marketplace で約18分、OpenVSX で約36分公開されていたと更新しました。さらに 5月22日の更新では、Cursor からの activation が 1 件あったことも追記しています。

ここで見るべきなのは、拡張が公開されていた時間の短さではありません。公開時間が短くても、影響端末上では persistence と credential harvesting が続きうること です。

今日すぐ確認したい IoC

Nx advisory が挙げている IoC は、かなり実務的です。

macOS と Linux では cat.py、com.user.kitty-monitor.plist、/var/tmp/.gh_update_state、/tmp/kitty-* が代表例です。Windows でも .gh_update_state や kitty-* が挙がっています。

プロセス面では、cat.py を走らせる Python process や __DAEMONIZED=1 を持つ process が指標になります。

つまり、まずやることは3つです。

1. 影響時間帯に Nx Console 18.95.0 を入れていないか確認する
2. 端末に永続化痕跡が残っていないか確認する
3. 悪性 process を止める

rotation だけ先に走らせても、端末側に process が残っていれば意味が薄れます。先に止血です。

何を優先して回すべきか

Nx advisory が重いのは、狙われた credential の範囲が広いからです。

GitHub では ghp_、gho_、ghs_ token、Actions secrets、process memory 上の token が対象に含まれます。加えて SSH key、Vault token、AWS metadata、Secrets Manager、SSM、Web Identity token、1Password の active session まで列挙されています。

優先順位はこう考えると動きやすいです。

今日中にやる

• gh token、PAT、SSH key の rotation
• GitHub Actions secrets と environment secrets の棚卸しと rotation
• cloud credential と Vault token の rotation
• 影響アカウントの access log 確認

明日までにやる

• 影響端末で使われた editor 拡張の配布経路確認
• OpenVSX と VS Code Marketplace の許可方針見直し
• 長寿命 token を減らし、OIDC や短命 credential に寄せる設計確認

今週やる

• 開発端末の least privilege 見直し
• extension install の承認フロー見直し
• self-hosted runner や CI 用 secret 境界の棚卸し

GitHub 標準運用へ寄せたいなら、GitHub Advanced Security や GitHub Copilot coding agent vs Claude Code vs Codex｜監査性・安全性・レビュー運用で選ぶ の文脈で、secret scanning と監査導線も一緒に見直したほうが後戻りしにくいです。

なぜ gh token の話が特に重いのか

今回の advisory では、TanStack 側の supply-chain compromise から GitHub CLI を通じた credential leakage が attack vector として追記されました。

この一点だけでも、開発端末の gh 認証を「便利なローカル設定」として放置しないほうがいい理由になります。

gh は repo 操作、PR、Actions、secret 周辺まで広く触れるため、漏れた後の横展開が速いです。GitHub 側が critical secrets を優先 rotation したのも自然です。

ここからの教訓は単純です。長寿命 token を減らし、権限を細かくし、端末 compromise を前提に回せる設計へ寄せるべきです。

今回の件で見直したい恒久対策

今回の incident を単発のニュースで終わらせると、次にまた詰まります。

まず見直したいのは、拡張配布の承認フロー です。VS Code Marketplace と OpenVSX を同じ安全度で見ないほうがよく、Cursor のような fork まで含めて許可経路を明示したほうが安全です。

次に、開発端末の credential の置き方 です。長寿命 token をローカルに広く置くほど、端末 compromise の被害は増えます。OIDC や短命 credential に寄せられる部分は寄せたほうがよいです。

最後に、CI/CD の境界 です。Actions secrets、reusable workflow、runner 権限、outbound 通信の監査は一緒に見たほうが効きます。そこは GitHub Actions security roadmap 2026 で何が変わる？CI/CD セキュリティ選定ガイド がちょうどつながります。

迷ったらこの順で動く

最後に、現場で止まりにくい順番だけ残します。

1. 影響端末の有無を切り分ける
2. 悪性 process と persistence を止める
3. gh token、PAT、Actions secrets、SSH key、cloud credential を回す
4. access log を確認する
5. 拡張配布と developer endpoint hardening の恒久対策を決める

現時点で customer repo への直接影響は未確認です。ただ、端末 compromise と credential harvesting の可能性があるなら、運用側はもう動いてよい段階 です。