はじめに：なぜフロントエンドエンジニアもSSRFを知るべきか

SSRF (Server-Side Request Forgery) は、サーバーが意図しないリクエストを送信させられるバックエンド側の脆弱性として知られています。しかし、その攻撃経路や影響範囲によっては、私たちフロントエンド開発者も間接的に、あるいは直接的に関わる可能性があります。

今回解説する`open-websearch`の脆弱性 (CVE-2026-42260, GHSA-v228-72c7-fx8j) は、内部ネットワークへの不正アクセスを許す深刻度「High」のSSRFです。特に、ブラウザからの攻撃シナリオも含まれるため、見過ごせません。この脆弱性の技術的な詳細と、私たちに何ができるかを見ていきましょう。

脆弱性の概要：`open-websearch`におけるSSRF

`open-websearch`の`fetchWebContent`ツールが使用するURL検証関数`isPrivateOrLocalHostname`に不備があり、攻撃者が細工したURLによって、本来アクセスをブロックすべき内部ネットワークリソースへ接続できてしまいます。これにより、認証なしでサーバー内部の機密情報にアクセスされる危険性があります。

このツールはリクエストのレスポンスボディをそのまま呼び出し元に返すため、攻撃者は内部ネットワークからの応答内容（APIキー、データベースの資格情報、環境設定など）を直接取得できてしまう致命的な問題です。

技術的な詳細：2つの致命的な欠陥

`isPrivateOrLocalHostname`関数には、主に以下の2つの欠陥が存在します。

角括弧で囲まれたIPv6アドレス（例: `[::1]`や`[::ffff:127.0.0.1]`）が、IPアドレスとして正しくパースされません。これにより、ローカルループバックアドレス（サーバー自身）や内部ネットワーク上のIPv6アドレスへのアクセスが許可されてしまいます。

攻撃者はこの欠陥を悪用し、`http://[::1]/admin`のようなURLを通じて、サーバー自身が持つ内部サービスにアクセスし、機密情報を窃取したり、設定を変更したりする可能性があります。

URLのホスト名がプライベートIPアドレスを指している場合でも、検証関数はDNS解決を行いません。攻撃者は自身が管理するドメイン（例: `evil.com`）のDNSレコードを、ターゲットサーバーの内部ネットワークIPアドレス（例: `192.168.1.100`）に向けることができます。

検証関数は`evil.com`を「安全なホスト名」と判断してしまい、結果として`http://evil.com/internal-api`へのリクエストが、実際には`192.168.1.100`へルーティングされ、内部リソースにアクセスされてしまうのです。これはDNSリバインディング攻撃の準備段階にもなり得ます。

どのような状況で影響を受けるか？フロントエンド視点での懸念

`open-websearch`の`config.enableHttpServer`が`true`（デフォルトで`0.0.0.0`で公開）かつCORSが`*`に設定され、`/mcp`エンドポイントに認証がない場合、外部から直接攻撃が可能です。

特にフロントエンドエンジニアが関わるシナリオとして、攻撃者が作成した悪意のあるウェブページをユーザーが閲覧すると、そのページからブラウザのJavaScript経由で、脆弱な`open-websearch`サーバーへSSRFリクエストが送信される可能性があります。CORS `*`の設定が悪用されるため、攻撃者は内部ネットワークからのレスポンスを直接取得できてしまいます。

HTTPサーバーが有効でなくても、LLMエージェントなどが内部で`open-websearch`ツールを呼び出す場合、プロンプトインジェクションなどを通じてSSRF攻撃を仕掛けられ、内部リソースへのアクセスを試みられる可能性もあります。

推奨される対応策

この脆弱性への対応として、以下の3点が推奨されます。

IPアドレスのチェック前に、ホスト名を正規化し、`[::1]`のようなIPv6リテラルを正しくパースするロジックを導入します。さらに重要なのは、URLのホスト名について、`node:dns/promises`モジュールの`lookup`関数などを使用してDNS解決を実行し、**解決されたすべてのIPアドレスがプライベートなCIDR範囲（例: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, `::1/128`など）に属さないことを確認**することです。`ip-address`のようなライブラリがこのIPアドレス範囲チェックに役立ちます。

DNSリバインディング攻撃など、時間差でIPアドレスが変更されるケースを防ぐため、実際にソケット接続が確立された後に、`socket.remoteAddress`（実際に接続されたIPアドレス）を再度検証するカスタム`undici` `Agent`を実装することを検討してください。

`/mcp`および`/sse`エンドポイントに対して、**必ず認証（例: ベアラートークン）を必須化**してください。環境変数などで設定できるようにします。また、デフォルトではサーバーのバインディングアドレスを`127.0.0.1`に制限し、外部からのアクセスをブロックすべきです。**CORS `*`と認証なしの組み合わせは、ウェブアプリケーションにおいて極めて危険な設定であり、絶対に避けるべきです。**

まとめ

`open-websearch`のSSRF脆弱性 (CVE-2026-42260) は、IPv6処理の不備とDNS解決の欠如が原因で、深刻な内部ネットワークへの不正アクセスを可能にします。

フロントエンドエンジニアも、ブラウザ経由の攻撃や、開発環境におけるバックエンドツールの安全な利用という観点から、この脆弱性を理解し、ご自身のプロジェクトでバックエンドが`open-websearch`を利用している場合は、速やかに上記の対策が実施されているか、あるいは公式のアップデートが適用されているかを確認することが重要です。常に最新のセキュリティ情報をキャッチアップし、安全な開発を心がけましょう。