Tencent BrowserSkillは拡張機能IDが本物らしく見えることしか確認しておらず、どの拡張機能でもエージェントに偽造ページを渡すことが可能だった

に2026年9月17日、GitHub ユーザーでcarfeii として投稿した人物が、Tencent のオープンソースプロジェクト BrowserSkill に対して issue #273 を開き、限定的な主張を行った。すなわち、ブラウザ拡張機能を AI エージェントに接続するローカルデーモンは、どの拡張機能が接続したかを確認しておらず、接続が拡張機能らしく見えるかどうかだけを確認していた、というものだ。3日後の9月20日、VulnCheck はこの発見を CVE-2026-94111 として公開し、デーモンは「a-p の範囲の32文字からなる任意の chrome-extension オリジンを受け入れる」と説明し、これをCWE-346（オリジン検証エラー）に分類し、George Chen の功績として挙げている。アドバイザリはこれをCVSS 4.0 6.9、中程度と評価し、完全性への影響を高、機密性と可用性を低としている。記録上、この欠陥が悪用されたことを示すものはない。アーカイブには悪用の記録がなく、エントリの信頼度は A と評価されており、real_harm は false である。これはAI インシデントアーカイブ内の1件の記録であり、各エントリには独自の情報源、重大度、信頼度評価、異議フラグが付されている。

同一性を一度も確認しなかった形式チェック

記録の中心にあるコードは小さい。crates/bsk-cli/src/daemon/ws.rs では、関数 origin_allowed() が WebSocket ハンドシェイクの Origin ヘッダーを受け取り、文字列 chrome-extension:// を取り除き、残った部分がちょうど 32 文字で、すべての文字が a から p の間にある場合に true を返す。それがテストのすべてだ。これは HTTP アップグレードコールバック内で一度だけ実行され、失敗すると 403 を返し、そのメッセージは「Origin not in chrome-extension allow-list」と表示される — ただし公開された時点では、属すべきリストは存在しなかった。

このパターンは恣意的なものではありません。ChromeのManifest V3拡張機能IDは、まさにその16文字だけから構成される32文字です。そのため、このチェックは実際の拡張機能オリジンの形状を正しく認識します。欠陥は、すべての拡張機能がその形状を持っていることです。このチェックは、呼び出し元がブラウザ拡張機能のように見えるかどうかを尋ねるだけで、決してそれがこのプロジェクトのブラウザ拡張機能であるかどうかは尋ねません。そして、比較すべきだった識別子はすでに公開されていました。プロジェクトのREADMEにはChrome Web Storeのリスティングへのリンクがあり、そのIDはhhcmgoofomhgciiibhipgmgkgnoenaoi、その横にはEdge Add-onsのIDもあります。どちらの文字列もゲートのどこにも現れません。

デーモンは固定のローカルポート、52800で待ち受けます。このポートは CLI で DEFAULT_WS_PORT として宣言され、ローカル接続パスでも一切変更せずに使用されます。ポートは文書化された定数であり、ユーザーのブラウザプロファイルで既に動作しているものから到達可能です。場所が、アドバイザリのベクトルが AV:L で始まる理由です。攻撃者にはマシン上での足場が必要であり、PR:L は低権限の足場で十分であることを記録しています。同じプロファイルにインストールされた拡張機能は、まさにその種の足場です。

その席にはどれだけの価値があり、そのうちどれだけが確立されているのか

アドバイザリの影響に関する文は広範です。悪意のある拡張機能をブラウザクライアントとして登録した攻撃者は、「AIエージェントに返されるページコンテンツ、DOM、スクリーンショットを傍受して操作できる」とされています。これはCVE、GitHubアドバイザリ記録GHSA-x6f2-qp26-2xrh、およびアーカイブのすべてが記載している説明であり、CVSSの完全性評価が高であることを説明しています。また、これはCVEを割り当てた当事者によって書かれた要約であり、実証された攻撃の報告ではありません。

