How Denial of Service via Unbounded Data Size happens in Node.js (axios) and how to fix it

Introduction

In a Node.js application's package-lock.json, the dependency axios was pinned at version 1.9.0—a version now known to contain CVE-2025-58754, a high-severity Denial of Service vulnerability. The project declared "axios": "^1.4.0" in its package.json, which resolved to 1.9.0 at install time. This version of axios lacks proper data size validation on HTTP responses, meaning any endpoint the application calls (or any response an attacker can influence) could return an unbounded payload that exhausts the Node.js process's memory.

This matters for any developer using axios in server-side Node.js applications—especially those that make outbound HTTP requests to external services, APIs, or user-controlled URLs. If your application fetches data from sources you don't fully control, you're at risk.

The Vulnerability Explained

What's Missing: Data Size Checks

Axios is one of the most popular HTTP clients in the JavaScript ecosystem, used in millions of projects. When axios receives an HTTP response, it buffers the response body into memory. In versions prior to 1.12.0, this buffering happened without enforcing a maximum size limit at the transport layer.

Here's what the vulnerable dependency looked like in package-lock.json:

"node_modules/axios": {
  "version": "1.9.0",
  "resolved": "https://registry.npmmirror.com/axios/-/axios-1.9.0.tgz",
  "integrity": "sha512-re4CqKTJaURpzbLHtIi6XpDv20/CnpXOtjRY5/CU32L8gU8ek9UIivcfvSWvmKEngmVbrUtPpdDwWDWL7DNHvg==",
  "license": "MIT",
  "dependencies": {
    "follow-redirects": "^1.15.6",
    "form-data": "^4.0.0",
    "proxy-from-env": "^1.1.0"
  }
}

The Attack Scenario

Consider this application uses axios to fetch data from external APIs (common patterns include web scraping with cheerio, which is also a dependency in this project). An attacker could exploit this in several ways:

1. Malicious API Response: If the application fetches data from a URL that an attacker can influence (e.g., a webhook URL, a user-provided feed URL, or a compromised API), the attacker returns a multi-gigabyte response body.

2. Slowloris-style Memory Exhaustion: The attacker sends a response with a Content-Length header indicating a normal size but streams an enormous body, or omits the header entirely and streams indefinitely.

3. Amplification via Redirects: Combined with follow-redirects (also a dependency), an attacker could chain redirects to a malicious endpoint that serves an unbounded payload.

In each case, axios in version 1.9.0 would attempt to buffer the entire response into memory without checking if it exceeds a safe threshold. The Node.js process's heap grows until it hits V8's memory limit (typically 1.5–4 GB depending on configuration), at which point the process crashes with an out-of-memory error.

Real-World Impact

For this specific application—which uses cheerio for HTML parsing, cron for scheduled tasks, and cors for cross-origin handling—the likely scenario is a scheduled job or API endpoint that fetches external content. If that content source is compromised or manipulated, a single malicious response could:

• Crash the entire Node.js process
• Cause cascading failures if running in a cluster
• Create a persistent DoS if the cron job retries automatically
• Consume all available memory on the host, affecting other services

The Fix

The fix upgrades axios from version 1.9.0 to 1.12.0, which introduces proper data size validation at the library level.

Before (Vulnerable)

In package.json:

"axios": "^1.4.0"

Resolved in package-lock.json to:

"version": "1.9.0"

After (Fixed)

In package.json:

"axios": "^1.12.0"

Resolved in package-lock.json to:

"node_modules/axios": {
  "version": "1.12.0",
  "resolved": "https://registry.npmjs.org/axios/-/axios-1.12.0.tgz",
  "integrity": "sha512-oXTDccv8PcfjZmPGlWsPSwtOJCZ/b6W5jAMCNcfwJbCzDckwG0jrYJFaWH1yvivfCXjVzV/SPDEhMB3Q+DSurg==",
  "license": "MIT",
  "dependencies": {
    "follow-redirects": "^1.15.6",
    "form-data": "^4.0.4",
    "proxy-from-env": "^1.1.0"
  }
}

What Changed

1. package.json: The version constraint was tightened from ^1.4.0 to ^1.12.0, ensuring no future npm install can resolve to a vulnerable version.

