はじめに：なぜこの脆弱性が重要なのか？

日本のフロントエンドエンジニアの皆さん、こんにちは。今回は、Webアプリケーションでフォームデータを扱う際に注意すべき重大な脆弱性、GHSA-xp7r-j8r6-j9h3（CVE-2026-45302）について解説します。これは`parse-nested-form-data`というライブラリに存在するプロトタイプ汚染の脆弱性で、悪用されるとアプリケーション全体の挙動が乗っ取られる可能性すらある非常に危険なものです。サーバーサイドの技術だと感じるかもしれませんが、フロントエンドで生成されるデータがバックエンドでどのように処理されるかを理解することは、安全なWebアプリケーション開発において不可欠です。本記事を読んで、ご自身のプロジェクトが影響を受けないか確認し、適切な対策を講じてください。

parse-nested-form-data とは？

`parse-nested-form-data`は、HTMLフォームなどから送信されたデータを解析し、JavaScriptのネストされたオブジェクト形式に変換するためのユーティリティライブラリです。例えば、`user[name]=Alice&user[age]=30`のようなフォームデータを`{ user: { name: 'Alice', age: 30 } }`といったオブジェクトに変換してくれます。多くのバックエンドフレームワークやAPIサーバーで、ユーザーからの入力を扱いやすくするために利用されています。

プロトタイプ汚染 (Prototype Pollution) とは？

この脆弱性の根幹にあるのが「プロトタイプ汚染」と呼ばれる攻撃手法です。JavaScriptでは、全てのオブジェクトが`prototype`というプロパティを通じて、共通の機能を継承しています。たとえば、`Object.prototype`にメソッドやプロパティを追加すると、それ以降に作成される全てのプレーンなオブジェクトにその追加された機能が反映されます。

プロトタイプ汚染とは、攻撃者がこの`Object.prototype`を意図せず、あるいは悪意を持って改ざんすることを指します。改ざんされたプロパティは、アプリケーション内のあらゆる場所で使われるオブジェクトに影響を及ぼし、予期しない動作やセキュリティ上の問題を引き起こす可能性があります。

脆弱性の具体的なメカニズム

`parse-nested-form-data`ライブラリの`parseFormData()`関数は、フォームデータのフィールド名を解析する際に、特別な処理を行っていました。問題は、フォームのフィールド名に`__proto__`というJavaScriptの特殊なプロパティ名が含まれている場合です。

例えば、攻撃者が以下のようなフォームデータを送信したとします。

``` __proto__.isAdmin=true ```

これを`parseFormData()`が処理すると、ライブラリは`__proto__`をオブジェクトのプロトタイプチェーンを辿る指示として解釈し、最終的に`Object.prototype`に`isAdmin: true`というプロパティを追加してしまいます。これにより、アプリケーション内で新しく作成される全てのプレーンなオブジェクトが、自動的に`isAdmin: true`を持つ状態になってしまうのです。

想定される深刻な影響

`Object.prototype`が汚染されると、アプリケーションには以下のような深刻な影響が及ぶ可能性があります。

<ul><li>**アプリケーションの状態破損**: 意図しないプロパティの追加により、内部データ構造が破壊され、アプリケーションがクラッシュしたり、予期しないエラーが発生したりします。</li><li>**制御フローの変更**: アプリケーションのロジックが、汚染されたプロパティの値を参照することで、攻撃者の意図するパスでコードが実行される可能性があります。場合によっては、リモートコード実行 (RCE) に繋がることもあり、最も危険なシナリオの一つです。</li><li>**サービス拒否 (DoS)**: プロトタイプ汚染によってアプリケーションが不正な状態に陥り、正常に動作できなくなり、サービスが停止する可能性があります。</li></ul>

この脆弱性は、認証されていないリモートクライアント（つまり、誰でも）が、たった一つの悪意あるフィールド名を使うだけで攻撃可能です。非常に広範囲かつ深刻な影響をもたらす可能性があるため、対応は急務です。

影響を受ける条件

この脆弱性の影響を受けるのは、攻撃者が内容を制御できる`FormData`（HTMLフォームからの送信データなど）を`parse-nested-form-data`ライブラリの`parseFormData()`関数に渡しているアプリケーションです。典型的には、Node.jsなどの環境でHTTPサーバーがウェブフォームからのデータを処理する際にこのライブラリを使用している場合に該当します。

フロントエンドエンジニアの皆さんにとっては、自身が開発したフォームが、バックエンドでこの脆弱性を持つライブラリで処理されていないか、改めて確認することが重要です。

推奨される対応策：速やかなアップデート

この脆弱性は、`parse-nested-form-data`のバージョン`1.0.1`で修正されています。最も推奨される対応策は、プロジェクトで使用しているライブラリを直ちにこのバージョン以上にアップグレードすることです。

```bash npm install parse-nested-form-data@^1.0.1 # または yarn upgrade parse-nested-form-data@^1.0.1 ```

バージョン`1.0.1`では、パスセグメントに`__proto__`、`constructor`、または`prototype`といった危険なキーワードが含まれる場合に、`ForbiddenKeyError`という新しいエラーがスローされるように変更されました。これにより、プロトタイプ汚染攻撃が未然に防がれます。

アップグレードが困難な場合の回避策

すぐにライブラリのアップグレードができない場合でも、一時的な回避策を講じることでリスクを軽減できます。`parseFormData()`を呼び出す前に、送信されたフォームデータのフィールド名に危険なキーワードが含まれていないかをチェックする処理を実装してください。

```javascript const FORBIDDEN = /(^|\.)(__proto__|constructor|prototype)($|[.[])/; // 例: ExpressなどのミドルウェアでFormDataを処理する前にチェック // function validateFormData(req, res, next) { // if (req.body instanceof FormData) { // または、他のFormData取得方法に応じて // for (const [name] of req.body.entries()) { // if (FORBIDDEN.test(name)) { // return res.status(400).send('危険なフィールド名が含まれています。'); // } // } // } // next(); // } // 例として、FormDataオブジェクトを直接扱う場合 // const formData = new FormData(someFormElement); for (const [name] of formData.entries()) { if (FORBIDDEN.test(name)) throw new Error('Unsafe field name'); } // 上記チェックをパスしたら parseFormData() を呼び出す // const parsedData = parseFormData(formData); ```

上記のコードは、フォームデータ内の各フィールド名に対して正規表現で危険なキーワードをチェックし、もし見つかった場合はエラーをスローして処理を中断します。これにより、プロトタイプ汚染の攻撃を防ぐことが可能です。ただし、これはあくまで一時的な回避策であり、最終的にはライブラリのアップグレードを強く推奨します。

まとめ

`parse-nested-form-data`におけるプロトタイプ汚染の脆弱性(GHSA-xp7r-j8r6-j9h3)は、Webアプリケーションのセキュリティを根幹から揺るがす可能性のある重大な問題です。フロントエンドエンジニアの皆さんも、バックエンドで利用されるライブラリのセキュリティにも目を向け、自身の提供するデータがどのように処理されるかを常に意識する必要があります。

繰り返しになりますが、速やかに`parse-nested-form-data`をバージョン`1.0.1`以上にアップグレードしてください。もしそれが難しい場合は、提供された回避策を適用し、アプリケーションを保護しましょう。安全なWebサービス提供のため、セキュリティアップデートは怠らないようにしましょう。