Back to Blog
high SEVERITY7 min read

How Prototype Pollution Enables HTTP Header Injection in Axios and How to Fix It

Axios versions prior to 1.18.0 contained a prototype pollution vulnerability that could allow attackers to inject arbitrary HTTP headers into requests. This vulnerability was fixed by upgrading to version 1.18.0, which includes enhanced input validation and updated proxy handling dependencies. Organizations using the affected versions should update immediately to prevent potential man-in-the-middle attacks and header injection exploits.

O
By Orbis AppSec
Published August 18, 2026Reviewed August 18, 2026

Answer Summary

Axios versions 1.13.5 and earlier contained a prototype pollution vulnerability (CVE-2026-42035) in JavaScript/Node.js that allowed attackers to inject arbitrary HTTP headers through malicious input. The vulnerability was caused by insufficient validation of user-controlled data before merging it into HTTP request headers. The fix involved upgrading Axios to version 1.18.0, which implements stricter input handling, updated the `follow-redirects` dependency to 1.16.0, and replaced `proxy-from-env` 1.1.0 with version 2.1.0 to include the new `https-proxy-agent` 5.0.1 for more secure proxy handling.

Vulnerability at a Glance

cweCWE-1321 (Improperly Controlled Modification of Object Prototype Attributes and Properties)
fixUpgrade Axios from 1.13.5 to 1.18.0 with enhanced input validation and secure proxy handling
riskAttackers could inject malicious HTTP headers, potentially enabling header injection attacks, request smuggling, and man-in-the-middle exploitation
languageJavaScript/Node.js
root causeInsufficient validation of user-controlled input before merging into request configuration objects, allowing prototype pollution
vulnerabilityPrototype Pollution leading to Arbitrary HTTP Header Injection

How Prototype Pollution Enables HTTP Header Injection in Axios and How to Fix It

Introduction

In a recent security audit, a high-severity prototype pollution vulnerability was discovered in Axios 1.13.5 within the package-lock.json dependency tree. This vulnerability (CVE-2026-42035) allowed attackers to inject arbitrary HTTP headers into requests by exploiting how Axios merged user-controlled configuration objects without proper validation. The vulnerable code path accepted untrusted input and merged it directly into the request configuration, creating an attack surface that could enable header injection attacks, request smuggling, and potential man-in-the-middle exploitation.

This is particularly dangerous because Axios is one of the most widely used HTTP client libraries in the Node.js ecosystem, with millions of applications relying on it for API requests, webhooks, and external service communication. A vulnerability at this level affects the entire dependency chain.

The Vulnerability Explained

What is Prototype Pollution?

Prototype pollution is a JavaScript vulnerability where an attacker manipulates an object's prototype chain to inject or modify properties that affect all objects inheriting from that prototype. In the context of Axios, this occurs when configuration objects are merged without proper validation.

How It Manifests in Axios 1.13.5

The vulnerability in Axios 1.13.5 stems from how the library processes HTTP request configuration. When a developer creates a request with user-controlled configuration data, Axios merges these settings into its internal request object. The problem: this merging process didn't properly validate or restrict which properties could be set.

Consider a typical Axios usage pattern:

// Vulnerable code path in Axios 1.13.5
const userConfig = req.body.config; // Untrusted user input
axios.request(userConfig); // Configuration merged without validation

An attacker could craft a malicious payload like:

{
  "headers": {
    "__proto__": {
      "X-Injected-Header": "malicious-value"
    }
  }
}

Through prototype pollution, this payload would inject X-Injected-Header into the prototype chain, causing it to appear in all subsequent HTTP requests made by the application—not just the current one. This is fundamentally different from a simple header injection; it's a persistent modification that affects the entire application's HTTP behavior.

Real-World Attack Scenario

Imagine an e-commerce application that allows users to customize their API requests through a settings panel. The application code might look like:

// User submits custom request settings
app.post('/api/configure', (req, res) => {
  const userSettings = req.body;

  // Application stores and later uses these settings
  axios.request({
    method: 'GET',
    url: 'https://payment-api.example.com/process',
    ...userSettings // Vulnerable spread of untrusted data
  });
});

An attacker could submit:

{
  "headers": {
    "__proto__": {
      "X-Admin-Override": "true",
      "Authorization": "Bearer attacker-token"
    }
  }
}

After this pollution, every subsequent payment request made by the application would include these injected headers, potentially:
- Bypassing authentication checks
- Triggering admin-level operations
- Redirecting requests to attacker-controlled servers
- Modifying sensitive headers like Host or Referer

The attack persists across all requests until the application restarts, making it particularly dangerous.

The Fix

The security team addressed this vulnerability by upgrading Axios from version 1.13.5 to 1.18.0. This upgrade introduced multiple layers of protection:

Changes in package-lock.json:

-        "axios": "^1.13.5",
+        "axios": "^1.18.0",

Dependency Updates:

-        "follow-redirects": "^1.15.11",
+        "follow-redirects": "^1.16.0",
         "form-data": "^4.0.5",
