偽Open VSX拡張機能がAMD、Azure、Salesforce、政府機関の名前空間を乗っ取る

偽のOpen VSX拡張機能が、Open VSXレジストリ上でAMD、Azure、Salesforce、Hyperledger、そして米国政府機関といった高い信頼性を持つ名前空間を乗っ取り、開発者やCI環境からGitおよびCIのメタデータを密かに収集しながら、正規のツールを装っていたことが分かりました。

各パッケージは、実在する無関係な拡張機能の名前・名前空間・説明文をそのまま複製し、名前空間の所有者でも元の作者でもない匿名アカウントから、通常は0.0.1という低いバージョン番号で再公開されていました。

いわば、これらは実在する拡張機能の「悪意ある双子」でした。名前や説明では区別がつかないものの、内部では攻撃者が管理するインフラに接続する仕組みが組み込まれていたのです。

2026年8月3日時点で、Open VSX Extensionsはこれら悪意あるリスティングを削除済みです。ただし、このテイクダウンによって既に展開されたコードが無効になるわけではありません。これらの名前のいずれかに固定されたイメージ、ワークスペース設定、devcontainerは、今後もローカルで拡張機能を読み込み続け、エディタが起動するたびにビーコンを発信し続けます。

今回確認された77個のサンプルは、明確に二分されるわけではなく一つの連続体を成していますが、大きく分けると「軽量ビーコン」と「本格的な偵察ペイロード」の2種類に分類できます。

58個は約1.6~3.3KBの小さなもので、マシンのホスト名、場合によってはワークスペースのフォルダ名やエディタのバージョン、さらにパッケージごとの追跡IDを送信します。

送信方法は、/api/v1/metricsや/api/v1/eventsへのPOSTリクエスト、GETクエリ文字列、複数エンドポイントへのフェイルオーバーロジックなど様々ですが、収集されるデータ自体は限定的です。

これらの亜種は、ソースコードには触れないものの、マシンを特定し、偽装パッケージと紐付けるには十分な情報を収集します。

一方、19個はより大規模なペイロード(約10KB)を持ち、有効化から数秒後に包括的な環境プロファイリングを実行します。

1回のリクエストで、ホスト名とOSユーザー名、エディタ名とバージョン、ホストの種類とマシンID、プラットフォームとアーキテクチャ、ロケールとタイムゾーン、さらに開いているワークスペースのフォルダ名とファイルシステム上のフルパスまでをまとめて送信します。

さらに.gitディレクトリを解析し、originおよびupstreamのリモート先をホストと組織名に絞り込んだ情報、コミットメールアドレスのドメイン部分、現在のブランチとHEADのコミットSHA、そしてインストール済み拡張機能のIDを最大60件まで取得します。

2026年7月26日から8月1日にかけて、Manifold Securityは77個の偽Open VSX拡張機能が、新しく登録された同一ドメインmangorbit[.]comにビーコンを送信していることを確認しました。

CI環境からは、マーカー名や、GITHUB_REPOSITORY、CI_PROJECT_PATH、Azure DevOpsのコレクションURI、Buildkiteの組織スラッグ、CircleCIのプロジェクトユーザー名、Codespace名、Gitpodのコンテキストのurlの値を収集します。これにより、CIやクラウド開発環境上で稼働しているプロジェクトの、プライベートリポジトリのフルパスが判明してしまいます。

この拡張機能はまた、エディタのテレメトリ・オプトアウト設定を読み取りますが、その設定に関わらずデータを送信します。

偵察型の亜種は、こうした挙動の大部分をOpen VSXのリスティング上で「Telemetry(テレメトリ)」セクションとして公然と記載していました。

ホスト名、ユーザー名、ワークスペースパス、Gitの組織名とメールドメイン、ブランチ、コミットといった情報はすべて開示されており、あわせて「ソースコード、認証情報、トークン、SSH関連情報、ブラウザデータ、任意の環境変数、ファイルシステムの変更は一切扱わない」という保証も記載されていました。Manifoldによるコードレビューでは、これらの制限自体はコード上でも実際に守られていることが確認されています。

唯一、事実と異なる重大な記載があったのがCIに関する部分です。リスティングでは、CIの値はマシンの外に送信されることはなく、単にどのCIプラットフォームが存在するかを示す指標に過ぎないと説明されていました。

しかし実際には、拡張機能はマーカー名だけでなくCI環境の値そのものも送信しており、その中にはペイロード中で最も機密性の高い情報であるプライベートリポジトリの識別子も含まれていました。

さらにリスティングには、次の3つの挙動についても記載がありませんでした。リポジトリの設定ファイルが拡張機能を呼び込んだかどうかを報告すること、エディタのテレメトリ設定を読み取り送信すること、そしてハードコードされたエンドポイントが失敗した場合に代替エンドポイントを動的に探すためDNSのTXTレコード(_beacon.<domain>)に問い合わせを行うことです。

重要な点として、これらの拡張機能はそれ以外の動作を一切行いません。ステータスバー上のチェックマークと、些細な「active」というメッセージコマンドを除けば、その唯一の機能はビーコン送信だけです。

「テレメトリ」という言葉が、あたかも正規の機能であるかのように使われることで、そのドキュメント自体が、本来なら不審に見えるはずの挙動への「同意」を取り付ける仕組みとして機能していたのです。

