Open VSX Scanner の脆弱性 CVE-N/A が FIX:曖昧なエラー処理による検証バイパス

Open VSX Scanner Vulnerability Lets Malicious Extensions Go Live

2026/03/28 gbhackers — Open VSX が公表したのは、新たに導入された公開前スキャン・パイプラインに存在し、悪意のエクステンションの公開を可能にする深刻な脆弱性の修正である。それにより、Cursor や Windsurf などの VS Code フォークで利用される、エクステンション・マーケットプレイス Open VSX において、セキュリティ・チェックの回避が発生する可能性が生じていた。この “Open Sesame” と呼ばれる問題は、スキャン・ワークフローにおける “fail-open” 条件に起因していた。

このプラットフォームに導入されたパイプラインは、マルウェア検知/シークレットスキャン/バイナリ解析を通じてセキュリティを強化するものである。しかし、そのロジック上の欠陥により、特定の条件下でスキャナーが完全に回避される状態となっていた。この脆弱性は、2026年2月8日に責任あるかたちで開示され、2月11日に修正された。

スキャン・パイプラインの仕組み

Open VSX のスキャン・システムは、公開前のエクステンションを検証するための、多段階プロセスとして設計されている。

The Scanning Pipeline (Source : Koi).
The Scanning Pipeline (Source : Koi).

開発者によりアップロードされたエクステンションは、非アクティブ状態で保存される。その直後に実行される同期型のスキャンにより、明らかな悪意が拒否される。

このチェックを通過したエクステンションに対して、非同期の複数スキャン・ジョブがスケジュールされ、マルウェア検知やシークレット検出などの詳細分析が実行される。

すべてのスキャナーが成功を返した場合のみ、対象となるエクステンションは公開される。いずれかのスキャナーが問題を検出した場合には、隔離措置が取られ、手動レビューへ回される。また、失敗や停止したスキャンを再試行するための、リカバリ・サービスも用意されている。

問題の原因

この問題の根本的な原因は、スキャナー実行結果の扱いにある。

バックエンドのあるメソッドは、スキャナーの実行結果を Boolean 値で返していたが、この値は 2 種類の状態を同時に表現していた。

  • スキャナーが設定されていない (正常な状態)
  • スキャナー・ジョブの実行に失敗した (異常な状態)

システムにより、これらの状態は区別されずに扱われていた。たとえば、高負荷時にデータベース接続が枯渇し、ジョブ・スケジューリングが失敗した場合に、このメソッドは “false” を返す。

The Open Sesame Bug(Source : Koi).
The Open Sesame Bug(Source : Koi).

呼び出し側サービスは、この “false” を “スキャナー未設定” と誤解し、エクステンションを自動的に合格扱いとしていた。その結果として、実際にはスキャンが実行されていないにもかかわらず、エクステンションを検証済みとして公開する状態となっていた。

影響と悪用方法

この攻撃は、特別な権限を必要とせず、通常の公開者アカウントで実行できる。

最初に攻撃者は、複数の悪意のエクステンションをアップロードしながら、publish API に大量リクエストを送信することで、バックエンド・リソースを圧迫する。

それにより、スキャン・ジョブ・スケジューリングに使用される共有データベース接続プールが枯渇すると、スキャンは実行されずにスキップされる。テストにおいても、この “fail-open” 状態が、高負荷下で再現可能であることが確認されている。

The Fix (Source : Koi).
The Fix (Source : Koi).

さらに、publish API のエンドポイントにレート制限が欠落していたことで、繰り返して攻撃を実行することが可能であった。

スキャンを回避したエクステンションは、UI 上で “PASSED” と表示され、正規のものと区別がつかない状態で公開されてしまう。

修正内容

すでに Open VSX チームは、曖昧な Boolean ロジックを削除することで、失敗の状態を明確に区別するための修正を完了している。それにより、スキャナー・ジョブの失敗が、自動承認につながることはなくなった。

この脆弱性が影響を及ぼしていた期間に、エクステンションをインストール/アップデートしたユーザーには、内容を確認することが推奨されている。

このインシデントが示すのは、”fail-open” 設計がセキュリティ機構全体を無効化し得ることだ。エラー状態と正常状態が区別されない状況において、高負荷時の防御機構が静かに破綻する可能性がある。