Fastify の reply-from で upstream を跨ぐ誤転送が起きる

Critical（CVSS 10.0）に分類されるFastify @fastify/reply-fromの脆弱性です。Fastify のリバースプロキシ用プラグイン @fastify/reply-from の 8.3.1 以上 12.6.4 未満で、内部の URL キャッシュのキーを転送先と元のパスを区切り文字なしで連結して作っている。このため転送先とパスの組み合わせが異なるのに同じキーになる場合があり、解決される upstream の URL は別物という状態が起こる。getUpstream がリクエストの内容から転送先を選ぶ構成では、ある upstream 向けにキャッシュされた URL が別の upstream 宛てのリクエストで再利用され、本来アクセスできない upstream に対する読み取りと書き込みが発生する。アドバイザリは既定の構成が影響を受けると明記しており、disableCache を true にするとこの挙動を防げるとしている。修正版は 12.6.4。CVSS は評価元で割れており、NVD（Primary）は 10.0 Critical（CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N）、CNA（Secondary）は 8.7 High（AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N）で、キー衝突を狙う難しさを攻撃の複雑度としてどう見るかの差である。CISA KEV には未収載。NVD の vulnStatus は Analyzed。CWE は CWE-441。

判定は二段階で見る。まず npm ls @fastify/reply-from やロックファイルで版を確認し、8.3.1 以上 12.6.4 未満なら該当である。次に、自分の使い方が危険側かを切り分ける。この問題が実害になるのはリクエストの内容から転送先を動的に選んでいる構成、つまり getUpstream を使って複数の upstream に振り分けている場合で、転送先が固定のシンプルなプロキシであれば取り違えの余地は小さい。コード中の reply-from の登録箇所（fastify.register の設定、replyFrom の呼び出し、upstream や getUpstream の指定）を検索して、動的に決めている箇所があるかを確認する。マルチテナントのゲートウェイやテナントごとに upstream を切り替える API 前段で使っている場合が最も危険で、テナント間のデータ混線という形で影響が出る。見落としやすいのは、自分で書いたプロキシではなく社内共通のゲートウェイライブラリやテンプレートに組み込まれている場合と、コンテナイメージに焼き込んだ node_modules である。すぐ更新できない場合の緩和策はアドバイザリが明示しており、プラグイン登録時に disableCache: true を渡すことでこの挙動を止められる。キャッシュを切る分の性能低下は許容し、更新までの一時措置として入れておくのが現実的である。完了条件は、@fastify/reply-from が 12.6.4 以上になっていること、あるいは暫定として disableCache が有効になっていることを全環境で確認できた時点である。動的に upstream を選ぶ構成で長く動かしていた場合は、アクセスログを見てテナントや upstream の対応が食い違っている応答が過去に無かったかも点検しておく。

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