Axios prototype pollution can expose Node.js request traffic

At a glance

What this is: This is a Node.js Axios vulnerability where a request interceptor that clones config can undo hardening and re-expose prototype-polluted proxy settings during outbound HTTP requests.

Why it matters: It matters because service-to-service clients, webhooks, CI helpers, and internal SDKs may carry credentials and request bodies that can be redirected or observed if prototype pollution reaches the process.

Context

Axios’s issue is not that JavaScript prototype pollution is unfamiliar, but that a later config clone can reopen a value path the library had already tried to close. In Node.js request flows, that turns a security boundary inside the client itself into a governance problem for outbound trust and secret handling.

The practical identity angle is indirect but real. When services authenticate with bearer tokens, Basic auth, or other secrets embedded in request metadata, an outbound request path that can be redirected or inspected becomes part of the identity attack surface, especially in internal service-to-service traffic.

This pattern is typical in modern Node.js codebases because immutable config transforms are a common engineering style. That makes the flaw more dangerous than an edge-case bug, since the same code shape can appear in wrappers, SDKs, and background jobs without raising suspicion.

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 does this Axios issue create real risk only after other prototype pollution exists?

A: Because the bug needs a polluted process to supply the malicious inherited value. Axios then becomes the re-exposure point when interceptor code clones the config back into a normal object, which makes the inherited property visible to the adapter again.

Q: What are the signs that Axios outbound traffic may be unsafe?

A: Look for Node.js services using the HTTP adapter, interceptors that return fresh config objects, unexpected proxy settings in request paths, and any dependency that can pollute Object.prototype. If those conditions overlap, treat outbound traffic as potentially redirectable.

Q: What should teams do immediately after discovering vulnerable Axios use?

A: Patch to a fixed Axios release, inventory affected services, and review whether secrets may have traversed plaintext HTTP during the exposure window. Then rotate credentials where request headers, auth fields, or bodies could have been observed by an attacker-controlled proxy.

Technical breakdown

How interceptor cloning reopens prototype pollution risk

Axios hardens request configuration by creating a null-prototype object so inherited properties on Object.prototype are ignored during merge. The weakness appears after that step: a request interceptor can return a new object built with spread syntax or Object.assign, which creates a normal object again. Once that happens, the later dispatch path can read inherited properties from Object.prototype if another dependency has already polluted them. The security problem is not the merge itself. It is the loss of the null-prototype invariant before the request is sent.

Practical implication: Review request interceptors for config cloning that restores a normal prototype before dispatch.

Why the Node HTTP adapter becomes the exposure point

In the Node HTTP adapter path, Axios reads config.proxy during request preparation. If proxy is not an own property on the cloned config, the adapter can resolve it through the prototype chain instead. That means a polluted Object.prototype.proxy can influence outbound routing without changing the application’s explicit request code. Browser adapters are not the same sink, and the advisory limits the clearest impact to Node.js HTTP traffic. The key lesson is that adapter-specific reads determine whether a polluted property becomes an exploitable control decision.

Practical implication: Inventory which Axios adapters your services use and treat the HTTP adapter path as the primary exposure point.

What plaintext interception changes about service trust

The highest-confidence impact is plaintext HTTP traffic in Node.js services, where an attacker-controlled proxy can see headers, request bodies, and Axios-generated authentication material. Even when TLS reduces content exposure, the routing manipulation still breaks trust in the client’s outbound path and can return a forged response body to the caller. This is not just a data leak issue. It is a client-side trust failure that can affect internal APIs, metadata fetchers, and helper services that assume local network traffic is inherently safe.

Practical implication: Identify Node.js services that still send secrets over plaintext HTTP and treat their outbound routing as sensitive.

Threat narrative

Attacker objective: The attacker wants to redirect Node.js outbound requests through a controlled proxy to observe request data and influence responses.

