Modern Frontend CVEs

対象CVE: CVE-2026-16221

フロントエンド開発者も要注意!fast-uriのホスト混同脆弱性(CVE-2026-16221)とNode.jsへの影響

fast-uriライブラリに、Node.jsのネイティブURLパーサーとの挙動の不一致を利用して、意図しないホストへのリクエストを誘導する高深刻度の脆弱性(CVE-2026-16221)が発見されました。この脆弱性は、SSRFなどの深刻な攻撃につながる可能性があり、速やかな対応が求められます。

1. この脆弱性は何?fast-uriとバックスラッシュの罠

fast-uriは、URI(Uniform Resource Identifier)を解析するためのJavaScriptライブラリです。今回の脆弱性(GHSA-v2hh-gcrm-f6hx / CVE-2026-16221)は、fast-uriのバージョンv4.1.0以前において、リテラルのバックスラッシュ(U+005C, `\`)をURIの権限(Authority)の区切り文字として正しく扱わないことに起因します。

通常、URIの権限部分は`user:password@host:port`のような形式で、ホスト名はスラッシュ(`/`)で区切られたり、`@`でユーザー情報と区切られたりします。しかし、fast-uriはこのバックスラッシュを区切り文字と見なさなかったため、後述するNode.jsの挙動との間で重大な差異が生じます。

2. なぜ問題になるのか?Node.jsのURLパーサーとの不一致

この脆弱性の根源は、fast-uriのパース結果と、Node.jsのネイティブWHATWG `URL`パーサー(`fetch()`, `undici`, `http`/`https`クライアントが内部で使用)のパース結果が異なる点にあります。

Node.jsのWHATWG `URL`パーサーは、`http`, `https`, `ws`, `wss`, `ftp`, `file`といった「特別なスキーム」のURLにおいて、バックスラッシュ(`\`)をフォワードスラッシュ(`/`)に正規化します。

例えば、`http://example.com\`というURLを与えると、Node.jsはこれを`http://example.com/`として扱います。この正規化処理が、fast-uriがバックスラッシュを無視する挙動と組み合わさることで、ホストの解釈に決定的な不一致が生じるのです。

3. 具体的な攻撃シナリオ:SSRFへの道

最も分かりやすいのは、以下の例でしょう。

**攻撃者が用意したURL:** `http://evil.com\@allowed.com`

1. **`fast-uri`での解釈:** fast-uriはバックスラッシュを権限区切り文字と見なさないため、`@`以降の`allowed.com`をホストとして解釈し、`evil.com\`をユーザー情報の一部と判断します。 結果:`allowed.com`がホワイトリストなどに含まれていれば、「安全なURL」として処理を続行します。

2. **Node.jsのWHATWG `URL`パーサー(`fetch()`など)での解釈:** Node.jsのパーサーは、まず`\`を`/`に正規化します。 URLは`http://evil.com/@allowed.com`と解釈されます。 このURLの場合、`@`より前の`evil.com`がホストとして扱われ、`/@allowed.com`はパスの一部となります。 結果: 実際のHTTPリクエストは**`evil.com`**に対して行われます。

このように、fast-uriで「安全」と判断したURLが、Node.jsの内部処理では全く別のホスト(攻撃者の意図するホスト)へアクセスしてしまうという「ホストの混乱 (Host Confusion)」が発生します。

この攻撃は、例えば以下のような深刻な問題を引き起こす可能性があります。

* **SSRF (Server-Side Request Forgery) 攻撃:** 許可されたドメインの背後に隠れて、内部ネットワークのリソース(クラウドメタデータエンドポイント、社内API、ローカルホストなど)へ不正にアクセスされる可能性があります。 * **オープンリダイレクトの悪用:** リダイレクト先を検証するロジックが迂回され、悪意のあるサイトへユーザーを誘導する可能性があります。 * **プロキシルーティングの回避:** 信頼されたドメインへのアクセスとして、本来アクセスを制限すべき外部サービスへ接続される可能性があります。

もし、あなたが開発しているNode.jsアプリケーションが、fast-uriでURLの安全性をチェック(例えば、許可リストに基づくドメイン検証やSSRF対策)し、その後`fetch()`や`undici`、`http`/`https`モジュールなどを使ってリクエストを送信している場合、この脆弱性の影響を強く受けます。

4. 対策:今すぐアップグレードを

この脆弱性に対する回避策は存在しません。唯一の対策は、fast-uriライブラリを脆弱性が修正されたバージョンに**アップグレードすること**です。

* `fast-uri` v4.1.1 * `fast-uri` v3.1.4 * `fast-uri` v2.4.3

あなたのプロジェクトがfast-uriを直接的または間接的に依存している場合は、`package.json`を確認し、速やかにバージョンを更新してください。

5. まとめ:URLパースの奥深さと注意点

今回のfast-uriの脆弱性は、一見些細に見えるURIパースの挙動の違いが、いかに深刻なセキュリティホールに繋がりうるかを示す好例です。特に、複数のライブラリやシステム間でURLの解釈が異なる場合、それが攻撃者に悪用されるリスクがあることを再認識させてくれます。

フロントエンドエンジニアの皆さんも、Node.jsベースのバックエンドやビルドツール、BFF(Backend For Frontend)などを扱う際には、URLの取り扱いについて常に注意を払い、使用しているライブラリのセキュリティ情報を定期的にチェックすることが重要です。常に最新のセキュリティパッチが適用されたバージョンを使用し、安全なアプリケーション開発を心がけましょう。

← ブログ一覧に戻る