CVE-2026-12143

What it actually does

The flaw is a CRLF injection issue in the Node.js form-data library. When an application passes attacker-controlled values into FormData#append as the multipart field name or filename, affected versions concatenate those values directly into the Content-Disposition header without escaping carriage return, line feed, or double-quote characters. An attacker can break out of the intended header context, inject additional multipart headers, or create additional multipart body parts. Downstream services that parse the forwarded multipart request may then see attacker-supplied fields that the upstream application did not intend to send, potentially allowing data integrity impact such as overriding business parameters, injecting hidden form fields, or changing authorization-relevant values interpreted by backend logic.

Why it matters to the business

Applications that transform user input into multipart requests may unintentionally let an external user alter fields sent to backend services. The most serious business risk is unauthorized manipulation of workflow inputs, such as changing flags, metadata, document attributes, or approval-related fields processed by downstream systems. The issue is not known to be in CISA KEV and has low current EPSS probability, but it is easy to exploit where the vulnerable usage pattern exists and the package is widely used in JavaScript ecosystems, so remediation should be prioritized for internet-facing gateways, upload services, API brokers, and services that build multipart requests from user-controlled JSON keys or filenames.

How an attack unfolds

An attacker first identifies an endpoint that accepts user-controlled field names, object keys, upload filenames, or metadata that the application later forwards using the form-data library. The attacker supplies a value containing carriage return and line feed sequences and carefully crafted multipart syntax. In affected versions, the library places this value verbatim into the Content-Disposition header. The injected CRLF sequence terminates the original header, and the attacker adds new headers or starts a new multipart part with attacker-chosen content. When the receiving backend parses the multipart request, it may treat the injected content as legitimate form fields. If the backend trusts those fields for authorization, routing, pricing, account attributes, processing decisions, or validation bypasses, the attacker can alter backend behavior without needing credentials or user interaction.

How to fix it

Upgrade form-data to a fixed release: 2.5.6, 3.0.5, or 4.0.6 or later, depending on the major version in use. Rebuild and redeploy applications after dependency updates, including transitive dependency refreshes where form-data is pulled in through other packages. If immediate upgrade is not possible, prevent untrusted input from being used as multipart field names or filenames, allowlist permitted field names, normalize filenames to a safe basename, and reject or encode CR, LF, and double-quote characters before constructing multipart requests. Review API gateway, upload, proxy, and integration code that converts arbitrary JSON keys or client-provided metadata into multipart fields, because applications using only fixed trusted field names are not affected by the vulnerable code path.

How to confirm the fix worked

Confirm package resolution shows only fixed form-data versions: 2.5.6, 3.0.5, 4.0.6, or later. Use npm, yarn, pnpm, lockfiles, SBOMs, and container image scans to identify both direct and transitive copies. Add a regression test that attempts to append a field name and filename containing CR, LF, and double quotes, then verifies the serialized multipart body encodes them as %0D, %0A, and %22 rather than producing additional headers or parts. For exposed services, test that inputs containing CRLF sequences in field names, filenames, or metadata are rejected, normalized, or safely encoded before any outbound multipart request is generated.

Typical attack path

1. Find an application endpoint that accepts field names, JSON object keys, upload filenames, or metadata from an untrusted client.
2. Confirm that the application constructs outbound multipart/form-data requests using the form-data library and attacker-controlled values are used as field names or filenames.
3. Submit input containing CRLF characters and multipart boundary/header syntax intended to terminate the Content-Disposition header.
4. Cause the vulnerable library to serialize the malicious field name or filename verbatim into the multipart request.
5. Have the downstream backend parse the injected header or additional multipart part as legitimate request data.
6. Abuse the injected or overridden field values to change backend processing decisions, such as adding hidden parameters or overriding security-sensitive form fields.

How to detect it

Look for evidence of CRLF or multipart injection attempts in web access logs, API gateway logs, application logs, upload service logs, and reverse proxy logs. Focus on requests where user-controlled field names, JSON object keys, filenames, or metadata contain encoded or literal carriage return and line feed sequences, double quotes inside field identifiers, repeated Content-Disposition headers, unexpected Content-Type headers inside form fields, or multipart boundary strings appearing inside parameter values. Review backend application logs for unexpected or duplicate form fields, especially security-sensitive names such as is_admin, role, admin, permissions, price, amount, status, owner, tenant, or account attributes. If outbound request logging is available, compare the upstream client request with the multipart request sent to downstream services and look for additional multipart parts that were not generated by normal application logic. Because exploitation depends heavily on application-specific field handling, absence of generic indicators does not prove the vulnerability was not targeted.

• %0d%0aContent-Disposition:
• %0D%0AContent-Disposition:
• %0d%0aContent-Type:
• %0D%0AContent-Type:
• \r\nContent-Disposition:
• \r\nContent-Type:
• name="is_admin"
• name="admin"
• name="role"
• filename="%0d%0a
• filename="%0D%0A
• filename="\r\n
• Content-Disposition: form-data; name="
• --form-data-boundary
• multipart/form-data; boundary=

What your security team should do

• Inventory all applications and containers that include the form-data package, including transitive dependencies in JavaScript lockfiles and SBOMs.
• Prioritize remediation for internet-facing upload handlers, API gateways, webhooks, proxy services, and integrations that build multipart/form-data requests from user-controlled input.
• Upgrade to form-data 2.5.6, 3.0.5, or 4.0.6 or later and redeploy affected services.
• Search code for FormData#append usage where the first argument or filename option is derived from request bodies, JSON keys, headers, query parameters, uploaded filenames, or external metadata.
• Add allowlists for multipart field names and sanitize filenames before passing them to multipart serialization libraries.
• Add tests and WAF/API validation rules to block or flag CRLF characters and multipart boundary strings in field names, filenames, and metadata parameters.
• Review backend services for trust assumptions around hidden form fields or security-sensitive multipart parameters that could be overridden by an upstream request.