CVE-2025-58754: Axios Data URI DoS and How to Safely Upgrade

Axios’s Node.js adapter will happily decode arbitrarily large data: URIs into memory, bypassing configured size limits and giving attackers an easy way to crash processes — a denial‑of‑service weakness tracked as CVE‑2025‑58754 that has been fixed in recent releases but remains a high‑risk issue for any application that forwards untrusted URLs to Axios.

Background​

Axios is one of the most widely used HTTP clients in the JavaScript ecosystem. Its Node.js adapter provides convenience features — including support for non‑HTTP schemes such as data: URIs — but that convenience is what created the risk in CVE‑2025‑58754. When given a data: URL in affected releases, Axios decodes the entire Base64 payload into a Buffer/Blob and returns a synthetic 200 response without applying the usual protections (maxContentLength / maxBodyLength). That decoding happens in process memory and is not streamed; a sufficiently large payload can therefore exhaust available memory and crash or hang the process.
This is not a hypothetical edge case: many applications accept or forward user‑supplied URLs, and serverless or containerized environments typically allocate only modest memory — making them particularly fragile in the face of unbounded allocations. The vulnerability was publicly disclosed in September 2025 and is tracked as CVE‑2025‑58754. Official advisories and vulnerability databases assign it a High severity (CVSS ≈ 7.5).

---

What exactly is wrong — technical overview​

The data: URI handling path​

• Axios’s Node http adapter recognizes URLs that begin with the data: scheme and, instead of issuing a real network call, calls an internal decoder (commonly referenced as fromDataURI()) that decodes the Base64 payload into a full in‑memory buffer or a Blob.
• Because this code path synthesizes a response locally, it does not engage the same response stream handling used for network responses. As a result, the normal runtime checks that enforce maxContentLength and maxBodyLength are skipped. Attackers can therefore supply a huge Base64 payload and force the application to allocate memory far beyond configured limits.

Why responseType: 'stream' does not help​

Many developers assume that using streaming semantics prevents OOM risks. In this case, however, the synthetic response is produced as a complete Buffer before any streaming hooks are applied, so asking for a stream does not prevent the in‑memory allocation. That surprising divergence between developer expectations and library behavior is a big part of why this class of bug is dangerous.

Affected and patched versions — what to upgrade to​

Different tracking sources list affected version ranges in slightly different ways, but the practical, conservative guidance is clear: upgrade any Axios install to a patched release. The maintainer changelog and official advisory indicate the fix landed in the 1.12.0 release (and in the 0.30.x line starting at 0.30.2), where a patch enforces maxContentLength for data: URLs or rejects data: URLs outright. If you are running any 1.x release prior to 1.12.0 or a 0.30.x release prior to 0.30.2, plan to upgrade.
Note: public trackers sometimes present the lower bound or exact affected minimum differently (for example, some sources call out "starting at 0.28.0" or list "<1.11.0"); treat those differences as metadata of the advisories and rely on the maintainer’s patch release identifiers as the authoritative remediation points.

---

Impact and threat scenarios​

Real‑world consequences​

• Total loss of availability for the affected process: a single crafted request can cause Node.js to exhaust memory, crash, or hang, denying service to legitimate users.
• Persistent or repeated outages: attackers who can repeatedly send longs data: URIs can maintain sustained outages or cause repeated restarts that destabilize dependent systems.
• Cloud and serverless pain: cloud functions and containers commonly run with constrained memory budgets; an OOM triggered by one request can lead to cascade effects or exhausted instance pools.

How an attacker may reach your code​

• Direct user input: any web endpoint that accepts a URL and passes it into Axios (for download, retrieval, or content‑fetch workflows) is an obvious vector.
• Proxy functionality: applications that accept a "resource" URL and fetch it on behalf of a user are particularly vulnerable, because they act as universal fetchers of arbitrary URLs.
• Internal automation: background jobs or ETL processes that accept external feeds or metadata specifying data: URIs can be coerced into decoding enormous payloads.

Because the exploit requires only a crafted data: URI (no authentication, no special privileges), risk is significant wherever Axios processes untrusted URLs. Several independent vulnerability databases and advisories make this threat model explicit.