同じ週、問題のスレッドそのものに、より注意深い説明が届いた。9月20日、bb6894として投稿したコメンテーターは、main のコミット fa953dc6（9月18日）に対してコードを再確認し、ハンドシェイク後に外部クライアントが実際に到達できる範囲を追跡したと報告した。コメントによると、受信ツールメソッドのほとんどは WebSocket ピアに UnknownMethod を返し、監査リクエストはクライアント自身のレコードに限定され、window_closed、user_interrupt、update_interaction といったクロスセッション操作は、別のブラウザが所有するセッションに対してガードされている。そのフィルターを通過するものはより狭く、エージェントにとっては、おそらく傍受よりも悪い。外部拡張は攻撃者が選択した instance_id の下でブラウザスロットを取得でき、それが登録されている唯一のブラウザである場合——コールドスタートまたはデーモンの再起動時——には、エージェントのツールリクエストを受信し、捏造されたページコンテンツ、DOM、スクリーンショットでそれらに応答する。コメンテーターはこれを「エージェントに対する結果の偽造」および「エージェントの知覚へのチャネル」と呼んでいる。第2の効果はサービス拒否である。正規のブラウザもオンラインで、セレクターがない場合、セッション起動は MultipleBrowsersOnline で失敗することがある。

どちらの説明も公の場で実証されてはいない。記者は概念実証を「請求に応じて提供可能」と表現したが、誰もそれを公開しておらず、悪用も記録されていない。したがって、二つの説明の違いは同じソースファイルの二つの解釈の違いであり、理論と動作するエクスプロイトの違いではない — そしてその記事はどちらかを選ぶのではなく、両方を報じている。無条件に言えるのは、ハンドシェイク後に二度目の身元確認は一度も行われなかったということだ。つまり、ゲートが受け入れたものは何であれ、接続が存続する間は受け入れられたままだった。

コードはすでに知っていた

この記録の中で最も居心地の悪い文書は、勧告ではない。それは、その関数のすぐ上に置かれ、勧告が指し示すタグ付きリリースにそのまま出荷されているコメントだ。このコメントはそのギャップを TODO(M10/M12) と印付け、構築しようとしている許可リスト——DaemonConfig::allowed_extension_ids の集合を設定ファイルやペアリングフローから埋めるもの——を名指しし、さらに延期した理由をこう記している。「現時点ではペアリングがポップアップ経由で行われるため、多層防御のギャップとしては容認できるが、同一マシン上にサイドロードされた拡張機能は現在このゲートを通過してしまう」。

素直に読めば、メンテナはゲートがどの呼び出し元を通したかを把握し、把握していると書き残し、そのまま出荷していた。それはアドバイザリが述べている以上に露出を大きくするものではない。驚きを減らすだけであり、問いを「なぜこれがレビューを通ったのか」から「何があれば先送りされた修正は緊急になっていたのか」へと移す。緩和要因となる設計上の前提は実在し、文書化もされている。ローカル接続はオプトインだ。README によれば、ユーザーは拡張機能をインストールし、そのポップアップを開いてローカル接続を有効にする必要があり、ここにある何かに到達できるようにするにはデーモンが実行中でなければならない。拡張機能がインストールされていてもトグルがオフのプロファイル、または bsk デーモンが実行されていないプロファイルは、待ち受け対象ではない。

5週間後、門は変わっていない

このレコードの影響範囲は「0.3.0まで」であり、それがCNAの割り当てた範囲です。リポジトリにおける話はこれで終わりではありません。CLIの0.3.0リリースには9月17日02:22 UTCにタグが付けられ、イシューは同じ日の15:14 UTC、およそ13時間後に起票されました。それ以降さらに3つのCLIリリースが公開されています — 0.3.1は9月23日、0.3.2は9月30日、そして0.3.3は10月15日 — そしてそれら各タグの origin_allowed() 関数は上記と同じチェックであり、その上には依然としてTODOが残っています。メインブランチも10月27日時点でそれを含んでいます。

修正は存在しますが、提案の形だけです。9月28日に、dangzitouとして投稿したコントリビューターが、個人フォークから「fix(daemon): pin WS origin gate to BrowserSkill's own extension ids」というタイトルでプルリクエスト #363 を開きました。これは形状テストを2つのストアIDとの比較に置き換え、サイドロード版および開発ビルド向けの明示的な admission path として BSK_ALLOWED_EXTENSION_IDS を追加します。これらのビルドでは、アンパックされたIDがインストールパスから導出されます。プルリクエスト本文は、偽造経路と MultipleBrowsersOnline のサービス拒否の両方をクローズすると主張しています。10月27日時点でもまだオープンで未マージであり、Issueもベンダーからの声明が付かないままオープンのままです。

実務上の帰結として、修正を含むアップグレード先のバージョンは存在しない。「0.3.0 より後のバージョンにアップグレードせよ」と助言する人は、まだ存在しない段階を勧めている。後続のリリースは後続であって、修正済みではない。記録上の範囲は、CNA が9月20日に評価した範囲として読むべきであり、0.3.1 以降が問題ないという表明として読むべきではない。

何が確立されており、何が確立されていないのか

