@fastify/http-proxy の WebSocket 経路でパストラバーサルにより rewrite プレフィックスを迂回

Critical（CVSS 10.0）に分類されるFastify @fastify/http-proxyの脆弱性です。Node.js のフレームワーク Fastify のプロキシプラグイン @fastify/http-proxy に、WebSocket の経路だけ経由するパストラバーサルがある。NVD の記述によれば、9.4.0 から 11.5.0 までのバージョンは、解決後の WebSocket 宛先パスを、設定した rewrite プレフィックスに対して検証していない。WebSocketProxy.findUpstream は WHATWG URL コンストラクタで宛先を解決するが、これはドットセグメント（.. など）を畳み込むため、パストラバーサル列を含む upgrade リクエストを作ると rewrite プレフィックスの外へ抜け、プロキシが公開するつもりのなかった上流エンドポイントへ到達できる。これは CVE-2021-21322 の変種で、HTTP 側の修正が入らなかったコードパスに残っていた。悪用には、リクエストパスを正規化しない WebSocket クライアントが必要である。ブラウザと ws パッケージは送信前に正規化するため、生の HTTP クライアントや、リクエストターゲットをそのまま転送する下流プロキシが経路にある構成が対象になる。CVSS 3.1 基本値は 10（Critical）で、ベクタは AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N。当初は 8.7（High）・AV:N/AC:H/… として登録されていたが、2026年8月15日の再点検で、NVD 側が攻撃条件を AC:H から AC:L へ、深刻度を High から Critical へ改定しているのを確認した。AC:L への改定は、「パスを正規化しないクライアントが要る」という前提が攻撃側の障壁として数えられなくなったことを意味する。生の HTTP クライアントも、リクエストターゲットをそのまま転送する下流プロキシも、攻撃者が用意するのは難しくないためである。修正は 11.6.0 で行われた。回避策は無い。2026年8月15日時点で CISA KEV カタログには収載されていない。

まず該当するかを package-lock.json か pnpm-lock.yaml で判定する。@fastify/http-proxy が 9.4.0 以上 11.5.0 以下なら影響を受ける。WebSocket のプロキシを使っていない場合でも、プラグインを読み込んでいれば該当バージョンの入れ替えは行う。対応は 11.6.0 以上への更新だけで、公式に回避策は示されていない。すぐに更新できない場合の実務的な緩和は、プロキシの前段でパスを正規化することである。前段に nginx や CDN があるなら、そこで .. を含む upgrade リクエストを落とすか正規化する。経路のどこかでパスが正規化されれば攻撃が成立しないという性質そのものは変わらない。ただし NVD は 2026年8月15日時点で攻撃条件を AC:L（当初は AC:H）と評価しており、基本値も 10 に上がっている。「条件が厳しいから後回しでよい」という判断はもう取れないので、前段の正規化は更新までの時間稼ぎと位置づけ、恒久対応にはしない。侵害の確認は、アクセスログの upgrade リクエストで %2e や .. を含むパスを検索する。同じコードベースで @fastify/reply-from も使っているなら、CVE-2026-16158（URLキャッシュのキー衝突）も併せて確認する。

Fastify @fastify/http-proxy を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-15631）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。