はじめに：AIエージェントツールを狙うSSRFの危険性

日本のフロントエンドエンジニアの皆さん、こんにちは。今回は、WebアプリケーションやAIエージェントのメディア取得ツールで利用される`auth-fetch-mcp`というパッケージに存在する、深刻度の高いSSRF (Server-Side Request Forgery) 脆弱性（CVE-2026-49857）について解説します。直接フロントエンドコードを書いている方にとっても、開発環境やデプロイ環境、あるいは利用しているツールチェーンにおいて、このような脆弱性がどのように影響しうるかを理解することは非常に重要です。

脆弱性の概要：IPv4-mapped IPv6によるSSRF保護の迂回

この脆弱性（GHSA-pvrj-8cg3-j5f8）は、`auth-fetch-mcp`パッケージのバージョン3.0.1において発見されました。このツールは、Webページからのメディア取得やURLリクエストを行う際に、内部ネットワークやループバックアドレスへのアクセスを防ぐためのSSRF保護メカニズム`assertSafeUrl()`を持っています。

しかし、特定のIPv4-mapped IPv6ループバックアドレス形式（例: `http://[::ffff:127.0.0.1]:PORT/`）が、Node.jsのWHATWG URLパーサーによる正規化を経て、この保護機能をすり抜けてしまうことが判明しました。これにより、外部からの入力値に基づいてリクエストを生成する機能を持つ場合、攻撃者は本来アクセスできないはずの内部サービスにHTTPリクエストを送信し、その応答を取得できる可能性があります。深刻度はHigh（CVSS v3.1 Base Score: 7.4）と評価されています。

技術的詳細：URL正規化と`net.isIPv4()`の落とし穴

問題の核心は、`src/security.ts`内の`isPrivateV6()`関数にあります。この関数は、IPv6アドレスがプライベートまたはループバックアドレスであるかをチェックするものです。`::ffff:`で始まるIPv4-mapped IPv6アドレスの場合、その後の部分をIPv4アドレスとして扱い、`net.isIPv4()`でチェックし、`isPrivateV4()`関数に処理を委譲します。

しかし、Node.jsのWHATWG URLパーサーは、`::ffff:127.0.0.1`のようなアドレスを内部的に`::ffff:7f00:1`のように16進数形式に正規化します。この正規化された`7f00:1`という文字列は、もはやドット区切りのIPv4アドレスではないため、`net.isIPv4('7f00:1')`は`false`を返してしまいます。結果として、`isPrivateV6()`関数はこれを安全なアドレスと誤認し、保護メカニズムを迂回してしまいます。

コードスニペットの例:

```ts if (lower.startsWith("::ffff:")) { const v4 = lower.slice(7); // "7f00:1" after Node normalization if (net.isIPv4(v4)) return isPrivateV4(v4); // false → falls through } return false; // loopback escapes the guard ```

`auth-fetch-mcp`には主に二つの機能がこの脆弱性の影響を受けます。

どちらのケースでも、このSSRF保護の迂回が成功すると、攻撃者は内部リソースへリクエストを送り、その内容を窃取・利用することが可能になります。

脆弱性の影響：内部情報の漏洩リスク

このSSRF脆弱性が悪用されると、攻撃者は以下のような内部サービスにアクセスできる可能性があります。

特に、AIエージェントのプロンプトインジェクションのようなシナリオでは、ユーザーが提示したWebページに含まれる悪意のあるペイロードによって、このツールが意図せず内部リソースへアクセスさせられるリスクがあります。攻撃者はこれにより、内部サービスから機密情報を読み取り、その結果をエージェント経由で取得することが可能になります。

対策と推奨事項

現時点（2026年4月時点）では、`auth-fetch-mcp`のパッチ済みバージョンは公開されていません。しかし、提供されている修正案を参考に、同様の機能を持つアプリケーション開発者は対応を検討する必要があります。

根本的な対策としては、Node.jsによって16進数に正規化されたIPv4-mapped IPv6アドレスを、元のドット区切りIPv4形式にデコードしてから`isPrivateV4()`関数でチェックする方法が提案されています。

```diff if (lower.startsWith("::ffff:")) { const v4 = lower.slice(7); if (net.isIPv4(v4)) return isPrivateV4(v4); + const m = /^([0-9a-f]{1,4}):([0-9a-f]{1,4})$/.exec(v4); + if (m) { + const hi = parseInt(m[1], 16); + const lo = parseInt(m[2], 16); + const mapped = `${hi >> 8}.${hi & 255}.${lo >> 8}.${lo & 255}`; + return isPrivateV4(mapped); + } } ```

さらに、`BrowserContext`のルートガードを追加し、リダイレクト先を含むすべてのナビゲーションURLが`assertSafeUrl()`によって再バリデートされるようにすることも推奨されています。これにより、ブラウザが内部的にリダイレクトを行った場合にもSSRF保護が機能するようになります。

まとめ

今回の`auth-fetch-mcp`のSSRF脆弱性は、URLの解析とバリデーションの複雑さ、特にIPv4とIPv6の相互運用性において潜む危険性を示しています。

フロントエンド開発に携わる皆さんも、たとえ直接バックエンドのSSRF対策を実装する立場になくても、以下の点に留意してください。

本脆弱性情報が、皆さんの開発プロセスにおけるセキュリティ意識向上の一助となれば幸いです。