「便利だから入れる」。私もずっとそうでした。

VSCodeやCursorの拡張は、クリック1回で入ります。そして入れた瞬間から、その拡張はあなたのワークスペース全文を読む権限を持ちます。確認も同意も求められません。

これは煽りではなく、設計です。VSCodeには拡張の権限モデルが存在しません。Androidのような「カメラを許可しますか」の画面は、拡張には一切ありません。

この記事は、私が以前書いた3本とは別の話です。npmの.env漏洩でもなく、Shai-Huludのnpm依存汚染でもなく、browser agentに渡すOSSの話でもない。今回はエディタ拡張そのものが黙って持つ権限を、manifest宣言と公式telemetry設定と2026年の実際の事故から監査します。

本記事は live packet capture ではなく、package.json(manifest)の権限宣言、VSCode公式のtelemetry仕様、公開済みの事故レポートを根拠に構成しています。実データは出典付きで断定し、推測部分は「推測」と明記します。

TL;DR(先に結論)

VSCode拡張には権限モデルがない。入れた拡張は全員、ワークスペース全文とNode.js経由のOS資源にアクセスできる(出典: Wiz)
2026年5月、検証済み発行元のNx Console拡張(220万install)が約11〜18分だけ汚染され、GitHubの内部リポジトリ約3,800件が流出した(出典: GitHub, The Hacker News)
2025年10月、自己増殖するワーム「GlassWorm」がOpen VSXで拡散。初動7拡張で約35,800ダウンロード、49種の暗号資産ウォレット拡張を標的にした(出典: Truesec, Koi)
2026年7月、Cursor向け偽Solidity拡張で約50万ドルの暗号資産が盗まれた。5.4万回DLされていた(出典: SC Media, The Hacker News)
防御は4つ。発行元verified確認、telemetry無効化、extensions.json管理、棚卸し。記事末尾にチェックリストを置きます

なぜ「拡張は安全」という前提が崩れているのか

結論から言います。VSCode拡張は、入れた時点でほぼ無制限の権限を得ます。

VSCode公式のExtension APIには、Android的な権限分離がありません。これはMicrosoft自身がissue #187386で議論している既知の構造です。あるのは「Workspace Trust」というbinaryな信頼スイッチだけ。フォルダを信頼するか、しないか。その2択です。

Wizの調査は、権限チェックなしで拡張が使えるAPIを具体的に挙げています。

ターミナルで任意コマンドを実行する
ソースコードやcommit履歴を開発者に黙って改変する
認証トークンや認証情報を捕捉する
他の拡張の挙動に干渉する
デバッグ中にアプリの動作を書き換える

しかも拡張はNode.jsの第三者依存をそのまま取り込めます。つまりNode.jsができることは、拡張もできる。ワークスペースのファイル読み取りも、外部サーバーへの送信も、OSとの対話も、技術的には全部可能です(出典: Wiz, VSCode公式)。

私が「便利だから入れる」を続けていたのは、スマホアプリの権限画面に慣れすぎていたからでした。エディタには、あの画面がない。だから無防備でいられた。これが第一の盲点です。

拡張が黙って持つ権限の通信フロー

拡張がインストールされてから何が起きるかを、図にしました。

赤いノードが、権限確認なしで通過する箇所です。activationEventsが*(全イベント)に設定されていれば、ワークスペースを開いた瞬間に拡張が走り出します。Nx Console事故で「開いた瞬間に認証情報を集めた」というのは、まさにこの挙動です。

2026年に実際に起きた拡張サプライチェーン事故

「理論上は危険」で止まる話ではありません。2025〜2026年に、実害が連発しました。

事故1: Nx Console汚染とGitHub内部リポ3,800件流出(2026年5月)

2026年5月18日、Nx ConsoleのVSCode拡張(220万install、検証済み発行元)に悪性版が公開されました。Marketplaceに乗っていたのは約11〜18分。Nxチームが12:47 UTCに削除しました。

しかし、その短時間で十分でした。悪性版は、開発者がワークスペースを開いた瞬間から認証情報を静かに収集。翌5月19日、GitHubは内部リポジトリ約3,800件が流出したと公表しました。GitHub従業員が公式Marketplaceから悪性拡張を入れ、その端末を起点に攻撃者が横展開したのです(出典: GitHub, The Hacker News, Aikido)。

攻撃者「TeamPCP」は、GitHubトークンを盗み、orphan commitを作り、汚染拡張を公開する手口を使いました。TeamPCPは2026年3月以降、確認できるだけで7波以上の攻撃を実行。Trivy、Checkmarx KICS、LiteLLM、Bitwarden CLIなども標的にしています(出典: The Hacker News, securityonline)。

