How NO_PROXY bypass via crafted URL happens in Node.js axios and how to fix it

How NO_PROXY bypass via crafted URL happens in Node.js axios and how to fix it

Introduction

In a Node.js project using the popular axios HTTP client library, Trivy flagged a high-severity vulnerability (CVE-2026-42043) in the yarn.lock file. The project had axios pinned at version 1.15.0 through a resolution in package.json, but this version contained a critical flaw in how it evaluates URLs against the NO_PROXY environment variable.

The vulnerability is particularly dangerous because NO_PROXY is a security boundary — it tells HTTP clients which hosts should never have their traffic routed through a proxy. When this boundary can be bypassed with a crafted URL, internal service-to-service communication that was assumed to be direct can instead flow through an attacker-controlled proxy server, exposing authentication tokens, API keys, and sensitive request bodies.

For any Node.js application that relies on NO_PROXY to protect internal traffic (which is extremely common in containerized and cloud-native environments), this vulnerability represents a direct path to data exfiltration.

The Vulnerability Explained

Axios uses the proxy-from-env package to determine whether a given request should use a proxy based on the HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables. The vulnerable version (1.15.0) depended on proxy-from-env version ^1.1.0:

axios@1.6.2, axios@^1.15.0:
  version "1.15.0"
  resolved "https://registry.yarnpkg.com/axios/-/axios-1.15.0.tgz#..."
  dependencies:
    follow-redirects "^1.15.6"
    form-data "^4.0.0"
    proxy-from-env "^1.1.0"

The flaw lies in how the URL is parsed before being compared against NO_PROXY entries. An attacker who can influence the URL that axios requests (e.g., through user-supplied input, redirect chains, or configuration injection) can craft a URL that:

1. Resolves to an internal host (matching what should be in NO_PROXY)
2. Bypasses the string/pattern matching that proxy-from-env uses to check against NO_PROXY

For example, if NO_PROXY is set to internal-api.company.com, an attacker might craft a URL like http://internal-api.company.com%00.evil.com/secret or use URL encoding tricks, authentication segments (http://user@internal-api.company.com@evil.com/), or other parsing ambiguities that cause the proxy check to fail while the actual HTTP request still reaches the intended internal host — but now through the proxy.

Real-World Attack Scenario

Consider this project, which uses @adguard/hostlist-compiler and axios to fetch hostlists from various URLs. An attacker who can influence which URLs are fetched (perhaps through a configuration file or an upstream data source) could:

1. Set up a malicious proxy server
2. Ensure HTTP_PROXY points to their server in the deployment environment (or exploit an existing corporate proxy)
3. Craft a URL that bypasses NO_PROXY validation
4. Intercept requests that should have gone directly to internal services, capturing credentials or modifying responses

The impact is data exfiltration, credential theft, and potential man-in-the-middle attacks on traffic that operators believed was protected by NO_PROXY.

The Fix

The fix involves two key changes in package.json and the corresponding yarn.lock updates:

1. Adding axios 1.15.1 as a direct dependency:

"dependencies": {
    "@adguard/hostlist-compiler": "^2.1.0",
    "@sindresorhus/slugify": "^3.0.0",
    "axios": "1.15.1",
    "fs-extra": "^11.3.6"
}

2. The resolved dependency in yarn.lock now uses proxy-from-env ^2.1.0:

axios@1.15.1:
  version "1.15.1"
  resolved "https://registry.yarnpkg.com/axios/-/axios-1.15.1.tgz#075420b785da8adbdf545785b69f90c926b28542"
  integrity sha512-WOG+Jj8ZOvR0a3rAn+Tuf1UQJRxw5venr6DgdbJzngJE3qG7X0kL83CZGpdHMxEm+ZK3seAbvFsw4FfOfP9vxg==
  dependencies:
    follow-redirects "^1.15.11"
    form-data "^4.0.5"
    proxy-from-env "^2.1.0"

