CVE-2026-42037: CRLF Injection in Axios Multipart Form Data Generation

The vulnerability, identified as CVE-2026-42037, resides in the popular axios HTTP client library when utilized within a Node.js environment. Specifically, the flaw affects the logic responsible for generating multipart/form-data payloads, a standard format for transmitting files and complex data structures over HTTP.

The core issue is a CWE-93 (Improper Neutralization of CRLF Sequences) vulnerability. When constructing the sub-headers for individual parts of a multipart message, axios extracts metadata from the input objects. If the input contains a Blob or File-like object, the library retrieves its .type property to specify the MIME type of the payload.

Because this property is processed without sanitization, an attacker can supply a crafted .type string containing carriage return and line feed (CRLF) characters. These characters serve as structural delimiters in the HTTP protocol. Injecting them allows the attacker to alter the intended structure of the multipart payload, leading to header injection within the request body.

The flaw is located in the FormDataPart constructor within lib/helpers/formDataToStream.js. During the construction of a multipart/form-data request, axios iterates over the entries provided in the user-supplied FormData object. The library dynamically builds the headers for each part before appending the actual data.

The vulnerability stems from the use of raw string concatenation to build these headers. The code accesses the .type property of a Blob or File object and appends it directly to the Content-Type definition. The lack of input validation or encoding means any control characters present in the .type string are passed unmodified into the final stream.

This behavior circumvents the native CRLF injection protections introduced in Node.js version 18. The built-in Node.js mitigations target the primary HTTP request headers passed to functions like http.request(). Because the axios multipart construction occurs entirely within the request payload, the underlying Node.js http module treats the generated boundaries and sub-headers as opaque body data, performing no sanitization.

Prior to the patch, the vulnerable logic in lib/helpers/formDataToStream.js constructed the part headers using direct interpolation. The code assumed the .type property would only contain standard MIME type identifiers.

// Vulnerable Implementation
let headers = 'Content-Disposition: form-data; name="' + key + '"';
if (filename) {
  headers += '; filename="' + filename + '"';
}
headers += CRLF;
// The value.type is concatenated directly with a trailing CRLF
headers += 'Content-Type: ' + (value.type || 'application/octet-stream') + CRLF;

The fix introduced in version 1.15.1 implements a sanitization function to strip newline and carriage return characters from the input. This prevents the attacker from prematurely terminating the header section.

// Patched Implementation
// A helper function strips CRLF sequences globally
const sanitize = (str) => str ? str.replace(/[\r\n]/g, '') : '';
 
let headers = 'Content-Disposition: form-data; name="' + sanitize(key) + '"';
if (filename) {
  headers += '; filename="' + sanitize(filename) + '"';
}
headers += CRLF;
// The value.type is explicitly sanitized before concatenation
headers += 'Content-Type: ' + (sanitize(value.type) || 'application/octet-stream') + CRLF;

Exploitation requires an architecture where a server-side Node.js application uses axios to proxy or forward user-supplied files to another endpoint. The attacker must have control over the MIME type attribute of the uploaded file.

The attacker constructs a malicious payload by appending \r\n to the expected MIME type, followed by arbitrary HTTP headers. If the attacker wishes to manipulate the body of the specific multipart section, they inject an additional \r\n to complete the header block.

A proof-of-concept payload sets the .type property to image/jpeg\r\nInjected-Header: malicious-value\r\n\r\n[Malicious Content]. When processed by the vulnerable axios version, the resulting multipart segment includes the injected header and alters the payload content boundary. The target backend parsing this multipart stream interprets the injected values as legitimate sub-headers.

The vulnerability holds a CVSS v3.1 score of 5.3 (Medium), reflecting its limited scope but high exploitability under specific conditions. The attack vector is strictly bounded by the multipart/form-data payload structure, meaning attackers cannot inject headers into the main HTTP envelope, only into the sub-headers of the specific file part.

While this limitation prevents classic HTTP request smuggling attacks against edge proxies, it enables targeted attacks against internal APIs and parsers. If the downstream service relies on the integrity of the multipart sub-headers for authentication, routing, or processing logic, the attacker can bypass these controls.

The impact on confidentiality, integrity, and availability remains context-dependent. In a typical scenario, the attacker gains low-level integrity modification capabilities over the internal request structure. Exploitation does not result in direct remote code execution or data exfiltration without chaining with a secondary vulnerability in the target backend's multipart parsing logic.

The primary remediation strategy is upgrading the axios dependency to version 1.15.1 or later. This version implements strict CRLF stripping on both the .type and .name properties during multipart form generation.

For environments where immediate upgrading is not feasible, developers must implement strict input validation on all file uploads. This involves verifying the user-provided MIME type against an allowlist of expected formats (e.g., image/jpeg, application/pdf) before passing the object to axios.

Security teams should review server-side proxy implementations to ensure untrusted metadata is not blindly trusted. Relying on client-provided MIME types is a known anti-pattern; applications should ideally infer file types using magic bytes or server-side analysis rather than trusting the user-supplied .type property.