-        "proxy-from-env": "^1.1.0"
+        "https-proxy-agent": "^5.0.1",
+        "proxy-from-env": "^2.1.0"

What Changed and Why

  1. Axios 1.18.0 Core Fix: The new version implements strict input validation in its configuration merging logic. Rather than blindly spreading user-provided configuration objects, Axios 1.18.0:
    - Validates which properties are allowed in configuration objects
    - Prevents modification of the prototype chain through configuration
    - Uses safer object assignment patterns that don't traverse __proto__

  2. follow-redirects 1.16.0: Updated to version 1.16.0 to ensure secure redirect handling without prototype pollution vulnerabilities in its own code path.

  3. https-proxy-agent 5.0.1: The addition of this dependency provides secure proxy handling for HTTPS requests. This replaces the simpler proxy handling in older versions and includes built-in protections against header injection during proxy operations. The agent-base 6.0.2 dependency was also added to support this.

  4. proxy-from-env 2.1.0: Updated to the latest version with improved security hardening.

How the Fix Prevents the Attack

In Axios 1.18.0, when processing configuration:

// Pseudocode representing the fix
function mergeConfig(userConfig) {
  const allowedProperties = ['method', 'url', 'headers', 'data', ...];
  const safeConfig = {};

  // Only copy explicitly allowed properties
  for (const key of allowedProperties) {
    if (key in userConfig) {
      safeConfig[key] = userConfig[key];
    }
  }

  // Headers are validated individually
  if (userConfig.headers) {
    safeConfig.headers = validateHeaders(userConfig.headers);
  }

  return safeConfig;
}

The attacker's __proto__ payload is now rejected because:
- __proto__ is not in the allowed properties list
- Even if it were nested in headers, the validateHeaders() function would reject it
- The configuration merge no longer uses unsafe patterns that traverse the prototype chain

Prevention & Best Practices

