CVE-2026-45302: Prototype Pollution in parse-nested-form-data Before 1.0.1

Technical summary

The vulnerability stems from unsafe traversal of FormData field names using bracket and dot notation without validation of reserved property keys. When parseFormData() encounters a field name containing `__proto__` as a segment, it writes directly to Object.prototype rather than halting or sanitizing the input. This is a classic prototype pollution flaw. An attacker controlling form field names can inject arbitrary properties into the prototype chain, affecting all objects that inherit from Object—essentially every plain object in the running process. The issue is network-accessible (AV:N), requires no authentication (PR:N), and can be triggered through a single malicious form submission.

Business impact

Applications using vulnerable versions of parse-nested-form-data face integrity and availability risks. An attacker can corrupt application state by polluting object prototypes, potentially causing unexpected behavior in business logic, authentication checks, or data validation routines. In worst-case scenarios, an attacker could disable critical features or leak sensitive information stored in object properties. The attack requires only network access and no user interaction, making it a straightforward vector for malicious actors. Any user-facing application or API endpoint that accepts and parses form data using this library is exposed.

Affected systems

All applications running parse-nested-form-data versions prior to 1.0.1 are affected. This includes any Node.js application that imports and uses the parseFormData() function to process user-submitted form data. Because the library is published on npm and is designed for form parsing, affected systems span web applications, REST APIs, microservices, and backend systems that accept multipart/form-data or application/x-www-form-urlencoded submissions. The vulnerability's scope is determined by the version constraint in each application's package.json or package-lock.json.

Exploitability

Exploitation is straightforward and requires minimal effort. An attacker simply crafts a form submission with a malicious field name—for example, a field named `__proto__.isAdmin` set to `true`, or `__proto__.constructor.prototype.adminBypass` with any value. No special tools, authentication, or user interaction are required. The attack is immediate upon form submission and affects the entire application process. The CVSS vector (AV:N/AC:L/PR:N/UI:N) reflects this low barrier to entry. However, the impact is not critical because the vulnerability results in information disclosure or availability degradation rather than remote code execution.

Remediation

Upgrade parse-nested-form-data to version 1.0.1 or later immediately. Version 1.0.1 includes filtering logic that prevents traversal into reserved prototype keys. After upgrading, restart all application instances. Verify that your application's dependency lock file (package-lock.json or yarn.lock) reflects the patched version. If you cannot upgrade immediately, implement input validation upstream: reject or sanitize any form field names containing `__proto__`, `constructor`, or `prototype` segments before passing them to the parser.

Patch guidance

Patch deployment is straightforward: run `npm update parse-nested-form-data` or `yarn upgrade parse-nested-form-data` to pull version 1.0.1 or later. Verify the installed version in node_modules or via `npm list parse-nested-form-data`. Confirm the version matches 1.0.1+ in your package-lock.json. Restart your application process to load the patched code. Testing should include a basic smoke test to confirm form parsing still works for legitimate inputs. Consider adding test cases for malicious field names to prevent regression.

Detection guidance

Monitor application logs and request bodies for form field names containing `__proto__`, `constructor`, or `prototype` segments. These patterns in FormData submissions are strong indicators of attempted exploitation. Intrusion detection systems and WAF rules can flag requests with these keywords in parameter names. Additionally, monitor for unexpected changes to Object.prototype at runtime (difficult but possible with custom instrumentation). Review application behavior logs for anomalies in object property values—if prototype pollution has occurred, you may see unexpected properties appearing in objects throughout your application.

Why prioritize this

This vulnerability scores HIGH (8.2) due to network accessibility, absence of authentication or user interaction barriers, and significant integrity/availability impact. While not critical (no RCE), prototype pollution in production systems can cascade into serious issues. The attack surface is large (any form submission), the fix is simple (upgrade), and the risk of active exploitation is real. Prioritize based on whether your application is internet-facing and whether it directly uses parse-nested-form-data; non-public internal tools are lower risk.

Risk score, explained

CVSS 3.1 score of 8.2 (HIGH) is justified by: Attack Vector Network (AV:N)—remotely exploitable; Attack Complexity Low (AC:L)—no special conditions required; Privileges Required None (PR:N)—unauthenticated access sufficient; User Interaction None (UI:N)—automatic upon form submission; Scope Unchanged (S:U)—impact limited to the vulnerable application; Confidentiality None (C:N)—no direct data exposure; Integrity High (I:H)—object properties can be corrupted; Availability Low (A:L)—denial of service possible through logic disruption. The score does not reach Critical (9.0+) because the vulnerability does not grant code execution or direct access to sensitive data, only the ability to corrupt application state.

Frequently asked questions