CVE-2026-12143: form-data CRLF Injection Header Attack (Versions ≤4.0.5)

Technical summary

CVE-2026-12143 is a CRLF injection (CWE-93) in the form-data library affecting versions ≤4.0.5. The `append()` method and `filename` option fail to sanitize CR (\r), LF (\n), and double-quote characters in the field argument before inserting them into the `Content-Disposition` header. An attacker supplying crafted input can terminate the header line, inject additional headers, or smuggle additional multipart parts into the serialized request. The fix applies percent-encoding (%0D for CR, %0A for LF, %22 for quotes) matching the WHATWG HTML standard. Patched versions: 2.5.6, 3.0.5, and 4.0.6.

Business impact

For API gateways, proxies, and backend services that accept dynamic form data: exploitation enables parameter tampering and potential privilege escalation. An attacker could inject admin flags, modify user-submitted data in transit, or circumvent business logic that depends on form field integrity. Organizations running form-data in production without version-gating risk accepting maliciously crafted multipart payloads that downstream parsers will process as legitimate requests.

Affected systems

The form-data Node.js library versions through 4.0.5 are affected. This includes the 2.x, 3.x, and 4.x release lines. Systems most at risk are those that: (1) use form-data to construct multipart requests; (2) derive field names or filenames from untrusted sources (e.g., request parameters, user uploads, API inputs); and (3) forward the resulting requests to backend services that parse those fields. Common patterns: API gateways translating JSON to multipart, file upload handlers, and proxy middleware.

Exploitability

Exploitability is straightforward if the vulnerable code path is active. No authentication is required, no special network setup is needed, and the attack is entirely deterministic. However, exploitation depends on the consuming application actually passing attacker-controlled data as field names or filenames. Applications using only hardcoded field names are immune. The attacker must understand the downstream parser's behavior to craft a payload that achieves their goal (e.g., field injection or privilege escalation).

Remediation

Upgrade form-data to version 2.5.6, 3.0.5, or 4.0.6 or later, depending on which major version your project uses. If immediate patching is not possible, implement input validation upstream: reject or sanitize field names and filenames to exclude CR, LF, and quote characters before passing them to `FormData#append()`. Additionally, audit your application to identify any code that constructs field names or filenames from untrusted sources and consider refactoring to use only fixed/controlled field names where feasible.

Patch guidance

Check your dependency tree for form-data and determine which major version (2.x, 3.x, or 4.x) you are using. Update to the corresponding patched version: 2.5.6+, 3.0.5+, or 4.0.6+. Test thoroughly before production deployment, as there is a small risk of unexpected behavior if any code was relying on the previous (unsafe) serialization. Most applications will see no functional change. Refer to the form-data project's release notes and vendor advisory for the complete list of changes and any migration notes.

Detection guidance

In logs or traffic inspection: look for unusual characters (encoded as %0D, %0A, %22, or literal \r, \n) appearing in multipart form field names or filename parameters in requests processed by form-data. Monitor for Content-Disposition headers that contain multiple line breaks or additional headers spliced mid-value. If you have access to application code, search for dynamic construction of field names passed to `FormData#append()` or dynamic filename options. Code review should focus on any path where request parameters, user input, or external data sources influence field naming.

Why prioritize this

This vulnerability merits immediate attention: (1) it is a HIGH severity injection flaw (CVSS 7.5) with high impact on integrity; (2) it requires no user interaction and can be triggered over the network; (3) it enables privilege escalation and data manipulation in systems that rely on form field integrity; (4) the fix is straightforward and low-risk. Organizations using form-data in production should prioritize patching within days, not weeks. Applications that can prove they use only hardcoded field names can be deprioritized after quick code review.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a HIGH severity: network-accessible attack vector (AV:N), low attack complexity (AC:L), no privilege required (PR:N), no user interaction (UI:N), and high integrity impact (I:H). There is no confidentiality or availability impact, which prevents a critical rating. The score appropriately reflects the real-world risk for applications that dynamically construct field names or filenames from untrusted input.

Frequently asked questions