@fastify/http-proxyでプレフィックス逸脱｜CVE-2026-120213を11.6.6で修正

Node.js のプロキシプラグイン @fastify/http-proxy に、固定したはずの上流パスを抜けられる脆弱性（CVE-2026-120213・CVSS 9.1 Critical）が見つかり、11.6.6 で修正された。parameterized prefix と rewritePrefix で「クライアントを上流の決まったパスに閉じ込める」構成が対象で、デコード済みのルートパラメータ経由でその固定を外せてしまう。この記事は GHSA を一次に、@fastify/http-proxy 脆弱性の仕組みと確認・更新手順を整理する。攻撃を再現する文字列は扱わない。まず確かめることは、使っている版が 9.0.0〜11.6.5 で、かつ rewritePrefix で上流パスを固定しているかだ。

基盤ソフトの脆弱性がどう広がるかの全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。近接事例はPyPI公開まわりの信頼に2つの穴やKubeflow Pipelines の2件、Cursor 改ざん拡張のSSHバックドアも参考になる。今回は「リバースプロキシの境界」が破れる話だ。

何が起きるのか：固定したはずの接尾辞が外れる

@fastify/http-proxy は、Fastify の前段でリクエストを上流へ中継するプラグインだ。よくある使い方の一つが、ルートにパラメータを置き（例 /tenants/:tenant）、rewritePrefix で上流側のパスを固定して、クライアントを決まった範囲に閉じ込める構成だ。マルチテナントで「各テナントは自分のパスの中だけ」に縛る、といった用途がこれにあたる。

脆弱性の核心は、URLデコード済みのルートパラメータを、再エンコードせずに rewritePrefix に代入していた点だ。デコードされた / と、# または ? の組み合わせを使うと、本来 rewritePrefix が付けるはずだった固定の接尾辞が削られ、上流へ余分なパスセグメントが注入される。GHSA の例では、一見するとテナント配下のアバター取得に見えるリクエストが、上流では管理系のパス（master-keys）への GETに化ける。注目すべきは、.. によるディレクトリトラバーサルを一切使っていないことだ。デコードのタイミングと、/・#・? の解釈のズレ（CWE-436＝Interpretation Conflict）を突いている。だから、.. を弾くだけの素朴な対策では防げない。

ここで効くのが、多くの実装がこの rewritePrefix を“境界”として信頼しているという前提だ。プロキシの手前で「このクライアントは上流のこのパスより先へは行けない」と固定しておけば、上流側は細かい認可を書かなくて済む——そういう設計はよくある。パラメータ（:tenant など）で宛先を切り替えつつ、rewritePrefix で上流パスを固定するのは、その代表的なやり方だ。今回の逸脱は、その“固定”そのものが外れるので、プロキシに預けていた安全の前提が崩れる。URL のパーセントエンコードは、ブラウザ・プロキシ・アプリの各層で「いつデコードするか」が食い違いがちで、CWE-436 はまさにその隙間を突く類型だ。

プロキシのパス固定を「認可」にしていないか

今回の件は、更新で直る個別のバグであると同時に、設計上の教訓も含んでいる。プロキシのパス固定（prefix/rewritePrefix）だけを、テナント分離や権限の“唯一の壁”にしていないか、という問いだ。プロキシ層のパス書き換えは便利だが、エンコードやパスの正規化の解釈は層ごとにズレうるので、そこに境界のすべてを預けると、今回のような一点の実装ミスが即、認可の全面的な破れになる。

堅くするなら、上流サービス側でも認可を独立に効かせるのが定石だ。たとえば、テナントIDをパスだけでなくトークン（JWT の claim など）からも検証する、管理系のパスは上流側で明示的に拒否する、プロキシが渡すヘッダ（X-Tenant など）を上流が鵜呑みにしない、といった二重化だ。こうしておけば、プロキシのパス固定が外れても、上流がもう一段で弾ける。今回の更新（11.6.6）は当然やるべきだが、「プロキシのパス固定を唯一の壁にしない」という発想を一緒に入れておくと、次に似た逸脱が出ても被害を抑えられる。

影響と、確認・更新

CVSS 9.1（AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N）は、ネットワーク経由・認証不要・利用者操作不要で、機密性と完全性に高い影響、という評価だ。実害は上流サービスの性質で決まる。プロキシの先が内部API・管理機能・鍵管理のような機微なものなら、認可バイパスや SSRF の意味は大きい。逆に、上流が公開前提の静的配信なら相対的に影響は小さい。いずれにせよ、境界を固定しているつもりが外れているという前提は崩れている。

具体的に危ないのは、API ゲートウェイや BFF（Backend For Frontend）、マルチテナント SaaS のように、「1つの入口で、各クライアントやテナントを上流の決まったパスへ振り分ける」構成だ。/tenants/:tenant/... を受けて rewritePrefix で /<tenant>/... に固定し、テナントをその範囲に閉じ込める——この形はまさに対象で、逸脱が起きると別テナントや管理パスに届く。逆に、rewritePrefix を使わずに素通しで中継しているだけ、あるいは上流が元から公開されていて隠す前提が無い構成なら、この経路の旨味は小さい。まずは自分のプロキシ定義で、prefix にパラメータがあり、かつ rewritePrefix で上流パスを固定しているかを確かめるのが早い。

検知の面では、更新前に露出があったなら、プロキシと上流のアクセスログを一度さらっておきたい。手掛かりは、該当ルートに対する %2f（エンコードされた /）や #・? を含む不自然なパス、本来のテナント範囲から外れた上流パスへの到達、普段出ないステータスの並びだ。正規の利用でもエンコードは現れるので、単発では断定できないが、テナント境界をまたぐ到達と併せて見れば兆候になる。確実な判定は難しいので、疑わしければ上流側のアクセス記録と突き合わせるのが堅い。

確認は、使っている版と使い方を見る。

# 直接・推移的な依存の版を確認（9.0.0〜11.6.5 なら対象）
npm ls @fastify/http-proxy 2>/dev/null || true
# 11.6.6 以上へ更新
npm install @fastify/http-proxy@^11.6.6

※この版表示だけでは、すでに逸脱を突かれていたかどうかまでは判断できない。心配があれば、プロキシと上流のアクセスログで、該当ルートに対するエンコード済みの /（%2f）や #・? を含む不自然なパスが無かったかを見ておくとよい。恒久策は 11.6.6 への更新で、GHSA は回避策は無いとしている。

参照ソース

• GHSA-h3vp-4jfr-v364 / CVE-2026-120213（CVSS 9.1・CWE-22/436・9.0.0〜<11.6.6→11.6.6・回避策なし）
• @fastify/http-proxy（npm）（版の確認・更新）