Fastifyのプロキシで公開パスの制限回避｜関連2パッケージを更新して上流到達を確認

FastifyでAPIの一部だけを公開するプロキシを組んでいる場合、パスの書き換え設定をアクセス制御の根拠にしていないか確認してください。2026年11月2日、@fastify/http-proxyと@fastify/reply-fromで、想定した上流パスの境界を越える3件の脆弱性が公表されました。http-proxyは11.6.6以降、reply-fromは12.8.1以降への更新を確認する必要があります。

最も評価が高いCVE-2026-120213は、パラメーター付きのprefixとrewritePrefixを組み合わせた構成が対象です。別の問題を修正したhttp-proxy 11.6.3へ更新済みでも、この問題の修正先には届きません。依存パッケージの実際の版と、転送先で受け取るパスを両方確認することが今回の対応の中心になります。

本稿は同日確認した開発元の公式勧告に基づくニュースです。以下の棚卸し・検証・調査の手順は本サイトの提案で、独自の攻撃実験や実測結果ではありません。勧告で示された影響を、全Fastifyアプリの侵害や任意コード実行へ広げて解釈しないでください。

公開用の末尾パスが消える問題

Fastify公式勧告 GHSA-h3vp-4jfr-v364によると、CVE-2026-120213では、URLデコード済みのルートパラメーターが再エンコードされずにrewritePrefixへ挿入されます。パラメーター内のスラッシュと、フラグメントやクエリーの区切りとして解釈される文字の組み合わせにより、追加の上流パスが入り、固定したはずの末尾部分が失われる仕組みです。

提供元は、テナントごとの公開アバターに限定する構成を例に、別の管理用パスへ転送される可能性を示しています。この経路は「..」を使う必要がありません。上位ディレクトリーを示す文字列だけを探す検査では、同じ種類の境界回避を見落とす理由になります。

影響版は@fastify/http-proxyの9.0.0以上11.6.6未満、修正版は11.6.6です。CVSS v3.1は9.1、Criticalで、ネットワークからの攻撃、権限不要、利用者操作不要という評価です。この9.1はCVE-2026-120213の値であり、以下の2件へ共通のスコアとして当てはめるものではありません。

成立条件は、パラメーター付きprefixとrewritePrefixによって、上流の公開領域を限定していることです。上流側が別途認証・認可を行っているかで到達後の影響は変わります。勧告は上流次第でSSRFや認可回避につながると説明しており、プロキシが存在するだけで全管理APIを操作できるとは述べていません。

バックスラッシュの扱いが食い違う別経路

Fastify公式勧告 GHSA-hr26-gmr2-pwcvが扱うCVE-2026-120214は、http-proxyの11.6.0から11.6.2が対象で、11.6.3が修正版です。文字として存在するバックスラッシュを先に正規化しても、パーセントデコードの後から現れるバックスラッシュには同じ処理が届かない点が問題になります。

この問題では、上流がデコード後のバックスラッシュをパス区切りとして解釈することが必要です。公式はWindows上で静的ファイルを配信するホストなどを例に挙げています。公開用の接頭辞を付けて転送したつもりでも、上流の解釈によってその外側の資源へ到達し得ます。評価はCVSS v3.1で5.9、Moderateです。

この2件をまとめる場合も、条件は混ぜないことが重要です。120214には上流の区切り解釈という追加条件がありますが、120213のパラメーター置換問題をWindows限定と説明することはできません。運用台帳では、それぞれのCVE、利用版、該当する設定、上流の動作を別の項目にします。

reply-fromを直接使うアプリも更新対象

Fastify公式勧告 GHSA-vp2r-3vgv-32g9は、@fastify/reply-fromの12.8.0までにCVE-2026-117518があると説明しています。従来の検査はスラッシュによるドット区切りだけを見ていましたが、その後に使うWHATWG URLパーサーがバックスラッシュなどを正規化し、検査時とは違う転送パスを作る可能性があります。

たとえば公開用の上流パスへ利用者の入力を連結してreply.from()へ渡す構成や、その呼び出しの前にルートのガードを置いている構成が確認対象です。入口で正しい公開ルートに一致したという事実と、正規化後の転送先が許可範囲に収まることは同じ確認ではありません。

修正版12.8.1では、URLを構築する前に正規化し、単一・二重のドットへ解決される区間、制御文字、曖昧な空白を拒否する処理が説明されています。評価はCVSS v3.1で8.2、Highです。3件とも公式勧告の回避策欄は更新を求めており、独自の文字列置換を修正の代替として扱わないでください。

