JVN（Japan Vulnerability Notes）は、Node.js 向け Web フレームワーク fastify のプラグインである @fastify/http-proxy に、パストラバーサルの脆弱性が存在すると公表している。インターネット経由で到達可能な環境では、影響範囲を確認し、該当する場合は速やかに修正済みバージョンへ更新することが重要である。
脆弱性の詳細
JVN（Japan Vulnerability Notes）によると、@fastify/http-proxy には、パストラバーサル（ディレクトリトラバーサル）に分類される脆弱性が存在する。パストラバーサルとは、外部から渡されるパス（URL やリソースの指定）を不適切に扱うことで、本来アクセスさせないはずの場所やエンドポイントへ到達できてしまう問題である。
この脆弱性は、プロキシのパス結合・書き換えの処理に不備がある場合に、攻撃者が細工したパスを含むリクエストを送信することで、意図しない上流（アップストリーム）パスにアクセスできてしまう点が問題となる。WebSocket のアップグレードリクエストや、URL エンコードを悪用したリクエスト、バックスラッシュを用いたドットセグメントなどを用いることで、プロキシ側で設定した prefix や rewritePrefix による制限を迂回し、内部向けエンドポイントや本来隠蔽している経路へ到達できる可能性がある。
JVN（Japan Vulnerability Notes）は本件を JVNDB-2026-032906 として公表している。CVE 番号および CVSS スコアについては、JVN（Japan Vulnerability Notes）の当該公表内容を確認のうえ、社内のリスク判断や対応優先度付けに反映させたい。悪用が成立した場合、機密情報の参照、内部情報の露出、認証済みユーザ専用 API の不正利用、さらには他の侵害の足掛かりとなるおそれがある。
公開している Web サービスの設定や運用状況によっては、情報漏えい、サービスの不正利用、内部管理用エンドポイントへのアクセスなどの影響が生じる可能性がある。インターネットから到達できる位置にある fastify ベースのサービスや API で @fastify/http-proxy を利用している場合は、優先度を上げて対応することが望ましい。
影響を受ける製品・バージョン
- fastify 用プラグイン
@fastify/http-proxy（JVN（Japan Vulnerability Notes）が公表した影響対象に該当するバージョン。一般には、9.4.0 以降 11.5.0 までの一部バージョンがパストラバーサルの影響を受け、修正版として 11.6.0 以降および 11.6.2 以降にかけて対策が施されているとされるが、正確な範囲は JVNDB-2026-032906 の公表内容に従うこと。）
推奨される対策
- アップデートの適用：JVN（Japan Vulnerability Notes）が示す修正版（修正を含むリリース）へ更新する。一般的には、
@fastify/http-proxyを 11.6.0 以上、バックスラッシュによるパストラバーサル問題に対しては 11.6.2 以上へ更新することが推奨されているが、最終的な判断は JVNDB-2026-032906 の記載に基づき行う。依存関係として導入している場合も、package-lock.jsonやpnpm-lock.yamlなどのロックファイル、ビルド成果物（コンテナイメージ、配布用バンドルなど）を含め、更新が反映されていることを確認する。 - 影響有無の確認：
@fastify/http-proxyを利用しているサービス、コンテナイメージ、サーバ上のアプリケーションでライブラリバージョンを確認し、JVN（Japan Vulnerability Notes）の影響範囲に該当するか棚卸しする。特に、WebSocket 経由でアップストリームに接続する構成や、外部公開 API の前段に本プラグインを用いている構成を重点的に確認する。 - 公開範囲の最小化：外部公開が不要な管理系エンドポイントや開発用経路がある場合は閉鎖し、到達経路を減らす。アップストリーム側の管理用 WebSocket エンドポイントなども、インターネットから直接到達できないようにする。アプリの前段にあるリバースプロキシや WAF のルールも見直し、不要なパスやプロトコル（WebSocket 含む）を遮断する。
- 監視とログ確認：不審なパス指定（
../などのドットセグメント、URL エンコードされたパス片、バックスラッシュによるディレクトリ移動を示す文字列など）を含むリクエストがないか、アクセスログとアプリケーションログを点検し、兆候があれば該当リクエストの送信元を隔離・調査する。WebSocket のハンドシェイク要求やプロキシ経由のリクエストも対象に含める。
日本の中小企業が今すぐ取るべき行動
- 最優先：利用有無の把握：自社の Web アプリや API、バックエンドサービスで
@fastify/http-proxyを使っているかを確認し、該当するシステム一覧を作る。package.jsonやロックファイル、コンテナの SBOM（ソフトウェア部品表）を確認することで、間接的に導入されているケースも洗い出す。 - 次に：外部公開の有無で優先度を決める：インターネット公開されているサービスから先に更新計画を立て、夜間・休日のメンテナンス枠を確保する。内部システムのみで利用している場合でも、ゼロトラストの観点から、リモートから到達可能な経路がないかを確認し、必要に応じてネットワーク制限を強化する。
- 更新の実施と動作確認：修正版へ更新し、プロキシ経由の正常系テスト（代表的な API 呼び出し、認証フロー、ファイル配信の有無、WebSocket 通信など）を実施して、業務影響を最小化しつつ脆弱性の再発がないことを確認する。アップストリーム側のログとも突き合わせ、想定外のパスへルーティングされていないかをチェックする。
- ログの点検と一次切り分け：過去一定期間（例：脆弱性公表前後数ヶ月）のアクセスログやプロキシログ、WebSocket ハンドシェイクログを確認し、不審なリクエストがあれば、当該端末・IP の遮断、関係者への連絡、証跡保全を行う。侵害の兆候がある場合は、被害範囲の特定、データの漏えい有無、関連する認証情報の再発行などの追加対応を検討する。
CSRIからの現場アドバイス
実際のペネトレーションテストでは、プロキシや中継機能が「入力されたパスをどのように結合・書き換え・検証するか」が盲点になりやすく、テスト環境だけ古い依存関係のまま残って発見されることがある。診断報告書でよく指摘されるのが、ライブラリ更新の担当不在と、依存関係の棚卸し不足である。
例えるなら、建物の案内板で「この扉の先だけ入ってよい」と決めているのに、抜け道の表示を悪用して倉庫や職員通路に入れてしまうようなものだ。つまり、許可した範囲のつもりでも、実装次第では別の場所に到達できてしまい、情報が見られる危険がある。パストラバーサルの脆弱性は、このような境界の設計ミス・検証不足によって生じる。
まず @fastify/http-proxy を使っているシステムのバージョンを確認し、JVN（Japan Vulnerability Notes）の影響範囲と照合する。次に担当者（または開発ベンダー）に、修正版への更新と再ビルド、デプロイ手順の確定を依頼する。最後にアクセスログやプロキシログを確認し、異常なパス指定や WebSocket 経路への不審なアクセスの痕跡がないか点検する。必要に応じて、WAF やリバースプロキシでのパス正規化・検証も強化し、防御を多層化しておきたい。