The critical difference is the upgrade from proxy-from-env "^1.1.0" to proxy-from-env "^2.1.0". This major version bump in the proxy resolution library includes proper URL canonicalization before comparing against NO_PROXY entries, eliminating the parsing ambiguity that allowed the bypass.

Additionally, follow-redirects was bumped from ^1.15.6 to ^1.15.11 and form-data from ^4.0.0 to ^4.0.5, indicating a comprehensive security update across axios's dependency tree.

By pinning axios at exactly 1.15.1 as a direct dependency (rather than relying solely on the resolution which used ^1.15.0), the fix ensures that yarn resolves to the patched version regardless of how other dependencies might request axios.

Prevention & Best Practices

1. Pin exact versions for security-critical dependencies: Using "axios": "1.15.1" (exact) rather than "axios": "^1.15.0" (range) ensures you get the specific patched version. While ranges offer flexibility, they can delay security fixes if your lockfile isn't regenerated.

2. Run dependency scanners in CI/CD: Tools like Trivy, Snyk, or npm audit should run on every PR to catch known vulnerabilities in your dependency tree before they reach production.

3. Audit proxy configuration in production: If your application relies on NO_PROXY as a security boundary, regularly verify that the HTTP client library correctly honors it. Write integration tests that confirm internal requests bypass the proxy.

4. Minimize URL construction from user input: When building URLs for axios requests, validate and sanitize input rigorously. Use the URL constructor to canonicalize URLs before passing them to HTTP clients.

5. Monitor for SSRF patterns: Any code path where user input influences outbound HTTP requests should be treated as a potential SSRF vector. The NO_PROXY bypass is essentially an SSRF enabler.

6. Keep transitive dependencies updated: The real fix here was in proxy-from-env, a transitive dependency. Tools that only check direct dependencies would miss this.

Key Takeaways

• NO_PROXY is a security boundary, not just a performance optimization — when it can be bypassed, internal traffic becomes visible to external parties
• The proxy-from-env ^1.x series had a URL parsing flaw that allowed crafted URLs to skip NO_PROXY matching; upgrading to ^2.1.0 via axios 1.15.1 resolves this
• Yarn resolutions alone aren't sufficient — this project had "axios": "^1.15.0" in resolutions but still resolved to the vulnerable 1.15.0; adding it as a direct pinned dependency at 1.15.1 was necessary
• Transitive dependency vulnerabilities require lockfile-level scanning — the vulnerability was in proxy-from-env, surfaced through axios, and detected only by scanning yarn.lock
• Follow-redirects was also bumped from ^1.15.6 to ^1.15.11, suggesting the redirect chain may have been part of the attack surface for URL crafting

How Orbis AppSec Detected This

• Source: URLs passed to axios HTTP requests, potentially influenced by external configuration or user input
• Sink: proxy-from-env URL-to-proxy resolution logic within axios's request pipeline, where NO_PROXY matching occurs
• Missing control: Proper URL canonicalization before comparing request URLs against NO_PROXY hostname patterns — crafted URLs could bypass string matching
• CWE: CWE-918 (Server-Side Request Forgery)
• Fix: Upgraded axios from 1.15.0 to 1.15.1, which depends on proxy-from-env ^2.1.0 with corrected URL parsing logic

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-2026-42043 is a reminder that proxy configuration isn't just an operational concern — it's a security boundary. When an HTTP client library like axios fails to properly validate URLs against NO_PROXY rules, the entire assumption that internal traffic stays internal breaks down. The fix was straightforward (upgrade axios to 1.15.1), but the implications of leaving it unpatched — data exfiltration through proxy interception — were severe. Always scan your lockfiles for known vulnerabilities, pin security-critical dependencies to exact versions, and treat NO_PROXY bypass as equivalent to SSRF in your threat models.

References

• CWE-918: Server-Side Request Forgery (SSRF)
• OWASP Server-Side Request Forgery Prevention Cheat Sheet
• Axios Official Documentation
• Semgrep Rules for SSRF
• fix: upgrade axios to 1.15.1, 0.31.1 (CVE-2026-42043)