Axios prototype pollution can expose Node.js request traffic

At a glance

What this is: This disclosure shows that cloning Axios request config can undo prototype-pollution hardening and let polluted proxy settings influence Node.js outbound traffic.

Why it matters: It matters because service-to-service clients often carry secrets, and IAM teams need to treat outbound request paths as credential-bearing surfaces when application code can re-open hardened trust boundaries.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Corgea's analysis of Axios prototype pollution and Node.js proxy exposure

Context

Prototype pollution becomes operationally dangerous when it changes how a service reads configuration at runtime, not just when it corrupts an object in memory. In this case, Axios’s Node.js HTTP adapter can be steered by inherited proxy settings if a later config clone restores a normal prototype chain, which turns a coding convenience into an outbound trust failure in Node.js services.

The identity angle is real because service accounts, API tokens, and Basic auth values often sit inside those same request objects. When application code or a dependency can re-open access to Object.prototype during request dispatch, NHI controls such as secret handling, outbound proxy policy, and request integrity all need to be evaluated together rather than in isolation.

Key questions

Q: What breaks when a request interceptor clones hardened Axios config in Node.js services?

A: A plain-object clone can restore the default prototype chain after Axios has already hardened the merged config. If another dependency has polluted Object.prototype.proxy, the adapter may read that inherited value during dispatch and route traffic through an attacker-controlled proxy. The failure is a control-boundary reset, not just a coding style issue.

Q: Why do service clients with secrets become higher risk when prototype pollution is possible?

A: Because request objects often carry bearer tokens, Basic auth, cookies, and routing metadata in the same structure. If application code can re-open inherited property access, those secrets can be redirected or observed through an untrusted proxy. That makes outbound clients part of NHI governance, not just transport plumbing.

Q: How do security teams know whether Axios requests are still exposed to inherited proxy values?

A: Check whether any request middleware clones config into a plain object before dispatch, then validate whether the service uses the Node HTTP adapter and accepts inputs from other vulnerable packages. If both conditions exist, test for prototype pollution and confirm that proxy is always an own property on the final config.

Q: Who is accountable when a dependency chain turns outbound traffic into a secret leak?

A: Accountability is shared across application engineering, AppSec, and identity governance because the failure spans code, dependency management, and credential handling. The engineering team owns the middleware pattern, AppSec owns detection and testing, and identity teams own the impact on secrets, service accounts, and outbound trust policy.

Technical breakdown

How request interceptor cloning breaks hardened config objects

Axios hardens request configuration by creating a null-prototype object during merge, which prevents inherited Object.prototype values from being read as own properties. The weakness appears when a request interceptor returns a cloned plain object, such as via spread syntax or Object.assign. That clone restores the default prototype chain, so downstream code now sees inherited values again. In other words, the security boundary is not broken at merge time but at the extension point that rebuilds the object.

Practical implication: Review interceptors that return cloned configs and preserve the null-prototype invariant end to end.

Why the Node.js HTTP adapter becomes the trust boundary

The Node HTTP adapter consumes config.proxy when building outbound requests. If proxy is no longer an own property and Object.prototype.proxy has already been polluted elsewhere in the process, the adapter can resolve the inherited attacker-controlled value. That makes the adapter the sink for a cross-library failure: one component pollutes prototype state, another component accidentally makes that state visible again, and outbound routing follows the polluted value.

Practical implication: Treat outbound HTTP routing as a security control point and validate own-property access before dispatch.

What plaintext traffic exposure changes in practice

The public proof of concept shows that the proxy can observe request metadata and contents when plaintext HTTP is used, including Authorization headers, Basic auth, method, URL, host, and body. The impact is narrower under TLS with proper validation, but many internal services still use plaintext links for local, sidecar, or development traffic. That makes the issue a practical credential-exposure and request-integrity problem, not just a theoretical prototype-pollution bug.

Practical implication: Inventory plaintext Axios traffic first, because that is where secret exposure becomes immediately actionable.

Threat narrative

Attacker objective: The attacker wants to redirect outbound application traffic through a proxy they control so they can harvest secrets and alter responses.

1. Entry occurs when a separate dependency, parser, or upstream bug pollutes Object.prototype.proxy inside the Node.js process.
2. Escalation occurs when a request interceptor clones hardened Axios config into a normal object, restoring inherited property lookup during dispatch.
3. Impact occurs when the HTTP adapter routes plaintext requests through an attacker-controlled proxy that can read headers, bodies, and responses.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prototype-pollution-to-proxy redirection is the real failure mode here: the issue is not abstract object corruption, it is the loss of a hardening invariant between merge and dispatch. Security teams often assume that a null-prototype merge is enough, but later object cloning can silently restore the prototype chain. Practitioners should treat object reconstruction in request middleware as part of the control surface, not just application style.

Outbound HTTP clients are identity-bearing systems because they carry secrets and trust decisions: once a service account token, API key, or Basic auth value is placed in a request object, it becomes part of the credential governance boundary. That means IAM, PAM, and application security teams need shared ownership of request libraries that touch authentication metadata. The practical conclusion is that service clients need the same scrutiny as other NHI-bearing components.

