Cloudanix VulnDB

CVE-2026-42037

Medium · 5.3

CVSS

5.3

EPSS

0.3%

Published

Apr 24, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A widely used web request library could let a malicious upload change how another service interprets the uploaded file.

Chainable
Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Tampering
Component
Library
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Axios versions 1.0.0 through 1.15.0 fail to sanitize carriage return and line feed characters in the type property of Blob/File-like values when constructing multipart/form-data request bodies in Node.js. If attacker-controlled input is passed into Axios as a file or Blob-like object, the attacker can inject additional MIME part headers into the multipart body. This does not inject top-level HTTP headers, so Node.js HTTP header protections do not block it. The practical impact is integrity-related: downstream services that parse multipart bodies may receive attacker-influenced part metadata, altered headers, or smuggled form semantics.

Why it matters to the business

Systems that proxy or submit user-controlled file uploads with vulnerable Axios versions may send manipulated multipart requests to internal or third-party services. This can cause validation bypass, incorrect processing of uploaded content, metadata spoofing, or unintended actions in workflows that trust multipart fields and headers. The CVSS score is moderate, EPSS is currently low, it is not listed in CISA KEV, and no exploit maturity is reported, but the issue affects a widely used HTTP client library and has been public for over 100 days, so routine dependency patching should prioritize it where Axios handles untrusted uploads.

How an attack unfolds

An attacker targets an application or service that accepts user-controlled file-like input and forwards it using Axios multipart/form-data in Node.js. The attacker supplies or influences a Blob/File-like object whose type property contains CRLF sequences followed by attacker-chosen MIME part headers. When vulnerable Axios serializes the object, it writes the unsanitized type value into the Content-Type line of the multipart part. The CRLF characters terminate the original header line and cause the attacker-supplied text to be interpreted as additional multipart headers or altered multipart structure by the downstream receiver. If the receiving service trusts multipart headers or uses them for validation, routing, parsing, or authorization-sensitive processing, the attacker may bypass checks or manipulate how the upload is handled.

How to fix it

Upgrade Axios to version 1.15.1 or later wherever Axios is used to construct multipart/form-data from user-controlled data. If immediate upgrade is not possible, prevent untrusted code or user input from controlling Blob/File type values, reject MIME type values containing CR or LF characters, and normalize upload metadata before passing it to Axios. Add server-side validation that MIME types match a strict allowlist such as image/png or application/pdf and reject any value containing control characters. Do not rely only on Node.js HTTP header validation, because this issue affects the multipart body rather than top-level HTTP headers.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve Axios to 1.15.1 or later. Inspect package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls axios, or equivalent software composition analysis output for vulnerable Axios versions from 1.0.0 through 1.15.0. Exercise upload/proxy paths with a benign test MIME type containing encoded CRLF characters and verify that the application rejects the value or that the generated multipart body does not contain injected extra part headers. Validate both direct and transitive Axios usage, especially in Node.js services that forward user uploads to APIs.

Typical attack path

  1. Identify an application endpoint or service path that accepts uploads or file-like data and forwards them using Axios multipart/form-data.
  2. Determine whether the application permits attacker influence over a Blob/File-like object's type property, MIME type metadata, or equivalent upload metadata.
  3. Craft a type value containing CRLF characters followed by injected multipart header lines.
  4. Submit the malicious upload or file-like payload to the vulnerable application.
  5. Vulnerable Axios serializes the multipart body and embeds the unsanitized type value into the part's Content-Type header.
  6. The downstream service parses the injected multipart headers or altered part metadata.
  7. Abuse the downstream service behavior to bypass validation, spoof metadata, or influence request processing.

How to detect it

To determine whether exploitation may already have occurred, focus on services that accepted user uploads and forwarded them with Axios multipart/form-data. Review application logs, upload metadata logs, API gateway logs, reverse proxy logs with request body capture, downstream multipart parser logs, object storage metadata, and error logs from services receiving forwarded uploads. Look for MIME type values containing CR or LF characters, unexpected multipart part headers, duplicate or conflicting Content-Disposition or Content-Type headers inside a single part, unexpected form field names created during upload forwarding, and parsing errors around multipart boundaries. If request bodies are not logged, review downstream effects such as rejected uploads, anomalous content classification, unexpected metadata values, or audit events showing fields that should not have been user-controllable. Also perform exposure detection by searching dependency manifests and lockfiles for Axios versions 1.0.0 through 1.15.0.

  • axios@1.0.0
  • axios@1.1.
  • axios@1.2.
  • axios@1.3.
  • axios@1.4.
  • axios@1.5.
  • axios@1.6.
  • axios@1.7.
  • axios@1.8.
  • axios@1.9.
  • axios@1.10.
  • axios@1.11.
  • axios@1.12.
  • axios@1.13.
  • axios@1.14.
  • axios@1.15.0
  • lib/helpers/formDataToStream.js
  • FormDataPart
  • Content-Type: image/png\r\n
  • Content-Type: application/octet-stream\r\n
  • Content-Disposition: form-data; name=
  • Content-Transfer-Encoding:
  • multipart/form-data; boundary=

What your security team should do

  • Inventory all applications and services using Axios, including transitive dependencies and bundled Node.js services.
  • Prioritize upgrades to Axios 1.15.1 or later for services that handle user-supplied uploads, proxy multipart requests, or forward files to internal or third-party APIs.
  • Add input validation that rejects CR, LF, and other control characters in MIME type and upload metadata fields.
  • Review downstream services that consume multipart uploads and ensure they do not make trust decisions solely from client-supplied multipart part headers.
  • Add regression tests that serialize multipart/form-data with hostile MIME type metadata and confirm header injection is not possible.
  • Enable dependency scanning policies to flag Axios versions 1.0.0 through 1.15.0 until all deployments are remediated.
  • Review application and API logs for anomalous multipart requests if vulnerable services accepted untrusted uploads before patching.

The record

Axios is a promise based HTTP client for the browser and Node.js. From 1.0.0 to before 1.15.1, the FormDataPart constructor in lib/helpers/formDataToStream.js interpolates value.type directly into the Content-Type header of each multipart part without sanitizing CRLF (\r\n) sequences. An attacker who controls the .type property of a Blob/File-like object (e.g., via a user-uploaded file in a Node.js proxy service) can inject arbitrary MIME part headers into the multipart form-data body. This bypasses Node.js v18+ built-in header protections because the injection targets the multipart body structure, not HTTP request headers. This vulnerability is fixed in 1.15.1.

Affected packages

Ecosystem Package Introduced Fixed
npm axios 1.0.0 1.15.1

Related vulnerabilities