軽量な多数派は、Amigaのデバッグツール、LEGO EV3向けMicroPython、MinecraftのJSONスキーマ、Vimのチートシート、WordPress、Perl、CoffeeLint、Hugoなど、ほぼあらゆる技術スタックとスキルレベルにまたがっており、標的を絞った攻撃というより拡張機能名を大量に収集した結果であることをうかがわせます。

19個の偵察ペイロードは、Git・CIの識別情報が実利的な価値を持つ組織環境に偏って狙いを定めていました。具体的には、IOTA、Move、Obyte向けのブロックチェーンツール、Salesforce Marketing Cloud・ApexSQL・ConfigCatといったエンタープライズ向けプラットフォーム、航空宇宙・自動車向けのバスプロトコル(UAVCAN DSDL)、そして米連邦政府機関の名前空間が含まれます。

偽Open VSX拡張機能

全体を通じて乗っ取られた名前空間には、AMD、Artsy、LEGO Education、Hyperledger、Azure、IOTA、Salesforce OSS、政府機関(.gov)の一つである「ssagov」、そしてマーケットプレイス自体になりすましたmarketplace.visualstudioが含まれます。

19個のサンプルだけで攻撃全体の戦略を断定するには不十分ですが、より豊富な情報を狙うペイロードは、プライベートリポジトリやCIプロジェクトのマッピングが運用上最大の価値を持つ環境に集中していました。

77個の拡張機能はすべてmangorbit[.]comと通信していました。このドメインは、公開の波が始まる11日前の2026年7月15日に、登録者情報を秘匿するレジストラを通じて登録されていました。

ドメインの最上位(apex)は汎用的なランディングページを表示する一方、pulse.mangorbit[.]com、pulse2.mangorbit[.]com、api.mangorbit[.]com、そしてランダム化されたcb.mangorbit[.]comのサブドメインといった収集用サブドメインは「ok」と応答しており、単なるパーキングされたDNSエントリではなく、入力を受け付ける稼働中のサーバーであることが確認されています。

偵察型ペイロードのリトライ処理は、明らかに通信妨害を見越して設計されています。リクエストは有効化からおよそ15分後、50分後、3時間半後に送信され、その後は7~8時間おきに送信されます。エディタを再起動するたびに再開し、7日間経過して初めて停止します。

オフライン状態、ファイアウォールで遮断された状態、プロキシでブロックされた状態にあるマシンであっても、1週間にわたってリトライが繰り返されます。エンドポイントのリストは冗長化されており、エラーコードを含むあらゆるHTTPレスポンスが「成功」とみなされます。これは、ペイロードの内容そのものよりも「到達すること」自体を重視した設計です。

すべてのエンドポイントへの接続が失敗した場合、拡張機能は_beacon TXTレコードに問い合わせて新しいベースURLを取得します。これにより、攻撃者はテイクダウン後でも拡張機能を更新することなく収集用インフラを移転でき、大半のアウトバウンド通信フィルタも回避できてしまいます。

特に示唆的なのが、あるフィールドの存在です。それは、開いているワークスペースのdevcontainer.jsonや.vscode/extensions.jsonが、その拡張機能のIDを明示的に参照していたかどうかを示すフラグです。

この「設定ファイル経由でのインストールか、人間による能動的な選択か」という区別こそ、自分たちのパッケージがどのようにして組織のフリート全体に取り込まれているかを攻撃者側が把握するために必要な情報にほかなりません。

今回のキャンペーンは、MicrosoftのVS CodeマーケットプレイスとEclipseが運営するOpen VSXレジストリとの間に存在する信頼性のギャップを悪用する、より広範な攻撃パターンの一環に位置付けられます。

Socketが6月に公表した「GlassWASM」レポートでは、正規のVS Codeマーケットプレイス拡張機能を模倣した、トロイの木馬化されたOpen VSXのクローンが報告されました。これらは発行者ID、名前、バージョン、説明文、上流のGitHubリンクをそのまま複製しつつ、ChaCha20で難読化されたWebAssemblyペイロードを追加していました。

7月には、研究者らがOpen VSXにおける名前空間乗っ取りの欠陥を公に指摘しました。この欠陥により、攻撃者はOpen VSX上で未登録のMicrosoftマーケットプレイス発行者名前空間を誰でも取得し、任意のコードをその名前で公開できてしまいます。しかも、多くのAI搭載IDEでは自動更新がデフォルトで有効になっています。

Manifoldが以前分析した、Microsoft自身のマーケットプレイス上に存在した偽の「Markdown All in One」拡張機能でも、同じ手口が別の側面から確認されています。借用された拡張機能のメタデータ、ハードコードされたIPアドレスへのユーザー名とホスト名の平文でのビーコン送信、そして密かなリモートファイル取得です。

Anthropicが7月30日に公表した内容と、OpenAIのHugging Faceに関するインシデントは、自動化に伴うリスクを浮き彫りにしています。Anthropicの報告によれば、あるモデルが評価作業中に、架空の設定文書にのみ存在するはずの名称で悪意あるPyPIパッケージを公開してしまい、それにもかかわらず1時間以内に15の実在するシステムがこれをダウンロードし実行していたということです。

侵害指標(IOC)

注: IPアドレスおよびドメイン名は、誤った名前解決やハイパーリンク化を防ぐため、意図的に無害化表記(例: [.])としています。実際の形式に戻す(re-fang)場合は、MISP、VirusTotal、SIEMなど管理されたスレットインテリジェンス基盤内でのみ行ってください。

2026年版Agentic SOC購入者向けガイドをおすすめする理由 8つの主要プラットフォームを徹底比較 – 2026年版購入者向けガイドをダウンロード