二つのパッケージと設定を一緒に棚卸しする

http-proxyの公式READMEは、このプラグインがreply-from上に構築されていると説明しています。自分のpackage.jsonにreply-fromを書いていなくても、間接依存として導入される可能性があります。逆にreply-fromだけを使うアプリへ、http-proxyの設定条件をそのまま適用することもできません。

npm ls @fastify/http-proxy @fastify/reply-from
npm explain @fastify/reply-from

上記はnpm管理のプロジェクトで依存関係を調べる例です。ローカル開発機だけで実行せず、本番を作るロックファイルと同じ依存解決結果を確認します。複数版が表示されたら、それぞれを呼び出す親パッケージまで追います。別のパッケージ管理ツールを使う環境では、そのツールの依存ツリー確認方法へ読み替えてください。

設定では、prefix、rewritePrefix、reply.from()の引数を検索し、パラメーターやワイルドカードがどこで挿入されるかを整理します。http-proxyのREADMEはupstream内のパスが無視され、転送先のベースパスにはrewritePrefixを使うと説明しています。upstreamのURLに公開用パスを書いたから限定できている、という思い込みもこの機会に点検します。

棚卸し表には、外部に見せる入口、書き換え後に許可する上流パス、転送できるHTTPメソッド、認証を行う場所、上流での認可の有無を記録する方法を勧めます。GETの公開参照と、更新・削除を行う処理を同じ経路で扱っていないかを確認すると、到達可能性と実際の業務影響を分けて評価できます。

更新は依存解決から再配備まで確認する

更新時はhttp-proxy 11.6.6以降とreply-from 12.8.1以降をそれぞれ確認します。依存範囲を書き換えただけでは、ロックファイルに古い版が残ったり、別の親パッケージから旧版が導入されたりする場合があります。採用する版を決めた後、クリーンなビルドで依存ツリーを再確認してください。

公式READMEの現在のhttp-proxyはFastify 5.xを前提としています。古いFastify構成で、互換性を確認せず最新版へ置換する作業は避けます。旧系列に同じ修正があるか不明なら、保守可能な構成への移行と利用停止・公開範囲の見直しを担当者間で判断します。確認していない旧系列の安全な版番号を補ってはいけません。

コンテナを利用している場合は、修正した依存を含むイメージを再ビルドし、各レプリカへ配備したことを確認します。タグ名だけでなくダイジェスト、ビルド日時、配備先、依存確認の結果を残すと、古いキャッシュや更新漏れを区別できます。再起動の成功と、修正版が実際に動いていることは別の判定項目です。

拒否応答だけでなく上流の到達記録を見る

更新後の検証は、権限を持つ隔離した検証環境で行います。実データや本物の管理APIを置く代わりに、公開用と非公開用のダミーエンドポイントを用意し、上流が受け取ったパスとメソッドを記録します。ここでの手順は検証計画の提案であり、本サイトが当該版で実施した試験結果ではありません。

通常の公開パス、通常のテナント識別子、存在しない識別子を基準にし、その後でパーセントエンコードした区切りやドット区間など、各勧告が扱う入力を試験項目に加えます。120213はドットなしの置換経路も対象なので、ドット区間の試験だけで完了にしないでください。期待する拒否と、公開機能が引き続き使えることを両方確認します。

入口の応答が400や403でも、先に上流へ転送されてからエラーになっていないか確認が必要です。逆に200が返っても、それだけで保護領域へ到達したとは判断できません。プロキシと上流の記録をリクエストIDで対応付け、到達先のパスを照合します。デコード前後の値を記録する場合は、資格情報や個人情報をログへ増やさないよう対象を絞ります。

過去の影響を調べる際は、外部公開期間、当時の設定、上流での認可、保存されているアクセス記録を組み合わせます。異常なエンコードや非公開パスへのアクセスは調査の手掛かりですが、単独で侵害成功の証拠にはなりません。今回読んだ公式勧告は実環境の悪用確認を示していないため、悪用状況は未確認として扱います。

対応完了の条件は、修正版への反映、依存ツリーの確認、想定外パスの非到達、通常機能の動作、過去の露出の評価です。URLの接頭辞を付けたことだけを認可の証拠にせず、上流自身にも必要な権限検査があるかを点検することを勧めます。文字の解釈が変わる境界を、設定と到達記録の両側から確認してください。