はじめに：`http-proxy-middleware`をご利用の皆さんへ

日本のフロントエンドエンジニアの皆さん、こんにちは。開発環境でのAPIプロキシ、あるいはMicroservicesアーキテクチャにおけるAPI Gatewayなど、様々な場面で`http-proxy-middleware`のようなHTTPプロキシライブラリを利用している方は多いのではないでしょうか。今回は、その`http-proxy-middleware`に発見された、比較的深刻度の高い脆弱性(CVE-2026-55603 / GHSA-gcq2-9pq2-cxqm)について、技術的な側面から詳しく解説し、皆さんのプロジェクトにおける影響と対策を検討していきます。

脆弱性の概要 (GHSA-gcq2-9pq2-cxqm / CVE-2026-55603)

この脆弱性は、`http-proxy-middleware`を使ってリクエストを転送する際に、リクエストボディ内の改行コード（`\r\n`）が適切に処理されないことに起因します。特に、`Content-Type: multipart/form-data`形式のリクエストにおいて、攻撃者がプロキシを介してバックエンドに不正なフォームパートを注入できるようになります。これにより、バックエンドでのセキュリティチェックをすり抜けたり、データを改ざんしたりする危険性があり、アプリケーションの認証やデータ整合性に重大な影響を及ぼす可能性があります。深刻度は`High`と評価されています。

この脆弱性がフロントエンド開発にどう関係するのか？

私たちフロントエンドエンジニアは、通常バックエンドのコードに直接触れることは少ないかもしれません。しかし、開発環境でWebpack Dev ServerやViteなどの開発サーバーのプロキシ設定に`http-proxy-middleware`を使用している場合、あるいは企業内の共通APIゲートウェイとしてNode.jsアプリケーションが`http-proxy-middleware`を利用している場合、この脆弱性は無関係ではありません。

フロントエンドが送信したデータがプロキシを経由してバックエンドに渡る際、プロキシの脆弱性によってデータが改ざんされる可能性があります。これにより、フロントエンドが意図しない、あるいは不正なデータがバックエンドに渡り、認証バイパスやデータベースの不正更新など、アプリケーション全体のセキュリティが脅かされることになります。自身の環境だけでなく、連携するバックエンドやインフラの構成も視野に入れて確認することが重要です。

脆弱性のメカニズム：`multipart/form-data`の巧妙な悪用

この脆弱性の核心は、`http-proxy-middleware`内部の`fixRequestBody()`関数、特に`multipart/form-data`形式のリクエストボディを再構築する`handlerFormDataBodyData()`関数に存在します。

通常の処理では、ボディパーサーでパースされた`req.body`のキーと値を使って、`multipart`形式の文字列が再構築されます。しかし、`handlerFormDataBodyData()`関数は、`req.body`のキーや値に含まれる**改行コード (`\r\n`) を適切にエスケープしません**。このエスケープ漏れが悪用されます。

攻撃者は、リクエストボディのフィールド値（またはキー）に意図的に`\r\n`と`multipart`の区切り文字を挿入します。これにより、プロキシ側で再構築される`multipart`ボディ内で、既存のフォームパートを途中で閉じ、**新しいフォームパートを自由に注入できる**ようになります。結果として、プロキシが認識している`req.body`の内容と、最終的にバックエンドサーバーが受け取るリクエストの内容が食い違ってしまい、バックエンドが不正なデータを処理してしまうのです。

なお、`application/json`や`application/x-www-form-urlencoded`形式のリクエストは、それぞれ`JSON.stringify`や`querystring.stringify`で適切にエスケープされるため、この脆弱性の影響は受けません。

あなたのアプリケーションは影響を受けるか？重要な3つの条件

この脆弱性は、以下の**3つの条件がすべて満たされた場合**に発生します。

1. **プロキシアプリケーションが`req.body`を、`multipart`形式ではないボディパーサーでパースしていること。**<br> 例: `express.urlencoded`、`express.json`、またはプレーンテキストパーサーなど。これにより、攻撃者が挿入した`multipart`の境界線がプロキシ側では単なる文字列として扱われ、そのままバックエンドに転送されてしまいます。

