0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kenimo49(Imoto Ken)

あなたのCursor拡張はコード全文を読んでいる。人気拡張の権限を監査した

0
Last updated at Posted at 2026-06-18

VSCode/Cursor拡張が権限確認なしでワークスペース全文を読み、外部送信できる構造とNx Console事故3800リポ流出・GlassWorm35800DL・偽Solidity拡張50万ドル窃取の監査図

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

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の権限宣言と公式telemetry仕様をもとに、拡張のリスクを分類しました。

以下は「個別拡張を名指しで危険認定する表」ではありません。VSCode拡張という仕組みが構造的に持つ権限カテゴリと、それぞれの監査ポイントを整理した表です。実在拡張の悪性認定は、上記の公開事故レポートに準拠します。

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

この表が示すのは、最重要のリスク(ファイル権限・外部通信)がmanifestに現れないという事実です。package.jsonを読んでも、その拡張が外部に何を送るかは書いていません。実装を読むしかない。だから「manifest監査だけで安全判定はできない」。これは正直に書いておきます。

manifest監査でわかるのは、activationEventsの広さと、宣言済みtelemetryの有無、発行元情報まで。残りは事故レポートとコミュニティの実績で補う。これが現実的な監査設計です。

実際のpackage.jsonで危険信号になるのは、こういう宣言です。

{
  "name": "innocent-looking-extension",
  "publisher": "unknown-publisher",
  "activationEvents": [
    "*"
  ],
  "main": "./out/extension.js",
  "dependencies": {
    "node-fetch": "^3.0.0",
    "child_process": "*"
  },
  "contributes": {
    "configuration": {
      "properties": {
        "myExt.telemetry.enabled": {
          "type": "boolean",
          "default": true,
          "tags": ["telemetry", "usesOnlineServices"]
        }
      }
    }
  }
}

activationEventsが*、node-fetchとchild_processの同居、usesOnlineServicesタグ。単体では合法でも、3つ揃うと「全ワークスペースで起動し、外部通信し、子プロセスを起動する」拡張だとわかります。発行元がunknownなら、私は入れません。

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

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

ポイントは、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個から始めてみませんか。私が見落としている監査軸があれば、コメントで教えてください。一緒に精度を上げていきましょう。

参考文献

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?