Axios multipart header injection CVE-2026-42037 prompts incident response checklist

A CRLF injection in Axios multipart handling

A checklist published on dev.to walks incident response teams through CVE-2026-42037, a header injection flaw in Axios, the widely used JavaScript HTTP library. According to the article, the defect affects Axios versions 1.0.0 through releases before 1.15.1 and lets carriage returns and line feeds embedded in untrusted file metadata survive into the headers of multipart form parts. The flaw is classified as CWE-93 with a CVSS 3.1 score of 5.3. The underlying GitHub advisory, GHSA-445q-vr5w-6q77, includes a proof of concept; CISA enrichment tags exploitation at the poc stage and marks the issue as not automatable. The author found no KEV entry and no verified active exploitation, and cites a ZoomEye query returning 5,548,145 Node.js fingerprints but zero matches on the CVE filter — numbers presented as background, not as a measure of affected deployments.

The response, as the article frames it, turns on three questions answered in order: was an affected Axios build actually running, did untrusted Blob or File metadata reach that code, and did a downstream parser act on an injected header? A package alert by itself answers none of them.

Evidence gathering comes first

Teams should start by mapping upload routes that pass Blob or File-like values through Axios FormData. Within the retention window, the article recommends collecting per-request metadata: timestamp, route, authentication state, source address, declared MIME type, filename, downstream service, response status and parser errors. File contents should be captured only where policy and legal review allow.

Deployment facts matter as much as traffic data: the exact package version, image digest and build time per route. Because a proxy logging only the outer HTTP headers can miss an injected part line entirely, the author advises pulling receiver-side parser logs and application serialization diagnostics, plus the multipart boundary and part-header representation where available.

Reproduce against your own build

Testing, the article insists, belongs in a controlled environment against the organization's own deployment — never third parties or production systems. The procedure uses the deployed Axios version, a synthetic Blob-like value and a local receiver to check whether CR and LF survive into a part header. Repeating the test on Axios 1.15.1 or later, with the application's validation layer enabled, separates a vulnerable build from a patched one without creating external side effects.

When a malformed request counts as exploitation

The advisory's potential consequences include bypassing Content-Type-based filters, parser confusion and the appearance of unexpected form fields. Responders are told to search receiver logs for surprise part headers, malformed multipart requests and mismatches between the uploaded type and the type that drove a downstream decision — then establish what the downstream service actually did: rejected the request, stored it, routed it onward, or used it for an access decision.

Exploitation claims need a complete chain, the author argues: attacker control, vulnerable code, a parser reaction and a consequential outcome. A parser error with no follow-on action is not a filter bypass, and negative findings deserve the same documentation as positive ones.

Patching and interim mitigations

The fix is an upgrade to Axios 1.15.1 or later plus a rebuild of affected artifacts. Release notes cited in the article describe stripping CRLF from multipart headers, and pull request #10758 documents removing CR and LF from Blob.type, tightening default handling and adjusting filename encoding.

Where an immediate upgrade is impossible, the article suggests rejecting CR and LF in MIME values and filenames at the upload boundary, substituting an allowlisted internal type where the expected format set is known, and validating on the receiver rather than trusting part metadata for security decisions. Credentials should be rotated only if evidence shows data or request integrity was affected: the advisory scores low integrity impact with no confidentiality or availability impact, but a downstream parser could change the real consequence.

Closing the investigation means documenting affected services, versions, reachable routes, logs reviewed and downstream outcomes, verifying the production version after deployment, and adding regression tests for CR, LF and CRLF in Blob type while keeping a valid-MIME test in place. The final check: would a new malformed request now be rejected before it enters multipart syntax? If that answer remains theoretical, the incident record should say so.

Why it matters

Axios is one of the most widely used HTTP clients in the JavaScript ecosystem, so a flaw spanning versions 1.0.0 to just before 1.15.1 has a long exposure tail. The checklist's real value is procedural: it converts a CVE alert into a verifiable decision path — confirm the deployed version, prove whether metadata reached the vulnerable code, establish whether a parser acted on it — before escalating containment. It also models discipline around severity scores: a moderate 5.3 says little about what a Content-Type filter bypass could do inside a specific pipeline. For any team that lets client-supplied MIME types influence a security decision, the lesson generalizes beyond this one library: validate that metadata on the receiving side, patched or not.