Prototype-chain rehydration should be treated as a named control gap in secure coding reviews: the dangerous step is not pollution alone but the moment a library turns a hardened object back into a default JavaScript object. That pattern is easy to miss because it looks like a harmless immutable update. Code review and SAST should flag config cloning after security hardening, especially in libraries that process proxy, auth, or routing fields.

This disclosure validates a broader governance problem in Node.js dependency chains: one package can pollute shared state, while another package can make that state reachable again through a perfectly ordinary extension point. That means application risk is now cumulative across packages, not isolated to the directly vulnerable library. The practitioner takeaway is to assess dependency interactions, not just individual CVEs.

For NHI governance, the key question is whether outbound clients can be coerced into trusting inherited configuration: if they can, then secret handling and transport trust are no longer separable controls. The right response is to define request middleware rules for secret-bearing services and require safe object construction patterns in code review. Teams should assume request config is a governance object, not a convenience wrapper.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For related guidance: 52 NHI Breaches Analysis shows how leaked credentials and exposed service identities repeatedly become breach multipliers.

What this signals

Prototype-chain rehydration is a useful name for a class of failures where a secure object becomes insecure again later in the request lifecycle. That pattern is relevant beyond Axios because any middleware stack that rebuilds config objects can accidentally restore inherited state and weaken routing, auth, or proxy controls.

For identity programmes, the signal is that application security and NHI governance now intersect at the request library layer. When secrets ride inside code-managed clients, teams need controls that cover dependency reachability, safe object construction, and credential exposure on plaintext paths, aligned with NIST SP 800-53 Rev 5 Security and Privacy Controls.

The broader programme implication is that dependency audits must move from version checking to behaviour checking. A service can be on a patched library and still be at risk if custom interceptors or wrapper code defeat the library’s safety invariant; that is the sort of issue that also shows up in the 52 NHI breaches Report when credentials and trust boundaries are treated separately.

For practitioners

• Inventory vulnerable Axios versions and usage paths Find all instances of axios in Node.js services, then identify which code paths use the HTTP adapter, return cloned configs, or handle secret-bearing requests. Prioritise internal services, webhooks, CI helpers, and metadata fetchers where plaintext traffic is still common.
• Eliminate plain-object config cloning in interceptors Replace spread syntax and Object.assign patterns in request interceptors with safe updates that preserve the original hardened config or use a null-prototype clone. This matters most where interceptors touch proxy, auth, or routing fields.
• Restrict outbound proxy trust to explicit own properties Require own-property checks for proxy settings in security-sensitive clients, and set proxy: false where proxy support is unnecessary. That reduces the chance that inherited Object.prototype values can steer request routing.
• Rotate secrets seen on plaintext request paths If vulnerable Axios versions were used on plaintext HTTP routes, rotate credentials that may have appeared in headers, config.auth, or request bodies. Review proxy logs and response handling for signs of redirection during the exposure window.
• Test for shared-state pollution across dependencies Add security tests that attempt prototype pollution in one dependency and validate whether another library later rehydrates polluted values into runtime request objects. This catches cross-package failure chains that individual package audits miss.

Key takeaways

• The core flaw is not prototype pollution alone, but the way ordinary interceptor cloning can undo a library's hardening before dispatch.
• The impact matters because Node.js services often carry secrets in outbound request objects, and plaintext traffic makes proxy interception immediately dangerous.
• Teams should treat request middleware, dependency interaction, and secret-bearing clients as one governance surface, not three separate controls.

Key terms

• Prototype Pollution: Prototype pollution is a JavaScript bug where attacker-controlled keys modify Object.prototype or another shared prototype. That makes the injected property visible to many objects that were never directly touched by the attacker. In security terms, it creates hidden state that later code may treat as trusted configuration.
• Null-prototype Object: A null-prototype object is created without Object.prototype in its inheritance chain, so inherited properties are not consulted during lookups. Security-sensitive code uses this pattern to reduce prototype-pollution risk, but later cloning can remove that protection if the object is rebuilt normally.
• Request Interceptor: A request interceptor is middleware that modifies or replaces an outgoing request before it is sent. In Node.js clients, interceptors are powerful because they can add headers, auth, and routing metadata, but they also become a security boundary when they reconstruct config objects.
• Outbound Proxy Routing: Outbound proxy routing is the decision process that sends a client request through an intermediary before reaching the target service. If that routing value is influenced by inherited properties or polluted state, attackers can intercept traffic, observe secrets, or alter responses.

What's in the full report

Corgea's full article covers the code-level detail this post intentionally leaves for the source:

• A line-by-line look at the mergeConfig, interceptor, and dispatch sequence that exposes the hardening gap.
• Proof-of-concept output showing how proxy routing can capture headers, bodies, and response content.
• Version-specific remediation guidance for the affected axios ranges and patch targets.
• Search patterns for locating risky interceptor code and plaintext Node.js request paths in real codebases.

👉 Corgea's full article shows the exploit chain, affected versions, and remediation details in code context.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is built for practitioners who need to connect credential risk to operational governance across modern security programmes.