---

How to detect and triage exploitation​

Leading indicators​

• Sudden, unexplained memory growth on servers that use Axios for URL retrieval.
• Node.js processes that repeatedly OOM or are killed by the runtime OOM killer.
• Frequent restarts of instances behind an autoscaler with progressively higher error rates.
• Application logs that show synthetic 200 responses for requests that you know were intended to be network fetches (the presence of a synthetic response for a data: URL may be evident in debug logs).

Practical detection steps​

• Instrument memory metrics (process.memoryUsage()) and set alerts for rapid escalations in RSS or heap usage.
• Search centralized logs for accesses to URLs that start with data: or for unusual long request‑parameter lengths.
• Audit code paths that accept URLs and confirm whether user input is forwarded to Axios without sanitization. Use automated scanning tools (SCA) to find packages and versions in your dependency graph.

Incident triage checklist​

• If you observe an OOM: take an immediate snapshot of process memory usage and the recent request payloads; quarantining the host or scaling down autoscaling groups may limit blast radius.
• Block or rate‑limit inbound requests containing data: schemes at the application firewall or web server while you patch.
• Roll forward to the patched Axios release in a canary environment and validate that memory behavior is restored before wide deployment.

---

Mitigation and remediation — short and long term​

Immediate actions (minutes to a few hours)​

• Prevent exposure: refuse or sanitize any external input that contains data: URIs before passing it into Axios. A simple guard in your URL handling layer that rejects URLs beginning with data: will stop the attack vector at the perimeter.
• Apply temporary validation: if you must accept data: URIs for business reasons, perform a pre‑decode size check on the Base64 payload and reject any payload larger than a safe threshold (for example, 100 KB to 1 MB depending on your system). This prevents unbounded allocation before Axios sees the content.

Example pre‑check (conceptual):

• If url startsWith('data:') then
• extract the Base64 section after the comma
• if base64String.length > MAX_ALLOWED_BASE64_CHARS then reject request
• else continue with decode

(Implement this in the language layer calling Axios — do not rely on Axios to protect you in unpatched versions.)

Recommended urgent patching​

• Upgrade Axios to a patched release: at minimum, install 1.12.0 (or a newer 1.x) or 0.30.2 (or newer 0.30.x) where the maintainer added explicit enforcement or rejection for data: URLs. Confirm the exact release in your environment and upgrade consistently across services.
• Rebuild containers and redeploy: for containerized or serverless workloads, the patch only helps once the image or function runtime uses the updated Axios artifact. Ensure CI pipelines produce images that contain the new library version.

Longer‑term controls (days to weeks)​

• Centralize URL handling: avoid letting arbitrary code paths call Axios directly with user‑supplied URLs. Instead, funnel external URLs through a small, audited utility that enforces strict validation and size checks.
• Use a custom Axios adapter: where you must accept data: URIs, consider a custom adapter that decodes input as a stream with hard upper limits or that uses a streaming Base64 decoder which can be aborted on overflow.
• Harden CI: treat this vulnerability as a reminder to run SCA (software composition analysis) and version pinning in CI, ensure SBOMs are available, and include Axios in dependency monitoring.

---

Operational checklist for teams​

• 1.) Inventory: run npm ls axios and scan package-lock / yarn.lock to find every project and container image that references Axios. Flag all projects referencing versions <1.12.0 or <0.30.2.
• 2.) Patch: upgrade to Axios 1.12.0 or later, rebuild images, and deploy through canary gates.
• 3.) Perimeter hardening: block or normalize data: URIs at web application firewalls and API gateways.
• 4.) Alerting: add temporary alerts for process memory growth and increased crash rates tied to services that use Axios.
• 5.) Post‑mortem: if you experienced downtime, capture the request that triggered it, confirm the remediation, and codify the PSA into your developer guidelines.

---

Why this class of bug keeps happening — critical analysis​

Convenience vs. safety tradeoffs​

Open‑source libraries often add convenience paths for lesser‑used features (like supporting data: URIs) to broaden utility. But convenience can create bypasses of obvious safety checks; in this case, Axios’s in‑process decoder created a parallel execution path that skipped the safeguards developers rely on for network streams. That divergence between developer expectation and internal implementation is thecom]

