Open VSXは8月16日から8月20日にかけて、悪意ある拡張機能リストから3件の拡張機能IDを削除し、大規模ななりすましキャンペーンで識別子を乗っ取られていた正規開発者の公開権限を復元しました。
今回のブロック解除の対象となったのはAlDuncanson.react-hooks-snippets、magne-sjaastad.opm-flow-editor-support、rumbledb.jsoniq-vscodeの3件で、いずれもManifold Securityが今月初めに報告した77件の拡張機能を悪用した「evil-twin(偽の双子)」キャンペーンで、なりすまし犯によって使われていたものです。この一件は、オープンソースエコシステム全体におけるサプライチェーン攻撃への対策が依然として難しいことを浮き彫りにしています。
いずれのケースも似たようなパターンをたどりました。攻撃者はMicrosoftのVS Codeマーケットプレイスですでに確立されているものの、Open VSXではまだ登録されていない拡張機能名を取得し、そこに悪意あるなりすまし版を公開していました。
その後、正規のメンテナーが自身の拡張機能を公開しようとすると、自分のIDが「既知の悪意あるもの」としてフラグを立てられ、公開をブロックされてしまう事態となりました。
React Hooks Snippetsのメンテナーであるアル・ダンカン氏は、この壁にぶつかった後、8月16日にブロック解除を要請しました。Open VSXのメンテナーは同日、このキャンペーンとの関連性を確認しIDを削除しましたが、Socketの脅威分析によると、8月24日時点でOpen VSX上に正規版のリリースはまだ公開されていません。
OPM Flow Editor Supportのメンテナーも同日に同様の要請を提出しました。Open VSXは8月18日にこのIDをリストから除外し、正規版の[email protected]は8月21日に公開されました。
RumbleDBのJSONiq/XQuery拡張機能は、最も長い経緯をたどりました。対応するマーケットプレイスの発行者アカウントおよびソースリポジトリの詳細情報で所有権を証明した後も、IDがブロックリストに残ったままだったため、チームがアップロードした版が一時的に消えてしまうという事態が発生しました。Open VSXは8月20日にこれを修正し、[email protected]は8月23日に公開されました。
Open VSXは8月3日までに、悪意あるパッケージ77件すべてを削除していました。正規の発行者たちは侵害を受けたわけでも、キャンペーンに関与していたわけでもなく、攻撃者が単に未登録の名前空間を先取りしていただけでした。
根本的な問題は構造的なものです。Open VSXの悪意ある拡張機能リストは、バージョン、ファイルハッシュ、発行者アカウント、タイムスタンプといった情報を一切持たない、ID文字列だけの単純な配列になっています。
あるIDに紐づくすべてのバージョンが悪意あるものである場合はこの仕組みでも機能しますが、正規の所有者が名前を取り戻した途端に破綻します。IDを削除すれば正規パッケージのブロックは解除されますが、それと同時に、同じ識別子がかつてマルウェアに使われていたという可視化された記録も消えてしまうのです(Gitの履歴自体には依然としてその痕跡が残っているものの)。
Socketのエンジニア、ジョン・タックナー氏はこの問題を継続的に追跡しており、過去1年間でOpen VSX上において491件のIDが不正に先取り登録されたことを記録しています。そのうち338件は2026年だけで発生したもので、なりすまし拡張機能415件はMicrosoftの上位1万件にランクインするものでした。
3月に発生したcarbon-lang.carbon-vscodeをめぐる事例は、これが決して新しい問題ではないことを示していますが、公にキャンペーンとして帰属付けられた証拠がないため、Socketはこの件を確認済みのevil-twin復元事例には数えていません。
Open VSXは、取り戻されたIDの扱いに関する一般的なポリシーをまだ公表していません。8月12日にリリースされた、不変バージョンと変更履歴フィードを導入するアップデートでも、悪意あるものから正規のものへと変わったIDを下流の利用者がどう扱うべきかについては触れられていません。
Socketは、悪意あるパッケージによるキャンペーンから身を守るため、組織に対して拡張機能IDだけでなく、正確なバージョン、ファイルハッシュ、発行者の身元、ソースリポジトリを併せて記録し、拒否ルールは単なるID自体ではなく特定の悪意あるアーティファクトに紐づけて維持するよう推奨しています。
VS Codeの拡張機能構成をOpen VSXベースのエディタへ移行するチームは、マーケットプレイス間で名前が一致するからといって信用するのではなく、発行者を独自に検証すべきです。
一方でメンテナー側は、攻撃者に先んじて自らOpen VSXの名前空間を取得しておくことで、この問題全体を未然に防ぐことができます。
翻訳元: https://cyberpress.org/open-vsx-malicious-extensions/
