CVE-2026-12143 — form-data
Fix: form-data/form-data@64190dbCVE-2026-12143 is a CWE-93 vulnerability in form-data. A fix is available for form-data — see the affected versions and patch details below.
form-data does not escape CR/LF/quote in multipart field names and filenames (CRLF injection)
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-12143.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
form-datanpmDescription
Summary
form-data builds multipart/form-data request bodies. Through v4.0.5, the field name passed to FormData#append and the filename option are concatenated directly into the Content-Disposition header with no escaping of CR (\r), LF (\n), or ". An application that uses untrusted input as a field name or filename therefore lets an attacker terminate the header line and either inject additional headers or smuggle whole additional multipart parts into the request the application forwards to a backend.
This is CWE-93 (CRLF injection). It is a divergence from how browsers and the WHATWG HTML spec serialize form-data (they escape these characters), so the fix is to match that behavior. Severity is conditional: it depends on the consuming application passing attacker-controlled data as a field name or filename. Applications that only use fixed/trusted field names are not affected.
Details
In lib/form_data.js, _multiPartHeader builds the part header as:
'Content-Disposition': ['form-data', 'name="' + field + '"'].concat(contentDisposition || [])
and _getContentDisposition builds filename="' + filename + '"'. Neither escapes control characters, so a \r\n in field/filename ends the header line. The same applies to ", which can break out of the quoted parameter.
Proof of concept
const FormData = require('form-data');
const form = new FormData();
form.append('email"\r\nX-Injected: true\r\nfake="', '[email protected]');
console.log(form.getBuffer().toString());
Before the fix this emits an injected X-Injected: true header line. A field name that also includes --<boundary> sequences can introduce additional parts (e.g. an extra name="is_admin" field), which a downstream parser accepts as legitimate.
Impact
For an application that uses untrusted field names/filenames:
- Field injection / override (integrity). Inject or override fields the backend trusts (e.g.
is_admin,role) — the primary demonstrated impact. - Header injection into the generated multipart part.
Claims of guaranteed privilege escalation, authentication bypass, high confidentiality impact, and availability impact are application-dependent downstream consequences, not properties of form-data itself, and are not demonstrated by the PoC.
Severity
The demonstrated, library-attributable impact is integrity (field/header injection); there is no demonstrated confidentiality disclosure or availability impact in form-data itself, and exploitation requires the consuming app to feed untrusted data into field names/filenames. A Moderate (≈5.3, I:L) rating is also defensible given that precondition.
Patch
Fixed in 4.0.6, 3.0.5, and 2.5.6. Users on older 0.x/1.x/2.x releases should upgrade to 2.5.6 or later.
The fix escapes \r, \n, and " as %0D, %0A, and %22 in field names and filenames, matching the WHATWG HTML multipart/form-data encoding algorithm that browsers implement. This neutralizes the injection while leaving ordinary field names (including name[0], dotted, and unicode names) unchanged.
Workaround
Until upgrading, validate or reject field names/filenames that contain control characters before calling append:
if (/[\r\n]/.test(field)) { throw new Error('invalid field name'); }
Credit
Reported by yueyueL.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | form-data | all versions | 2.5.6npm install form-data@2.5.6 |
| 📦npm | form-data | ≥ 3.0.0&&< 3.0.5 | 3.0.5npm install form-data@3.0.5 |
| 📦npm | form-data | ≥ 4.0.0&&< 4.0.6 | 4.0.6npm install form-data@4.0.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for form-data, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update form-data to 2.5.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-12143 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-12143 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-12143. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This is an Important impact flaw in the form-data library: a remote attacker can inject arbitrary headers or additional multipart parts via CRLF injection in field names or filenames, potentially overriding sensitive form fields and affecting data integrity. For RHOAI and RHEL AI, severity is Moderate because affected…
Applications using the `form-data` library should implement strict input validation and sanitization for all field names and filenames derived from untrusted sources. This prevents the injection of control characters (CR, LF, ") that could lead to header injection or form field overrides. Deployments that exclusively use fixed or trusted field names are not impacted.Source: Red Hat security advisory for CVE-2026-12143 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Cryostat 4 on RHEL 9 | cryostat/cryostat-openshift-console-plugin-rhel9:4.2.0-13 | RHSA-2026:48151 |
| Red Hat AMQ Broker 7.13.6 | form-data | RHSA-2026:66545 |
| Red Hat AMQ Broker 7.14.1 | form-data | RHSA-2026:66488 |
| Red Hat Ansible Automation Platform 2.6 for RHEL 9 | automation-platform-ui-0:2.6.13-1.el9ap | RHSA-2026:59136 |
| Red Hat Data Grid 8.6.2 | form-data | RHSA-2026:41951 |
| Red Hat Enterprise Linux 10 | rh-podman-desktop-0:1.1.2-1.el10_2 | RHSA-2026:57590 |
| Cluster Observability Operator 1.5.0 | cluster-observability-operator/distributed-tracing-console-plugin-pf4-rhel9:1782840519 | RHSA-2026:34342 |
| multicluster engine for Kubernetes 2.10 | multicluster-engine/console-mce-rhel9:1787079364 | RHSA-2026:59557 |
Frequently Asked Questions
Is CVE-2026-12143 in your dependencies?
O3 Security finds CVE-2026-12143 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.