ここが恐ろしい点です。発行元はverified、install数は220万。「信頼できる拡張」の条件を全部満たしていた拡張が、トークン窃取で乗っ取られました。verifiedは「発行元が誰か」を保証するだけで、「中身が安全か」は保証しません。

事故2: GlassWorm 自己増殖ワーム(2025年10月〜)

2025年10月17日、Open VSX上の拡張「CodeJoy」v1.8.3で不審な挙動が検知されました。これがGlassWorm、VSCode拡張で初の自己増殖ワームです。

初動は7拡張で約35,800ダウンロード(出典: Truesec, Koi)。GlassWormの特徴は3つあります。

不可視のUnicode文字で悪性コードをレビューから隠す
Solanaブロックチェーンを使ったC2でテイクダウン困難
NPM/GitHub/Git認証情報を奪い、49種の暗号資産ウォレット拡張を標的にする

奪った認証情報で別の拡張を自動汚染し、指数関数的に広がります。標的はVSCodeだけでなくCursor、Windsurf、VSCodium、Positronにも及びました。2026年3月時点で計72のOpen VSX拡張が関連づけられています(出典: The Hacker News, Socket)。2026年5月26日、CrowdStrike主導でインフラが一部停止されました。

事故3: 偽Solidity拡張で50万ドル窃取(2026年7月)

2026年7月、Cursor向けの偽Solidity拡張で、ロシアの開発者から約50万ドルの暗号資産が盗まれました。Solidityのシンタックスハイライトを装った悪性パッケージで、検知・削除までに5.4万回以上DLされていました(出典: SC Media, The Hacker News)。

事故4: フォークが「存在しない拡張」を推薦(2025年末)

Cursor、Windsurf、Google Antigravityなどのフォークは、ライセンス上Microsoft公式Marketplaceを使えず、Open VSXに依存します。問題は、これらが「Open VSXに存在しない拡張」を推薦していたことです。

攻撃者がその名前で悪性拡張を登録すれば、開発者は推薦に従って入れてしまう。Cursorは2025年12月1日に修正、Googleは2026年1月までに対応しました(出典: The Hacker News, BleepingComputer)。

監査軸	manifestで見る箇所	何がわかるか	リスク
起動条件	`activationEvents`	`*`なら全ワークスペースで即起動	高
ファイル権限	(宣言なし)	VSCodeに権限分離がなく全文読取可能	高
外部通信	コード本体 / 依存	manifestには現れず実装依存	高
Node.js依存	`dependencies`	第三者依存経由でOS資源に到達	高
telemetry	`configuration`の`telemetry`タグ	利用データ送信先と内容	中
発行元	publisher / verified	「誰が出したか」のみ保証	中
install規模	Marketplace表示	多い=標的にされやすい	中

拡張を監査する判断フローチャート

では、目の前の拡張を入れるべきか。判断手順を図にしました。

ポイントは、verifiedを通過点として扱い、ゴールにしないことです。Nx Console事故が証明したように、verifiedでも乗っ取られます。だから「verified且つinstall多い且つactivationEventsが妥当」の重ね合わせで判断します。投資のリスク分散と同じ発想で、1つの指標に賭けない。

防御策1: telemetryを無効化する

VSCode本体のtelemetryは、設定1つで止まります。settings.jsonにこう書きます。

{
  "telemetry.telemetryLevel": "off",
  "redhat.telemetry.enabled": false,
  "workbench.enableExperiments": false,
  "extensions.autoCheckUpdates": false
}

telemetry.telemetryLevelをoffにすると、Microsoftへの利用データ送信が止まります。重要なのは、まともな拡張はisTelemetryEnabledとonDidChangeTelemetryEnabledを尊重する義務がある点です(出典: VSCode公式)。

つまりこの設定は、本体telemetryだけでなく、行儀の良い拡張のtelemetryも連動して止めます。逆に言えば、この設定を無視して送信を続ける拡張は、その時点で要注意です。Red Hat系拡張はredhat.telemetry.enabledという独自設定を持つので、個別に切ります。

防御策2: extensions.jsonで推薦と禁止を管理する

.vscode/extensions.jsonは、チームで拡張を統制する仕組みです。推薦と「入れてほしくない」拡張の両方を書けます。

{
  "recommendations": [
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode"
  ],
  "unwantedRecommendations": [
    "some.deprecated-extension",
    "suspicious.unknown-extension"
  ]
}

recommendationsはチームで使う拡張のホワイトリスト。unwantedRecommendationsは警告対象です。フォークが「存在しない拡張」を推薦する問題(事故4)への対策として、リポジトリ側で推薦を固定する意味があります。チームのリポジトリに置けば、新メンバーが勝手な拡張を入れる前に警告が出ます。

防御策3: 発行元verifiedとOpen VSXの注意点

verifiedの青いチェックは、発行元がドメイン所有を証明したことを意味します。中身の安全性は意味しません(出典: BleepingComputer)。

