How Denial of Service via Unbounded Data Size Happens in Node.js HTTP Clients and How to Fix It

Introduction

The ComfyUIGen plugin, designed for AI image generation via ComfyUI, relied on axios version 1.11.0 for making HTTP requests. During a routine security scan, Trivy flagged a critical issue: the axios dependency in Plugin/ComfyUIGen/package-lock.json was vulnerable to CVE-2025-58754, a denial of service attack that could bring down the entire application.

This vulnerability is particularly dangerous for plugins that interact with external services—exactly what ComfyUIGen does when communicating with ComfyUI backends. An attacker controlling or intercepting these HTTP responses could craft a malicious payload designed to exhaust the Node.js process's memory, causing the plugin and potentially the entire application to crash.

The Vulnerability Explained

What Went Wrong

Axios is one of the most popular HTTP client libraries in the JavaScript ecosystem, used by millions of projects for making HTTP requests. In versions prior to 1.12.0, axios had a fundamental flaw: it didn't properly enforce limits on the size of data it would accept from HTTP responses.

Looking at the vulnerable dependency declaration in package.json:

"dependencies": {
    "axios": "^1.6.0",
    "uuid": "^9.0.0"
}

This semver range (^1.6.0) allowed npm to resolve to version 1.11.0, which is what the package-lock.json recorded:

"node_modules/axios": {
    "version": "1.11.0",
    "resolved": "https://registry.npmmirror.com/axios/-/axios-1.11.0.tgz",
    "integrity": "sha512-1Lx3WLFQWm3ooKDYZD1eXmoGO9fxYQjrycfHFC8P0sCfQVXyROp0p9PFWBehewBOdCwHc+f/b8I0fMto5eSfwA==",
    ...
}

How the Attack Works

Consider how ComfyUIGen likely uses axios to communicate with a ComfyUI backend:

const axios = require('axios');

// Fetching generated image data from ComfyUI
const response = await axios.get('http://comfyui-server/api/images/output.png');
const imageData = response.data;

In a normal scenario, this returns image data of a few megabytes. But what if an attacker can control or intercept the response? They could return an HTTP response claiming to be a valid image but actually streaming gigabytes of data:

HTTP/1.1 200 OK
Content-Type: image/png
Transfer-Encoding: chunked

[Endless stream of data...]

With vulnerable axios versions, the library would happily buffer this entire response into memory. A 4GB response on a server with 2GB of RAM? The Node.js process crashes with an out-of-memory error. The service becomes unavailable. If this is a production system handling multiple users, all of them lose access.

Real-World Attack Scenario

For ComfyUIGen specifically, the attack surface includes:

1. Compromised ComfyUI Server: If an attacker gains control of the ComfyUI backend, they can return malicious responses to all axios requests
2. Man-in-the-Middle: On networks without TLS or with certificate validation disabled, attackers can intercept and modify responses
3. DNS Hijacking: Redirecting the ComfyUI hostname to an attacker-controlled server

Any of these scenarios allows the attacker to send unbounded data that crashes the plugin.

The Fix

The fix is elegantly simple: upgrade axios to version 1.12.0, which properly enforces data size limits.

Before (Vulnerable)

package.json:

"dependencies": {
    "axios": "^1.6.0",
    "uuid": "^9.0.0"
}

package-lock.json:

"node_modules/axios": {
    "version": "1.11.0",
    "resolved": "https://registry.npmmirror.com/axios/-/axios-1.11.0.tgz",
    ...
}

After (Fixed)

package.json:

"dependencies": {
    "axios": "^1.12.0",
    "uuid": "^9.0.0"
}

package-lock.json:

"node_modules/axios": {
    "version": "1.12.0",
    "resolved": "https://registry.npmjs.org/axios/-/axios-1.12.0.tgz",
    "integrity": "sha512-oXTDccv8PcfjZmPGlWsPSwtOJCZ/b6W5jAMCNcfwJbCzDckwG0jrYJFaWH1yvivfCXjVzV/SPDEhMB3Q+DSurg==",
    ...
}

Why Both Files Changed

1. package.json: The version constraint was updated from ^1.6.0 to ^1.12.0 to ensure that future npm install commands will always resolve to at least version 1.12.0

2. package-lock.json: This file records the exact resolved version. Updating it ensures that all developers and CI/CD pipelines get the exact same patched version (1.12.0) rather than potentially resolving to a vulnerable version

What axios 1.12.0 Does Differently

The patched version implements proper enforcement of the maxContentLength and maxBodyLength configuration options. Even if developers don't explicitly set these limits, axios 1.12.0 applies sensible defaults that prevent unbounded memory consumption.

Prevention & Best Practices

1. Pin Dependencies Appropriately

While semver ranges like ^1.6.0 are convenient, they can allow vulnerable versions to be installed. Consider:

// More restrictive: only patch updates
"axios": "~1.12.0"

// Most restrictive: exact version
"axios": "1.12.0"

2. Implement Defense in Depth

Even with patched libraries, add your own safeguards:

const axios = require('axios');

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

3. Regular Dependency Auditing

Run security audits as part of your CI/CD pipeline:

npm audit
npx trivy fs --scanners vuln .

4. Use Lockfile Maintenance

Regularly update your lockfile to get security patches:

npm update
npm audit fix

5. Monitor for CVEs

Subscribe to security advisories for your critical dependencies. The Node.js security ecosystem has tools like npm audit built in, but third-party scanners like Trivy, Snyk, and Dependabot provide additional coverage.

Key Takeaways

• Axios versions before 1.12.0 are vulnerable to CVE-2025-58754: Any project using axios 1.11.0 or earlier should upgrade immediately
• The ComfyUIGen plugin's HTTP communication with ComfyUI backends was at risk: External service communication is a prime attack vector for DoS vulnerabilities
• Semver ranges can silently allow vulnerable versions: The ^1.6.0 constraint permitted resolution to the vulnerable 1.11.0 version
• Both package.json and package-lock.json must be updated: Changing only one file leaves the vulnerability potentially exploitable
• Defense in depth matters: Even with patched libraries, explicitly setting maxContentLength and timeout provides additional protection

How Orbis AppSec Detected This

• Source: HTTP responses from external ComfyUI services consumed by the axios client in the ComfyUIGen plugin
• Sink: axios response handling in Plugin/ComfyUIGen/ where unbounded data could be buffered into memory
• Missing control: No enforced limit on HTTP response body size in axios versions prior to 1.12.0
• CWE: CWE-400 (Uncontrolled Resource Consumption)
• Fix: Upgraded axios dependency from 1.11.0 to 1.12.0 in both package.json and package-lock.json

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 serves as a reminder that even well-maintained, popular libraries can have serious security flaws. The axios library is used by countless Node.js applications, and this DoS vulnerability could have widespread impact if left unpatched.

For the ComfyUIGen plugin specifically, this vulnerability could have allowed attackers to crash the image generation service by exploiting the HTTP communication channel with ComfyUI backends. The fix—a simple version bump—eliminates this attack vector while maintaining full backward compatibility.

Keep your dependencies updated, run regular security audits, and implement defense in depth. Your future self (and your users) will thank you.

References

• CWE-400: Uncontrolled Resource Consumption
• OWASP Denial of Service Cheat Sheet
• axios GitHub Repository
• npm audit documentation
• Semgrep Rules for JavaScript Security
• fix: upgrade axios to 1.12.0, 0.30.2 (CVE-2025-58754)