Koi Securityのセキュリティ研究者が、現代のAIコーディングツールのインフラ深くに埋め込まれた重大なゼロデイ脆弱性を偶然発見しました。もし悪用されていれば、技術的に高度でない攻撃者でも、たった一度の攻撃で1,000万台以上のマシンを乗っ取ることができたでしょう。
CursorやWindsurfのようなAIコーディングアシスタントは、世界中の開発者の生産性を飛躍的に高めると約束し、急速に人気を集めています。その洗練されたインターフェースの裏には、コミュニティ主導で作られたVS Codeのフォークと、拡張機能のオープンマーケットプレイスという共通の基盤があります。しかし、この新しい開発者ツールの波には、危険な盲点が潜んでいました。
VSXPloitと名付けられた脆弱性： 開発者サプライチェーンの重要な構成要素であるOpenVSXに見落とされたたった一つの欠陥が、VS Codeフォークを実行しているあらゆるマシンで、静かにシステム全体を乗っ取ることを可能にしていました。たった一つのバグで、完全な制御が可能でした。
詳しく見ていきましょう。
現在のAI搭載エディタは、基本的な機能を提供するために拡張機能に大きく依存しています。シンタックスハイライトやリンティング、デバッグといった機能はエディタに直接組み込まれているわけではなく、拡張機能によって提供されています。
これらの拡張機能はすべて、開発者のマシン上でフル権限で実行されます。つまり、1つの拡張機能が侵害されるだけで、それをインストールした人のマシン全体が乗っ取られる可能性があるのです。
まさにこの悪夢のようなシナリオを、ソフトウェアの配布や拡張機能のセキュリティプラットフォームを提供するKoi Securityのセキュリティ研究者Oren Yomtov氏が発見しました。
最近の投稿でYomtov氏は、Cursor、Windsurf、VSCodiumなどのツール向け拡張機能を支えるオープンソースマーケットプレイスであるOpenVSXのビルドプロセスを調査していた際、重大な欠陥を発見したと説明しています。
この脆弱性により、攻撃者は単一の拡張機能を乗っ取るだけでなく、サプライチェーン全体を制御し、マーケットプレイス全体を掌握することができました。
この欠陥があれば、攻撃者は信頼された@open-vsxアカウントのもとで悪意あるアップデートを配信できました。最初、Yomtov氏はこれは何かの間違いだと思いました。このコードは何年も稼働し、何千万人ものユーザーが使ってきたからです。しかし、彼が自分のラボで攻撃を再現すると、シミュレーションは完璧に成功しました。
考えられなかったはずのことが、突然現実になりました。静かに進行する大規模なセキュリティ災害が、目の前にあったのです。
脆弱性の詳細：古典的な「Pwn Request」の変種
この脆弱性がどのように機能したのか理解するには、まず拡張機能がどのようにしてOpenVSXに追加されるのかを知る必要があります。
Open VSXに拡張機能を公開したい場合、選択肢は2つあります：
-
自分でOpen VSXにアップロードする
-
extensions.jsonファイルのリストに拡張機能を追加するプルリクエストを作成し、自動公開をリクエストする
「問題はナイトリービルドにあります」とYomtov氏は言います。
毎晩、OpenVSXはコミュニティから提出された拡張機能の最新版を自動で取得し、ビルドし、マーケットプレイスに公開します。これは開発者の手間を減らすための仕組みですが、今回の場合は重大な欠陥を生み出していました。
拡張機能を自動公開するには、開発者は単純なプルリクエストで公開リストに追加するだけで済みます。そこからOpenVSXが処理を引き継ぎ、コードを取得し、依存関係をインストールし、拡張機能をビルドし、信頼された@open-vsxアカウントの強力なシークレットトークンを使って公開します。
このトークンは本来、信頼されたインフラだけが見られるはずのものでした。しかし、ビルドプロセスが公開リポジトリから任意のコードを実行する仕組みのため、どんな拡張機能の作者でもトークンを密かに取得する悪意あるアップデートを作成できてしまいました。
さらに恐ろしいのは、悪意ある拡張機能を直接提出する必要すらなかったことです。依存関係や、そのまた依存関係に悪意あるコードを仕込むこともでき、システムはナイトリービルド中に自動でそれを実行してしまいます。そこからトークンを盗むのは簡単でした。
そしてこのトークンを手にした攻撃者は、自分の拡張機能だけでなく、アップデートの公開や既存拡張機能の上書き、マーケットプレイス全体の乗っ取りまでできてしまうのです。
影響：数百万の開発者を危険にさらすサプライチェーンの悪夢
@open-vsxアカウントのトークンにアクセスできれば、攻撃者は世界規模のサプライチェーンの悪夢を引き起こせました。「このトークンはスーパ管理者の認証情報です」とYomtov氏は説明します。「新しい拡張機能の公開、既存拡張機能の上書き、エコシステム内のどのパブリッシャーにもなりすますことができます。」
そこから先の被害はほとんど手間がかかりません。開発者が拡張機能をインストールするたび、あるいはエディタがバックグラウンドで自動アップデートするたび（これは常に発生しています）、攻撃者のペイロードが静かにマシンに配信されます。警告も、プロンプトも、疑いもなく、完全に乗っ取られます。
そのペイロードは何ができるのでしょうか？「ほぼ何でもできます」とYomtov氏。VS Codeやそのフォークの拡張機能はNode.jsプロセスとして動作するため、ファイルへのアクセス、他プログラムの起動、ネットワークリクエスト、任意のコード実行が可能です。
たとえば人気のPythonプラグインに悪意あるアップデートを仕込めば、キーロガーのインストール、ブラウザのクッキー窃取、ソースコードの盗難、ビルドの感染、開発パイプライン全体のバックドア化など、静かに実行できます。
過去にも、悪意あるVS Code拡張機能がSSHキーや暗号通貨ウォレットを盗む事例はありました。しかし、これは一部の悪意ある開発者がすり抜ける話ではありません。エコシステム全体を巻き込むサプライチェーンの大規模な乗っ取りです。まるでSolarWinds事件の開発者ツール版のようなものです。
最も深刻な影響はCursor、Windsurf、VSCodiumなどのデスクトップエディタですが、GitpodやStackBlitzのようなブラウザベースの環境も、拡張機能の統合度合いによっては影響を受ける可能性があります。
では、どうすればよいのでしょうか？
この件からユーザーや組織は何を学ぶべきか、Yomtov氏に尋ねました。彼の答えは率直でした。「すべての拡張機能は、信頼できると証明されるまで信用しないことです。」
拡張機能は無害なアドオンのように感じられるかもしれませんが、実際には強力なソフトウェアコンポーネントであり、多くの場合個人が作成し、フル権限で動作し、監視なしで自動更新されます。
「npmやPyPIからパッケージを取り込むのと同じ、いやそれ以上に危険です」とYomtov氏。「もしGitHubリポジトリにroot権限を無条件で与えないのであれば、拡張機能も同じく信用すべきではありません。」
自衛のために、Yomtov氏は組織が拡張機能も攻撃対象領域の一部とみなし、他の依存関係と同じ厳格さで管理することを推奨しています。つまり：
-
インベントリの維持：どのマシンに、誰が、何をインストールしているかを正確に把握する
-
リスク評価：誰が作成し、どのようにメンテナンスされ、実際に何をしているのかを基にリスクを評価する
-
明確なポリシーの徹底：許可されるものを明確にし、逸脱があれば対処する
-
継続的な監視：拡張機能は静かに更新され、新たなリスクを夜間に持ち込む可能性があるため、常に監視する
Koiの研究チームは、OpenVSXやMicrosoftのマーケットプレイスだけでなく、Chromeウェブストアなど他の拡張機能マーケットプレイスでも、脆弱または実際に悪意ある拡張機能を発見し続けています。
「エコシステムの成長がガードレールの整備を上回っています」とYomtov氏。「それが変わるまでは、ゼロトラスト（無条件不信）が最も安全な前提です。レビューし、監視していない限り、すべての拡張機能は潜在的なバックドアだと考えるべきです。」
Yomtov氏とKoi Securityのチームは、OpenVSXプロジェクトを管理するEclipse Foundationに責任を持って脆弱性を報告しました。その後数週間、メンテナーと緊密に連携し、問題の検証、堅牢な修正の設計、パッチの正しい実装と展開を行いました。
この協力のおかげで、脆弱性は修正され、何百万人もの開発者が日々頼るマーケットプレイスは再び安全になりました。
しかし、この事件は警鐘でもあります。たとえ信頼されたインフラでも、エコシステム全体の鍵を握る場合は特に、常に厳しい監視が必要なのです。
Koiがどのようにして組織のVSCode、OpenVSX、Chrome、その他マーケットプレイスにおけるリスクのある拡張機能の発見、評価、管理を支援しているかをご覧ください
ご相談はこちら。
Koi Securityによるスポンサード記事・執筆。