Maintainer response and the patch​

Axios’s maintainers addressed the issue by adding enforcement in the Node adapter and releasing patched versions. The fix landed as a short, surgical change — either rejecting data: URIs by default or applying maxContentLength for them — which is appropriate given the severity and the small surface area of the problem. The release notes and the PR history show a quick correction (PR #7011). This is an example of responsible open‑source maintenance: disclosure, fix, and release.

Residual risk and supply chain complexity​

• Transitive dependencies and downstream packages often vendor or pin Axios at older versions; scanning your dependency tree is essential because a direct npm ls axios in one app does not show Axios copies embedded in subpackages or other services.
• Binary artifacts: older Docker images or serverless layers that were built prior to the fix may remain in production long after code is patched. Image rebuilds and redeployments are necessary to ensure the patch truly reaches runtime.

---

Parallels and precedent​

Unbounded decoding and improper size checks are a recurring category of DoS vulnerabilities across ecosystems. For example, a recently tracked Python HTTP client weakness (CVE‑2025‑13836) allowed remote actors to force a Python process to allocate huge amounts of memory by abusing Content‑Length handling — the mechanics and operational impact are analogous: unexpected, unchecked inputs cause memory exhaustion and service failure. That prior incident underscores that the Axios problem is part of a broader pattern: whenever libraries add alternate I/O paths (synthetic responses, in‑process decoders), those paths must receive the same resource‑protection scrutiny as canonical network streams.

---

Concrete developer guidance (code and patterns)​

Example guard (pseudo‑JavaScript)​

• Before calling Axios, apply a simple check for data: URIs:
• if (url.startsWith('data:')) {
• const base64 = url.split(',')[1] || '';
• if (base64.length > MAX_BASE64_CHARS) throw new Error('Data URI too large');
• // Optionally: reject data: URIs entirely if not needed
• throw new Error('Data URIs are disallowed');
• }

This check prevents decoding of massive payloads before they reach Axios. For environments where data: URIs are necessary, implement streaming Base64 decoders with hard cutoffs and process the payload incrementally.

When to use a custom adapter​

If your application legitimately consumes data: URIs (for example, small inline images uploaded by authenticated users), build a thin, audited adapter:

• Decode incrementally — process chunks rather than calling a one‑shot decode into Buffer.
• Enforce strict configurable thresholds (e.g., 512 KB) and fail fast.
• Log and alert when thresholds are hit.

A custom adapter gives you control over resource boundaries in a way that a generic library may not.

---

Governance and risk reduction​

• Treat dependency updates as security events: adopt a formal cadence for patching widely used libraries like Axios and bake dependency updates into sprint planning.
• Use SBOM tooling and SCA to continuously monitor for new advisories.
• Ensure CI pipelines produce immutable artifacts and that images are rebuilt and redeployed after security dependency changes.
• Add library behavior tests that model resource limits — e.g., include regression tests that verify maxContentLength or that data: URIs are rejected — so future changes cannot reintroduce the problem silently.

---

Final assessment​

CVE‑2025‑58754 is a textbook example of a vulnerability born from a secondary code path that escaped the protections placed on the primary flow. The impact is practical and immediate — an attacker with the ability to influence URL inputs can force memory exhaustion in Node.js, producing DoS at scale. The fix is straightforward and available: upgrade to the patched Axios releases (1.12.0+ or 0.30.2+), apply perimeter validation, and rebuild runtime images.
That said, the operational burden is nontrivial: organizations must find every place Axios is used, rebuild images and serverless layers, and validate that no older artifacts remain in production. The incident also reinforces a broader lesson: convenience features that perform in‑process decoding or synthetic responses must be treated with the same defensive engineering discipline as network I/O.

---

CVE‑2025‑58754 is remediated in the library, but the real work for operators and developers remains ongoing: inventory, upgrade, harden, and test. Do not assume “minor library dependency” equals “low priority” — when a single decoded string can take down a process, that minor dependency becomes a major operational risk.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center