2. **プロキシ経由で送信される（外部への）リクエストが`multipart/form-data`形式であること。**<br> これにより、脆弱性のある`handlerFormDataBodyData()`関数が実行されます。

3. **アプリケーションが`fixRequestBody`関数を呼び出しており、かつ攻撃者がリクエストボディ内の少なくとも1つのフィールドの値またはキーを制御できること。**<br> 攻撃者が注入したい内容を制御できることが前提となります。

一般的な`multer`などの`multipart`パーサーをプロキシ側で使用している場合は、プロキシ側で既に攻撃者の注入した境界線が分割されてしまうため、この注入攻撃には通常悪用されにくい点も覚えておきましょう。

もたらされる具体的なリスク

上記の条件が満たされた場合、攻撃者はバックエンドのみが認識する`multipart`フィールドを自由に注入または上書きできるようになります。具体的なリスクは以下の通りです。

・**検証/アクセス制御のバイパス:** ゲートウェイ側で特定のフィールドに対する検証やアクセス制御が設定されていても、それをすり抜け、バックエンドに不正なデータを渡すことが可能になります（例: `role=admin`を注入して管理者権限を不正に取得する）。

・**パラメータの改ざん:** バックエンドが信頼して処理するID、フラグ、価格などの重要なパラメータを、攻撃者が追加したり、意図しない値に上書きしたりすることができます。

・**ファイルパートの注入:** `filename="..."`のような`multipart`のファイルパートを、アップストリームのストリームに不正に挿入し、意図しないファイルをアップロードさせるなど、さらに深刻な攻撃につながる可能性があります。

今すぐできる対策と推奨される修正

この脆弱性に対処するためには、以下の対応を検討してください。

1. **専用の`multipart`エンコーダーライブラリの使用:**<br> 最も安全かつ推奨される方法は、ボディを文字列連結で構築するのではなく、`FormData` (ブラウザAPI) や `form-data` (Node.jsライブラリ) のような**専用の`multipart`エンコーダーライブラリ**を使用してリクエストボディを再構築することです。これらのライブラリは、内部的に改行コードやその他の特殊文字を適切にエスケープ処理するため、安全性が高まります。

2. **改行コード (`\r\n`) および二重引用符 (`"`) のチェックとエラー処理 (一時的な修正):**<br> もし専用ライブラリへの移行が難しい場合、一時的な対策として、`req.body`のキーや値に改行コード（`\r\n`）や二重引用符（`"`）が含まれていないかをチェックし、見つかった場合は処理を中止しエラーをスローすることを検討してください。これにより、悪意のある入力を拒否できます。サイレントに削除するよりも、問題を明確にするためにエラーをスローすることが推奨されます。

3. **`http-proxy-middleware`のバージョンアップ:**<br> 本脆弱性に対応したバージョンがリリースされている場合、可能な限り速やかにバージョンアップを行ってください。これは最も直接的な解決策です。

4. **プロキシ側のボディパーサーの見直し:**<br> もしプロキシ側で`multipart`ではないボディパーサー（例: `express.json`）を使用しているためにこの脆弱性の影響を受ける場合、`multipart/form-data`のリクエストを適切に処理するために`multer`などの`multipart`パーサーの導入を検討してください。これにより、不正な境界線がバックエンドに到達する前に処理されます。

まとめ

今回の`http-proxy-middleware`の脆弱性は、開発プロセスで深く関わることの少ないミドルウェア層にも、思わぬセキュリティリスクが潜んでいることを示しています。特に`multipart/form-data`のような複雑なデータ形式を扱う際には、その処理方法に細心の注意を払う必要があります。

自身のプロジェクトや利用しているインフラで`http-proxy-middleware`が使われているかを確認し、上記で解説した3つの条件に当てはまる場合は、速やかに推奨される対策を実施してください。フロントエンドエンジニアも、こうしたバックエンド寄りのミドルウェアのセキュリティ動向に目を光らせ、アプリケーション全体の安全性を確保する意識を持つことが重要です。