CVE-2025-58754

What it actually does

In Node.js applications using Axios, requests to a URL beginning with the data: scheme are handled differently from normal HTTP(S) requests. Instead of making a network request, Axios decodes the entire data URI payload into memory and returns a synthetic successful response. The vulnerable code path does not enforce maxContentLength or maxBodyLength, and responseType: "stream" does not prevent full in-memory allocation. If attacker-controlled input can reach an Axios request URL, a sufficiently large data: URI can force excessive Buffer or Blob allocation, exhaust the Node.js heap or process memory, and crash the application process. The impact is denial of service rather than code execution or data theft.

Why it matters to the business

Applications that accept user-supplied URLs, webhooks, import sources, preview links, integrations, or server-side fetch targets may be vulnerable to remote application crashes if those inputs are passed to Axios in Node.js. Successful exploitation can interrupt customer-facing services, background workers, API gateways, ingestion jobs, or automation pipelines. The CVSS score indicates high availability impact, but the EPSS score is currently low and the issue is not listed in CISA KEV, so broad active exploitation is not indicated from the supplied data. Because Axios is widely used across JavaScript services, organizations should still prioritize dependency inventory and patching for externally reachable URL-fetching workflows.

How an attack unfolds

An attacker first identifies an application feature that causes a server-side Node.js process to fetch a URL using Axios, such as link preview generation, webhook validation, file import, image retrieval, feed ingestion, or integration callbacks. The attacker supplies a data: URI instead of an http: or https: URL. When Axios processes that input with its Node adapter, it treats the data URI as a local decodable payload, expands the encoded content into memory, and returns a synthetic 200 response rather than enforcing the usual HTTP response size limits. By making the data URI very large or sending repeated requests, the attacker causes memory pressure until the Node.js process terminates due to heap exhaustion, out-of-memory killing, container restart, or service supervisor restart. No authentication bypass or network callback from the victim is required if the vulnerable URL-fetching feature is reachable by the attacker.

How to fix it

Upgrade Axios to a fixed release that includes the upstream fix corresponding to git commit 0d8ad6e1de0f5339e02bc262d6f0df4936974120, or to the latest patched Axios version available for the package manager in use. Regenerate lockfiles and redeploy all affected Node.js services, including transitive dependency consumers where Axios is bundled or vendored. As a defense-in-depth mitigation, reject non-network schemes before calling Axios: allow only http: and https: unless another scheme is explicitly required. Do not rely only on maxContentLength, maxBodyLength, or responseType: "stream" for protection against data: URIs in vulnerable versions. Add request-level input validation, maximum URL length checks, request body limits, authentication or authorization on URL-fetching features, per-client rate limits, worker isolation, memory limits, and automatic restart policies. Where possible, centralize outbound-fetch helpers so protocol allowlisting and size controls are applied consistently across services.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles no longer resolve to a vulnerable Axios version and that the installed source contains the fix associated with commit 0d8ad6e1de0f5339e02bc262d6f0df4936974120 or a later upstream patch. Use software composition analysis, npm/yarn/pnpm lockfile review, and container image scanning to verify all deployed artifacts. Functionally test URL-ingestion features with benign small data: URIs and confirm they are rejected before Axios is invoked unless explicitly required. Test oversized URL handling in a controlled non-production environment and confirm the application returns a validation error without a process restart, heap exhaustion, or synthetic Axios 200 response. Review telemetry after deployment for absence of Node.js out-of-memory crashes associated with URL-fetching endpoints.

Typical attack path

1. Find a Node.js application endpoint or workflow that accepts a URL or URI from an external user or integration.
2. Confirm the server-side code attempts to retrieve that supplied URL using Axios.
3. Submit a data: URI rather than an http:// or https:// URL.
4. Use an oversized encoded data URI or repeated submissions to force Axios to decode the payload into memory.
5. Trigger Node.js heap exhaustion, process crash, container restart, or degraded service availability.
6. Repeat requests as needed to sustain denial of service until input validation, rate limiting, or patching is applied.

How to detect it

Review logs for evidence that attacker-controlled URL fields contained data: URIs, especially unusually long values, base64-encoded payloads, or repeated submissions from the same source. Useful sources include application request logs, API gateway logs, reverse proxy logs, WAF logs, APM traces, structured application logs around outbound fetch operations, Node.js stderr/stdout, process supervisor logs, container runtime events, Kubernetes pod events, and host OOM killer logs. Look for temporal correlation between data: URI submissions and symptoms such as HTTP 500/502/503 responses, process restarts, container OOMKilled events, Node.js fatal heap errors, sharp memory growth, or degraded worker availability. Because exploitation does not require a successful external network connection, network egress logs may show little or nothing. Focus detection on inbound parameters or JSON fields that carry URLs, application exceptions around Axios calls, and memory-related termination artifacts. No specific threat actors or ransomware campaigns are indicated in the supplied data.

• data:
• data:text/plain
• data:application/octet-stream
• data:;base64,
• data:text/plain;base64,
• data:application/octet-stream;base64,
• axios
• maxContentLength
• maxBodyLength
• responseType: 'stream'
• responseType: "stream"
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• ENOMEM
• process out of memory
• OOMKilled
• Killed process
• Out of memory: Killed process
• node --max-old-space-size
• RangeError: Invalid string length

What your security team should do

• Inventory Node.js services, serverless functions, workers, and containers that include Axios, prioritizing externally reachable features that fetch user-supplied URLs.
• Upgrade Axios to a patched version containing the fix for commit 0d8ad6e1de0f5339e02bc262d6f0df4936974120 and redeploy rebuilt artifacts from clean lockfiles.
• Implement strict URL scheme allowlisting so only http: and https: are accepted for server-side fetch operations unless a business requirement explicitly justifies another scheme.
• Add URL length limits, payload limits, rate limits, and authentication controls around URL-submission, import, webhook, and link-preview features.
• Search historical application, reverse proxy, API gateway, and APM logs for data: URI submissions and Node.js memory-exhaustion events.
• Create SIEM detections for data: schemes in URL parameters or JSON fields sent to URL-fetching endpoints, especially followed by process crashes or container restarts.
• Monitor for repeated 5xx responses, Kubernetes OOMKilled events, Node.js heap errors, and abnormal memory growth in services that perform outbound fetches.
• Document and standardize a safe outbound HTTP client wrapper that blocks dangerous schemes before passing input to Axios or any other fetch library.