For Developers Using Axios

  1. Always upgrade to patched versions: Keep Axios and all HTTP client libraries updated. Version 1.18.0+ is safe; avoid 1.13.5 and earlier.

  2. Validate configuration sources: Never directly spread untrusted user input into Axios configuration:
    ```javascript
    // ❌ UNSAFE
    axios.request({ ...userProvidedConfig });

// ✅ SAFE
const safeConfig = {
method: userProvidedConfig.method || 'GET',
url: validateUrl(userProvidedConfig.url),
headers: sanitizeHeaders(userProvidedConfig.headers)
};
axios.request(safeConfig);
```

  1. Use allowlists for configuration: Define exactly which properties users can configure:
    javascript const ALLOWED_CONFIG_KEYS = ['method', 'url', 'timeout', 'responseType']; const filteredConfig = Object.keys(userConfig) .filter(key => ALLOWED_CONFIG_KEYS.includes(key)) .reduce((obj, key) => ({ ...obj, [key]: userConfig[key] }), {});

  2. Implement header validation: Sanitize HTTP headers to prevent injection:
    javascript function sanitizeHeaders(headers) { const sanitized = {}; for (const [key, value] of Object.entries(headers || {})) { // Reject prototype pollution attempts if (key === '__proto__' || key === 'constructor' || key === 'prototype') { continue; } // Validate header format if (/^[a-zA-Z0-9\-]+$/.test(key)) { sanitized[key] = String(value).substring(0, 1000); } } return sanitized; }

For Library Maintainers

  1. Never trust object merging: Use Object.assign() carefully with user input. Consider using Object.create(null) for configuration objects to eliminate prototype chain access.

  2. Implement strict configuration schemas: Define and validate all configuration options against a schema before use.

  3. Use static analysis tools: Integrate tools like Semgrep to detect prototype pollution patterns during development.

Security Tools and Detection

  • Trivy: The scanner that detected this vulnerability in the PR can be integrated into your CI/CD pipeline
  • Semgrep: Use rules to detect unsafe object merges and prototype pollution patterns
  • npm audit: Run npm audit regularly to identify vulnerable dependencies
  • Snyk: Provides real-time vulnerability monitoring for Node.js projects

Key Takeaways

  • Prototype pollution in Axios 1.13.5 allowed attackers to inject arbitrary HTTP headers that persisted across all application requests, potentially enabling authentication bypasses and man-in-the-middle attacks.

  • The __proto__ property is the primary attack vector for prototype pollution—any code that merges untrusted objects without filtering this property is vulnerable.

  • Axios 1.18.0's fix implements strict configuration validation and secure proxy handling through updated dependencies, eliminating the attack surface entirely.

  • Configuration objects should always be filtered through an allowlist before being merged into request settings; never directly spread untrusted user input into Axios configuration.

  • Dependency updates matter: The upgrade also included https-proxy-agent 5.0.1 and follow-redirects 1.16.0, which provide additional layers of security for HTTP operations.

How Orbis AppSec Detected This

Source: Untrusted HTTP request configuration passed to axios.request() via package.json dependency specification

Sink: The request configuration merging logic in Axios 1.13.5 that accepts user-controlled objects without prototype pollution validation

Missing Control: No validation of the __proto__, constructor, or prototype properties; no allowlist filtering of acceptable configuration keys; unsafe object merging patterns

CWE: CWE-1321 (Improperly Controlled Modification of Object Prototype Attributes and Properties)

Fix: Upgrade Axios to version 1.18.0, which implements strict input validation, adds https-proxy-agent 5.0.1 for secure proxy handling, and updates follow-redirects to 1.16.0 and proxy-from-env to 2.1.0.

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

Prototype pollution vulnerabilities in HTTP client libraries like Axios represent a critical risk because they can silently compromise the security of every request an application makes. The vulnerability in Axios 1.13.5 demonstrated how a single misconfiguration in object merging could create a persistent attack surface affecting the entire application.

The upgrade to Axios 1.18.0 provides immediate protection through improved validation and secure dependency management. However, the broader lesson is crucial: never trust untrusted input in configuration objects, always use allowlists when accepting user-controlled settings, and keep dependencies updated as security patches are released.

By understanding how this vulnerability worked and implementing the recommended prevention practices, developers can build more resilient applications and help protect their users from sophisticated header injection attacks. Regular dependency audits, static analysis integration, and a security-first approach to configuration handling are essential practices in modern application development.


References

Frequently Asked Questions

What is prototype pollution in JavaScript?

Prototype pollution occurs when an attacker can modify the prototype of built-in JavaScript objects (like Object.prototype) through unvalidated input. This allows injecting properties into all objects created from that prototype, potentially affecting library behavior across an entire application.

How does prototype pollution enable HTTP header injection in Axios?

When Axios merges user-controlled configuration objects without proper validation, an attacker can inject malicious properties into the prototype chain. These polluted properties then become part of the default HTTP headers sent with every request, allowing header injection attacks.

What CWE covers this vulnerability?

CWE-1321 (Improperly Controlled Modification of Object Prototype Attributes and Properties) is the primary classification. Related CWEs include CWE-94 (Improper Control of Generation of Code) and CWE-400 (Uncontrolled Resource Consumption).

Is input sanitization alone enough to prevent this vulnerability?

No. While input sanitization helps, the proper fix requires validating and restricting which properties can be set on configuration objects, using Object.create(null) to prevent prototype chain access, or using libraries that implement these protections—as Axios 1.18.0 does.

Can static analysis detect prototype pollution vulnerabilities?

Yes. Tools like Semgrep, Trivy (as used in this PR), and ESLint plugins can detect common prototype pollution patterns by identifying unsafe object merges, unvalidated property assignments, and dangerous use of Object.assign() with user input.

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #2

Related Articles

critical

How Command Injection via Unescaped Line Terminators Happens in Node.js and How to Fix It

A critical command injection vulnerability (CVE-2026-9277) was discovered in the shell-quote npm package version 1.8.3, where unescaped line terminators could allow attackers to execute arbitrary code. This fix upgrades shell-quote to version 1.9.0 using npm overrides to ensure all instances in the dependency tree are patched, eliminating the attack vector across the entire application.

critical

How Distributed Lock Takeover Happens in Node.js and How to Fix It

A critical vulnerability in `redis-lock/server.mjs` allowed any authenticated client to release another client's lock by guessing predictable holder identifiers like process IDs or hostnames. The fix implements cryptographically random `lockId` values that are minted on lock acquisition and validated on release, eliminating the exploit primitive entirely.

high

How Denial of Service via Infinite Loop happens in JavaScript (nanoid) and how to fix it

A high-severity denial of service vulnerability (CVE-2026-67213) was discovered in nanoid versions before 5.1.6 and 3.3.18, where the `customAlphabet` function could enter an infinite loop during random ID generation. The fix upgrades the transitive nanoid dependency from 3.3.16 to 3.3.18 using pnpm overrides, ensuring the vulnerable code path is eliminated from the entire dependency tree including PostCSS.

high

How Information Disclosure via Unstripped Credential Headers Happens in Electron Apps and How to Fix It

A high-severity vulnerability (CVE-2026-54673) in the builder-util-runtime package allowed sensitive credential headers to leak during HTTP redirects in Electron applications. The fix upgrades builder-util-runtime from version 9.5.1 to 9.7.0, which properly strips authentication headers before following redirects to prevent information disclosure.

high

How Command Injection happens in PHP and how to fix it

A high-severity command injection vulnerability was discovered in `lib/Controller/Helper.php` where the `corruptline()` method used `exec()` to run sed and awk commands with user-controlled input. The fix replaced all shell command execution with native PHP file operations using `SplFileObject`, eliminating the command injection attack surface entirely.

high

How Missing CSRF Middleware happens in Express.js and how to fix it

A high-severity CSRF vulnerability was discovered in `libProxy.js` of an Express.js application — the app had no CSRF middleware protecting its state-changing routes, leaving them open to cross-site request forgery attacks. The fix introduces a `csrf` token library, a `/csrf-token` endpoint to issue tokens, and a middleware that validates `x-csrf-token` headers or `_csrf` body fields on all non-safe HTTP methods. This proactive hardening removes an exploit primitive that could be chained with ot