確認項目	意味すること	意味しないこと
Verified Publisher	発行元のドメイン所有	拡張コードの安全性
install数	普及度	無害である保証
評価/レビュー	ユーザー体感	セキュリティ監査
Open VSX掲載	フォークで使える	Microsoft同等の審査

Cursorなどフォークが使うOpen VSXは、Microsoft Marketplaceと同等の審査ではありません。GlassWormがOpen VSXを起点にしたのは偶然ではない。フォークユーザーは、この差を前提に拡張を選ぶべきです。Eclipse Foundationは非公式contributorの排除など対策を進めていますが、構造的なリスクは残ります。

棚卸しを習慣にする理由

最後に、いちばん地味で効く防御を。入れっぱなしの拡張を、定期的に棚卸しすることです。

私が信長の野望を15年やって学んだのは、布石は打った後に効くということです。拡張も同じで、使わなくなった拡張を放置すると、それがある日アップデートで乗っ取られる。Nx Console事故も、攻撃の入口は「すでに入っていた拡張」のアップデートでした。

インストール済み拡張の一覧は、こう取れます。

# インストール済み拡張をバージョン付きで一覧
code --list-extensions --show-versions

# Cursor の場合
cursor --list-extensions --show-versions

この出力をリポジトリに保存しておけば、差分で「いつの間にか増えた拡張」に気づけます。月1回の棚卸しを、依存ライブラリのnpm auditと同じ感覚で回す。これが効きます。

拡張棚卸しチェックリスト

明日から使える形にまとめました。

code --list-extensions --show-versionsで全拡張を棚卸ししたか
半年使っていない拡張を削除したか
各拡張の発行元verifiedを確認したか(過信はしない)
activationEventsが*の拡張を把握しているか
settings.jsonでtelemetry.telemetryLevel: offにしたか
Red Hat等の独自telemetry設定を個別に切ったか
チームリポジトリに.vscode/extensions.jsonを置いたか
unwantedRecommendationsに非推奨拡張を登録したか
Cursor等フォーク利用時、Open VSXのリスクを認識しているか
拡張一覧をリポジトリ保存し、差分監視しているか
extensions.autoCheckUpdates: falseで自動更新を制御したか
月1回の棚卸しをルーティン化したか

おわりに

VSCode拡張に権限モデルがない以上、私たちが手動で権限を監査するしかありません。manifest監査で全部はわからない。それでもactivationEventsとtelemetry宣言と発行元を見るだけで、判断の解像度は上がります。残りは事故レポートで補う。完璧ではないが、無防備よりはるかにマシです。

Nx Console事故で流出したのは3,800リポジトリ。きっかけは従業員1人が入れた1拡張でした。あなたの環境の入口は、いま何個開いていますか。

最後に問いを置きます。みなさんは拡張を入れるとき、package.jsonを見ていますか。見ていないなら、次の1個から始めてみませんか。私が見落としている監査軸があれば、コメントで教えてください。一緒に精度を上げていきましょう。

参考文献

GitHub Internal Repositories Breached via Compromised Nx Console VS Code Extension / The Hacker News (2026): https://thehackernews.com/2026/05/github-internal-repositories-breached.html
GitHub Breached via VS Code Extension / Aikido (2026): https://www.aikido.dev/blog/github-breached-vs-code-extension
Supply Chain Risk in VSCode Extension Marketplaces / Wiz Blog: https://www.wiz.io/blog/supply-chain-risk-in-vscode-extension-marketplaces
GlassWorm - Self-Propagating VSCode Extension Worm / Truesec: https://www.truesec.com/hub/blog/glassworm-self-propagating-vscode-extension
GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions / The Hacker News (2026): https://thehackernews.com/2026/03/glassworm-supply-chain-attack-abuses-72.html
72 Malicious Open VSX Extensions Linked to GlassWorm / Socket: https://socket.dev/blog/open-vsx-transitive-glassworm-campaign
AI IDEs pushed fake extensions, posing malware risk / SC Media: https://www.scworld.com/news/ai-ides-pushed-fake-extensions-posing-malware-risk-say-researchers
VS Code Forks Recommend Missing Extensions / The Hacker News (2026): https://thehackernews.com/2026/01/vs-code-forks-recommend-missing.html
VSCode IDE forks expose users to "recommended extension" attacks / BleepingComputer: https://www.bleepingcomputer.com/news/security/vscode-ide-forks-expose-users-to-recommended-extension-attacks/
Telemetry / VS Code 公式ドキュメント: https://code.visualstudio.com/docs/configure/telemetry
Telemetry extension authors guide / VS Code Extension API: https://code.visualstudio.com/api/extension-guides/telemetry
Support for Permission System in VS Code Extensions (Issue #187386) / microsoft/vscode: https://github.com/microsoft/vscode/issues/187386