High severity7.5NVD Advisory· Published Jun 12, 2026· Updated Jun 12, 2026

CVE-2026-12143

Description

CRLF injection in form-data library lets attackers inject headers or form fields when attacker-controlled input is used as a multipart field name or filename.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

CRLF injection in form-data library lets attackers inject headers or form fields when attacker-controlled input is used as a multipart field name or filename.

Vulnerability

The form-data library (versions 4.0.5 and earlier, as well as 3.x and 2.x through the corresponding latest releases before the fix) fails to sanitize carriage return (CR), line feed (LF), and double-quote (") characters in the field argument to FormData#append and the filename option. These values are concatenated verbatim into the Content-Disposition header, enabling CRLF injection (CWE-93) [2]. An application that passes attacker-controlled data as a field name or filename—for example, an API gateway that maps JSON object keys to multipart field names—allows the attacker to terminate the header line and inject additional headers or even entire multipart parts into the forwarded request. This affects all versions through 4.0.5 (and corresponding 3.0.x, 2.5.x prior to the fix releases) [1][3][4].

Exploitation

An attacker needs the ability to control the string used as a field name or filename in a multipart request constructed by the vulnerable form-data library. No authentication is required if the application exposes an endpoint that accepts untrusted input and uses it directly as a form field name. The attacker provides a malicious string containing %0D%0A (CRLF) sequences to break out of the Content-Disposition header line, then injects arbitrary HTTP headers or additional multipart body parts. For example, injecting a complete Content-Disposition header line for a new part with a field name like is_admin and value true would cause the backend to interpret it as an additional form field [1][2].

Impact

Successful exploitation allows the attacker to add or override form fields seen by the downstream multipart parser. This can lead to privilege escalation (e.g., setting an is_admin=true field), data corruption, or bypassing access controls—depending on how the server processes the injected parameters. The impact is at the application logic level, potentially achieving unintended state changes or unauthorized data access. The CIA outcome is primarily integrity violation, with possible confidentiality and availability implications if the injected fields influence backend behavior [1][2].

Mitigation

The vulnerability is fixed in form-data versions 2.5.6, 3.0.5, and 4.0.6, released on 2026-06-12 [3][4]. The fix escapes CR, LF, and " as %0D, %0A, and %22 respectively, matching the WHATWG HTML multipart/form-data encoding algorithm [1]. Applications should upgrade to these patched versions immediately. Workarounds: if upgrade is not possible, applications must sanitize or reject any user-supplied input that will be used as a field name or filename, specifically stripping or encoding CR, LF, and double-quote characters before passing them to FormData#append. The vulnerability is not exploitable if the application only uses fixed, trusted field names [1].

References

AI Insight generated on Jun 12, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

Npm/Form Datareferences
Package: https://npmjs.com/package/form-data
Form Data/Form Datallm-fuzzy
Range: <=4.0.5

Patches

ecd6d1ca3f77

Merge tags v4.0.6, v3.0.5, and v2.5.6

https://github.com/form-data/form-dataJordan HarbandJun 12, 2026via github-commit-search

cvss	0.488
epss	0.000
exploit	0.000
kev	0.000
patch	-0.070
ransomware	0.000

Vulnerability

Exploitation

Impact

Mitigation

Root cause

Attack vector

Affected code

What the fix does

Preconditions