1. Entry occurs when another dependency, parser, or upstream bug pollutes Object.prototype.proxy in the Node.js process.
2. Credential and request metadata become reachable again when an Axios interceptor clones hardened config into a plain object before dispatch.
3. The Node HTTP adapter reads the inherited proxy value and silently redirects outbound traffic through an attacker-controlled proxy.
4. Impact is plaintext request interception, response spoofing, and exposure of headers, bodies, and authentication material from affected services.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prototype pollution becomes a governance problem when a later extension point can restore the attack path. This case shows that hardening at merge time is not enough if interceptors, wrappers, or middleware can reintroduce ordinary object semantics before dispatch. The real control gap is not simply polluted input, but loss of the null-prototype invariant inside trusted application code. Practitioners should treat in-process object hardening as an end-to-end property, not a one-time merge step.

Outbound trust is now part of identity governance for service workloads. When a client library can redirect requests carrying bearer tokens or Basic auth, the identity boundary shifts from authentication alone to the integrity of the request path. That is especially relevant for service accounts, internal APIs, and background jobs that assume local traffic is low risk. Teams need to govern where credentials can travel, not just who can present them.

Immutable coding patterns can create security regressions if they discard security invariants. Spread syntax and Object.assign are normal engineering tools, but here they turned a protected config object back into one that consults Object.prototype. This is a useful named concept for the field: invariant drift through config cloning: a security property survives the first control layer but is lost when later code rebuilds the object without preserving the original shape. Practitioners should add invariant checks around object cloning in security-sensitive client paths.

This issue reinforces that NHI and service-secret governance must include runtime behaviour, not just secret storage. A token can be well managed at rest and still become exposed when request construction is compromised inside the process. That means secret handling, outbound proxy control, and prototype-pollution resistance belong in the same operational conversation. Security teams should review client libraries as part of NHI governance, not as mere application plumbing.

The broader lesson is that adapter choice can determine exploitability more than the vulnerability label itself. Browser paths, fetch-based paths, and Node HTTP adapter paths do not share the same sink behavior, so teams need to model exposure by execution context. That makes this a useful example of why control validation must follow the runtime path, not just the package version. Practitioners should evaluate where library invariants are preserved or dropped across adapters.

What this signals

Invariant drift through config cloning: this is the pattern security teams need to watch for when trusted runtime objects are rebuilt by application code. The issue is broader than Axios because any security-sensitive client path can lose a control invariant if later code returns a fresh object instead of preserving the protected one.

For identity and secret governance, the lesson is to model outbound request construction as part of the credential lifecycle. A bearer token or Basic auth secret that is safe at rest can still be exposed if client-side trust in the routing path is broken inside the process.

For practitioners

• Audit Axios interceptors for object-cloning patterns Look for spread syntax, Object.assign, or wrapper functions that return a fresh config object after Axios has hardened it. Replace cloning in security-sensitive request paths with patterns that preserve the original object shape or reapply null-prototype semantics.
• Pin and verify fixed Axios versions Upgrade affected Node.js services to axios 0.33.0 or 1.18.0 or later, then verify the resolved dependency tree across npm, pnpm, or yarn so transitive copies do not remain in place.
• Map Node HTTP adapter exposure Identify which services use Axios’s HTTP adapter and which still send plaintext HTTP traffic, then prioritise the ones that carry bearer tokens, Basic auth, or request bodies with sensitive data.
• Scan for process-level prototype pollution paths Review parsers, deserialisers, and third-party dependencies that can mutate Object.prototype in the same process, because that prerequisite is what makes the Axios bug exploitable in practice.
• Rotate credentials touched during the exposure window If a vulnerable service handled secrets through Axios on the HTTP adapter, rotate any bearer tokens, Basic auth material, or other credentials that may have been present in outbound request headers or config.auth.

Key takeaways

• Axios prototype pollution matters here because a plain-object clone can undo a hardening step that was meant to keep inherited properties out of outbound request config.
• The exposure is strongest in Node.js services that still use the HTTP adapter and send secrets over plaintext HTTP or internal network paths.
• The control gap is not just patching a vulnerable package, but preserving security invariants across interceptor code and other in-process extension points.

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 Trust Boundary: An outbound trust boundary is the point where a system leaves passive observation and begins initiating network actions based on input it does not fully trust. For scanners and verification services, this boundary determines whether live checks are governed and constrained or left open to abuse.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the runtime paths that actually carry credentials.