• 確認済み: タグ cli-v0.3.0 でリリースされたソースには、任意の32文字の a–p の chrome-extension オリジンを許可するオリジンゲートが含まれています。報告者、CNA、およびファイル自体の見解は一致しており、コードは公開されています。

• 確定済み:ゲートはWebSocketアップグレード時に一度だけ実行され、その後に本人確認は行われず、固定のローカルポート52800上で動作していた。

• 確定:プロジェクト自身のソースコメントが、サイドロードされた拡張機能は通過すると認め、許可リストを先送りしていた。

• 確定:CVSS 4.0 の 6.9 と CVSS 3.1 の 6.6 はどちらも VulnCheck によるスコアで、NVD によってセカンダリとして記録されています。このエントリに対する NVD 自身のステータスは Deferred であり、これは NVD が独自に作成した分析を追加することなく、CNA のデータを公開したことを意味します。

• 確定:CISAのSSVC評価（9月21日付）では、悪用は「なし」、自動化可能は「いいえ」、技術的影響は「部分的」と記録されている。FIRSTのEPSSでは、10月26日時点で、今後30日以内に悪用される確率は0.00135（2.9パーセンタイル）とされている。

• 確認されていない：実際の使用例は一切なし。悪用も、公開された概念実証も、影響を受けたインストール数の集計もない。プロジェクトのリポジトリ指標はインストール数の集計ではなく、誰もそのような集計を公開していない。

• 未確立：どの影響評価が妥当か。CNAの「傍受と操作」とスレッドの「結果の偽造とサービス拒否」は異なる上限を述べており、どちらもコードを読む以外では実証されていない。

• 未確認: その欠陥が0.3.0で止まること。バージョン文字列はCNAの評価であり、その後の3つのリリースでコードは変わっておらず、それを否定するベンダーの声明もない。

• 矛盾があり未解決: アグリゲーターのDevGuardは、このCVEについて「悪用の試みが検出された」というシグナルを表示しているが、情報源、IOC、テレメトリプロバイダーを明示していない。これは、悪用なしというCISAの記録済みの評価に反し、公開報告が存在しないことにも反する。アーカイブにも悪用の記録はない。このアグリゲーターのフラグは、第二のデータポイントとしてではなく、裏付けのないものとして扱うべきである。

なぜトランスポートが興味深いターゲットなのか

ほとんどのプロンプトインジェクション対策の指針は、同じ境界線を引いている。取得したページテキストは信頼できないものとして扱い、それを届ける仕組みは信頼できるものとして扱う。ウェブページを読むツールは、そのページを読んでいると想定される。問題は、ページに何が書かれているかだ。この記録はそれを逆転させる。エージェントがページ内容、DOM、スクリーンショットとして受け取るのは、ローカルソケットのもう一端にいるクライアントが送ると決めたものにすぎず、そのソケット上の唯一の関門は、どの候補でも正しく答えられる質問をしていた。クライアントが外部のものであれば、「ページに何が書かれているかを検証する」には、照らし合わせる対象が何も残らない。

深刻度がより高くではなく、この水準に落ち着くのも同じ理由である。攻撃はローカルであり、プロファイルにすでにインストールされた拡張機能か他のローカルコードを前提とし、デーモンがローカル接続を有効にして稼働していることを必要とする。こうした条件は、このツールの想定利用者にはありふれたもので、それ以外の人々には異例である。アーカイブの中程度の深刻度と、被害がなかったと記録されていることは、その形と整合する。すなわち、設計がまさに監視するはずだった境界で信頼が実際に広がったものの、誰かがそれをすり抜けた証拠はない、ということだ。

以下に述べる狭い実務的助言は、誰かが公開した緩和策ではなく、コードがそのまま残している境界にすぎない。接続の受け入れは公開ポート上でのハンドシェイク時に一度だけ決定されるため、到達可能な範囲は、デーモンを実行するプロファイルにどの拡張機能がインストールされているか、そしてその時点でそのデーモンと拡張機能のローカル接続が有効になっているかどうかによって決まる。拡張機能IDの許可リストが出荷されるまでは、この2つの事実が制御のすべてである。

CVE-2026-94111は、二つのうちどちらかの形で時を経ることになる。プルリクエストがマージされ、記録が、対応に時間がかかった既知のギャップについての短い項目になるか、それとも同じ形状チェックが1年後もツリーに残り、その項目が、それが属するクラスの初期例として引用されるかだ。それは、敵対的な指示を載せたページではなく、エージェントがどのページを読んでいるかを決めるパイプである。