2. package-lock.json: The locked version moved from 1.9.0 to 1.12.0, and the form-data sub-dependency was also updated from ^4.0.0 to ^4.0.4 (addressing potential related issues in form data handling).

3. Registry change: The resolved URLs switched from registry.npmmirror.com to registry.npmjs.org, ensuring packages are fetched from the canonical npm registry—a subtle but important supply chain hygiene improvement.

Axios 1.12.0 internally enforces size limits on response data by default, preventing unbounded memory allocation even when developers don't explicitly configure maxContentLength. This is a defense-in-depth improvement that protects all consumers of the library.

Prevention & Best Practices

1. Always Configure Size Limits Explicitly

Even with the fix, explicitly set limits in your axios configuration:

const axios = require('axios');

const client = axios.create({
  maxContentLength: 10 * 1024 * 1024, // 10 MB max response
  maxBodyLength: 10 * 1024 * 1024,    // 10 MB max request body
  timeout: 30000                        // 30 second timeout
});

2. Use Streaming for Large Responses

If you need to handle large files, use axios's streaming mode with manual size tracking:

const response = await axios.get(url, { responseType: 'stream' });
let size = 0;
const MAX_SIZE = 50 * 1024 * 1024; // 50 MB

response.data.on('data', (chunk) => {
  size += chunk.length;
  if (size > MAX_SIZE) {
    response.data.destroy();
    throw new Error('Response too large');
  }
});

3. Keep Dependencies Updated

• Use npm audit regularly to check for known vulnerabilities
• Configure Dependabot or Renovate for automated dependency updates
• Pin exact versions in package-lock.json and review updates carefully

4. Implement Application-Level Rate Limiting

Protect your application from DoS at multiple layers:
- Reverse proxy limits (nginx client_max_body_size)
- Application-level request timeouts
- Memory usage monitoring with automatic restarts

5. Use SCA Tools in CI/CD

Integrate Software Composition Analysis tools like Trivy, Snyk, or npm audit into your CI pipeline to catch vulnerable dependencies before they reach production.

Key Takeaways

• Axios 1.9.0 lacks transport-level data size enforcement, allowing a single malicious HTTP response to crash a Node.js process via memory exhaustion
• The ^1.4.0 semver range was too permissive—it allowed resolution to any 1.x version ≥1.4.0, but didn't guarantee the security fix in 1.12.0 would be installed
• Applications using cheerio + axios for web scraping are especially vulnerable, since they fetch content from potentially untrusted external sources
• Switching from npmmirror.com to npmjs.org in the lock file is a supply chain hygiene improvement that reduces the risk of mirror-based attacks
• Defense in depth matters: even with the library fix, explicitly configuring maxContentLength provides an additional safety net

How Orbis AppSec Detected This

• Source: External HTTP responses received by the axios client when making outbound requests (e.g., API calls, web scraping via cheerio)
• Sink: axios's internal response buffering mechanism in version 1.9.0, which accumulates response data in memory without size validation
• Missing control: No maximum data size check on incoming HTTP response bodies at the transport layer
• CWE: CWE-400 (Uncontrolled Resource Consumption)
• Fix: Upgraded axios from 1.9.0 to 1.12.0, which adds built-in response data size validation to prevent memory exhaustion

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2025-58754 is a reminder that even widely-used, well-maintained libraries like axios can have fundamental safety gaps. The lack of a data size check—something that seems obvious in hindsight—could allow a trivial attack to bring down production services. By upgrading to axios 1.12.0, tightening your semver constraints, and implementing defense-in-depth measures like explicit size limits and timeouts, you can protect your Node.js applications from this class of DoS attack.

Don't wait for an incident to audit your dependencies. Run npm audit today, and consider automated tools that continuously monitor your dependency tree for newly disclosed vulnerabilities.

References

• CWE-400: Uncontrolled Resource Consumption
• OWASP Denial of Service Cheat Sheet
• Axios Documentation - Request Config (maxContentLength)
• Semgrep Rules for DoS
• fix: upgrade axios to 1.12.0, 0.30.2 (CVE-2025-58754)