CVE-2026-40175 in Axios and the Real Trust Boundary

CVE-2026-40175 looked catastrophic when it first hit public feeds. The public description tied Axios to a gadget chain in which prototype pollution in some other dependency could turn into header injection, request smuggling, SSRF, an AWS IMDSv2 bypass, and in the worst case remote code execution or full cloud compromise. That framing was not invented by blog hype. It came from the official record itself. (NVD)

The story got murkier after disclosure. GitHub’s current advisory metadata shows a Moderate 4.8 score with high attack complexity. OSV mirrors that lower-severity view. GitLab still presents the issue as critical, and the long-form narrative in some official feeds still carries “critical” language. NVD’s current text also says the issue is fixed in Axios “1.15.0 and 0.3.1,” while GitHub, GitLab, OSV, and Axios release references point to “0.31.0.” Those are not cosmetic differences. They change how defenders prioritize the work, what version they deploy, and how much confidence they should place in the first wave of commentary. (NVD)

The right way to read CVE-2026-40175 is not as “Axios equals RCE.” It is a trust-boundary bug. Untrusted or inherited data can become outbound request material. If that data crosses enough boundaries without being normalized or rejected, the result can move from configuration weirdness to real network impact. That is why this CVE still matters even though the public severity picture softened later. Patch it, test the paths that matter in your environment, and harden the surrounding boundaries instead of treating the package bump as the whole response. (GitHub)

The public record changed after disclosure

The disclosure history is unusually revealing. GitHub’s advisory narrative describes a chain from prototype pollution to header injection, request smuggling, SSRF, and AWS metadata abuse. NVD imported that language. But the current GitHub advisory metadata now rates the issue as Moderate 4.8 with attack complexity marked high, and OSV shows the same vector. GitLab, by contrast, still presents the issue as critical and points to the same fixed versions. The result is a live example of why security teams should read both the patch and the record history, not just the latest top-line score. (NVD)

מקור	Public framing today	What it tells defenders
GitHub advisory	Narrative still describes a severe gadget chain, but current metadata is Moderate 4.8	The worst case is still documented, but exploitation is no longer being framed as low-complexity default
NVD	Carries the severe chain description and tracks later record modifications	The official record preserves both the strong initial language and the later changes
OSV	Shows the lower 4.8 severity while still echoing critical wording in details	Public databases can lag or partially normalize the same advisory in different ways
GitLab advisory	Continues to present the issue as critical	Some feeds may stay on the more conservative, worst-case interpretation longer

That table matters because CVE-2026-40175 is not the kind of issue where “critical” or “moderate” alone answers the operational question. A library-level sink with multiple environmental dependencies can be low-friction in one runtime and much harder in another. When that happens, the responsible response is to separate three things: what the advisory says is theoretically possible, what your runtime makes difficult, and what your own network posture still leaves reachable. (NVD)

There is also a version-string problem that defenders should not miss. NVD currently says the bug is fixed in “1.15.0 and 0.3.1,” but GitLab, OSV, and the advisory references align on “0.31.0” for the legacy 0.x line. Axios also published a v0.31.0 release referenced by the official records. The safest interpretation is that 0.31.0 is the relevant legacy fix and that teams should verify against their lockfiles rather than trusting a single database field in isolation. (NVD)

What the bug really is

Axios is not being accused here of spontaneously inventing malicious headers. The advisory describes a gadget chain. The upstream problem begins elsewhere, typically with a polluted object or inherited property that should never have been trusted as real configuration. Axios becomes dangerous when that tainted data crosses into outbound request construction without being treated as hostile input. That is why the advisory language couples Axios to prototype pollution instead of presenting the issue as a pure parser bug inside the library. (NVD)

Axios’s own threat model now reflects that design lesson. It explicitly calls out header injection risk from carriage return and line feed characters, notes that AxiosHeaders rejects \\r ו \\n, and also points out that Node’s http module rejects those characters too. The same threat model discusses read-side prototype pollution gadgets and says many configuration reads are guarded with own-property checks, with regression tests added for that class of issue. In other words, the maintainers are treating the problem as a boundary-management issue across config, headers, proxies, and runtime behavior. (GitHub)

A simple way to understand the boundary problem is to ignore exploitation for a moment and just look at inherited properties:

const inherited = Object.create({
  "x-forwarded-host": "ok\\r\\nInjected: yes"
});

inherited.accept = "application/json";

for (const key in inherited) {
  console.log("seen by loose iteration:", key);
}

console.log(Object.hasOwn(inherited, "accept")); // true
console.log(Object.hasOwn(inherited, "x-forwarded-host")); // false

That is not a weaponized proof of concept, and it is not meant to be. It shows why polluted prototypes are dangerous. If code later iterates loosely with for...in, merges without checking ownership, or treats inherited values as if they were explicit configuration, data that was never supposed to be “real” starts steering request behavior. MDN and OWASP both recommend ownership checks and other prototype-pollution defenses for exactly this reason. (developer.mozilla.org)

The important shift in thinking is this: a request library sits at the boundary where data turns into action. Configuration is no longer inert once it becomes headers, URLs, proxy decisions, or redirect state. That is why outbound HTTP clients deserve the same kind of boundary thinking that teams usually reserve for deserializers, template engines, or ORM layers. CVE-2026-40175 is a useful reminder that “just a client library” can still be a security-critical sink. (GitHub)

Why Node matters more than the headline

The most important technical friction in the public exploit story is Node itself. Node’s official documentation says the http module validates header values automatically, and invalid characters raise an ERR_INVALID_CHAR error. That means a chain that depends on raw CRLF making it all the way into a normal Node HTTP request is already facing a built-in guardrail before Axios adds anything on top. (nodejs.org)

Axios still hardened its own layer. The patch adds assertValidHeaderValue to the Axios header implementation and rejects values containing carriage returns or line feeds before the request is sent. The tests added in the fix cover multiple adapters, including browser, fetch, and Node HTTP paths, and they explicitly assert that requests are rejected when CRLF shows up in header values. That is more than a cosmetic fix. It means validation now happens earlier, closer to the library boundary, and more consistently across runtimes. (GitHub)

A minimal Node example shows the underlying runtime behavior:

import { validateHeaderValue } from "node:http";

try {
  validateHeaderValue("x-test", "ok\\r\\nInjected: yes");
  console.log("header accepted");
} catch (err) {
  console.error(err.code); // ERR_INVALID_CHAR
  console.error(err.message);
}

That behavior is one reason a later third-party analysis challenged the initial worst-case framing. Aikido argued that in standard Node.js environments the chain was not realistically exploitable because Node already blocks CRLF in header values, and it said that assessment was validated with the original reporter. That does not settle the issue universally, and it should not be mistaken for an official retraction. But it does explain why the later severity posture looks more conservative than the first-wave narrative. (אייקידו)

Defenders should resist two lazy conclusions here. The first is “the advisory said cloud compromise, so every vulnerable Axios version is a near-automatic high-severity incident.” The second is “Node blocks CRLF, so the CVE is meaningless.” Both are too crude. Node’s validation makes some paths materially harder. Axios’s own fix closes the sink earlier and across adapters. But the record still describes a real class of trust-boundary failures, and not every deployment is a plain default Node client with no custom transport, proxy, or request-shaping logic in front of it. (GitHub)

The exploit chain depends on several boundaries failing at once

The easiest way to overstate CVE-2026-40175 is to compress the chain into a single label. The advisory itself is longer and more conditional than that. It describes a progression: prototype pollution or a similar upstream taint source, use of that data in Axios request construction, header injection, possible request smuggling or SSRF, possible AWS IMDSv2 abuse, and then a much more environment-specific end state such as credential theft or code execution. Each step adds a condition. (NVD)

Chain stage	What must be true	What often blocks it	What you should verify
Upstream taint	Some parser, merge helper, or config path allows polluted or inherited data into request material	Schema validation, null-prototype objects, own-property checks	Search for loose merges, for...in, dynamic header pass-through
Header sink	Tainted data reaches headers or related request metadata	Axios patch, Node header validation	Unit test with hostile inherited values and CRLF content
SSRF reachability	The service can reach internal or special targets	Egress policy, DNS controls, service mesh, host firewalls	Test access to loopback, metadata IP, internal control planes
IMDS abuse	Metadata endpoint is reachable and protected weakly enough to matter	IMDSv2 required, hop limit, endpoint disabled	Audit instance metadata options, container and proxy topology
End-state escalation	Stolen credentials or internal responses can be turned into more access	Least privilege IAM, short-lived credentials, downstream auth checks	Review IAM scope, trust policies, and secret handling

That table is why CVE-2026-40175 should be read as a chain-of-trust problem instead of a one-line exploit primitive. Any one of those controls can reduce impact materially. The flip side is that patching Axios without checking metadata settings, egress reachability, or polluted object handling leaves too much to chance. A package upgrade closes the library sink, but it does not prove the rest of the path is safe. (GitHub)

The advisory’s mention of request smuggling is best understood in the same conditional way. Injected CRLF in header values is a classic prerequisite for header confusion and, in some stacks, request splitting or smuggling-like behavior. But whether that becomes an actual network exploit depends on what client, adapter, intermediary, and backend parser are in play. In default Node paths, the built-in header validation is a major obstacle. In less standard paths, the right answer is not to assume either safety or compromise, but to test the concrete route your application uses. (GitHub)

Why AWS IMDSv2 appears in the advisory

AWS metadata access is central to the advisory’s worst-case story because cloud credential theft is one of the most valuable SSRF outcomes in real environments. But the reference to IMDSv2 matters precisely because IMDSv2 is harder to abuse than IMDSv1. AWS documents that IMDSv2 is session-oriented. A client first makes a PUT request to obtain a token and then uses that token in a follow-up request header to retrieve metadata. That extra method and header requirement breaks many simple SSRF patterns that would have worked against weaker metadata setups. (docs.aws.amazon.com)

That is why the advisory does not merely say “SSRF to metadata.” It points to an IMDSv2 bypass scenario. For such a chain to work, the attacker needs more than the ability to trigger a plain outbound GET. They need the surrounding request logic to allow method and header manipulation, the environment to allow network reachability to the metadata endpoint, and the instance settings to leave room for the request path to succeed. That is a much narrower claim than “Axios lets attackers dump cloud credentials by default.” (NVD)

AWS gives defenders clear, concrete controls here. You can require IMDSv2 tokens, set the response hop limit, or disable the metadata endpoint entirely when the workload does not need it. Those options are available through the EC2 metadata settings. The combination of “tokens required” and a restrictive hop limit is especially relevant when you worry about requests being proxied or bounced through extra network hops inside containers or layered service stacks. (docs.aws.amazon.com)

A practical hardening baseline looks like this:

# Require IMDSv2 and keep the hop limit tight
aws ec2 modify-instance-metadata-options \\
  --instance-id i-0123456789abcdef0 \\
  --http-tokens required \\
  --http-endpoint enabled \\
  --http-put-response-hop-limit 1

And for workloads that do not need instance metadata at all:

# Disable IMDS entirely
aws ec2 modify-instance-metadata-options \\
  --instance-id i-0123456789abcdef0 \\
  --http-endpoint disabled

Those settings are not Axios-specific, and that is exactly the point. CVE-2026-40175 is one more reminder that application-layer sink fixes and cloud-control hardening belong in the same incident response playbook. If metadata access is disabled or properly constrained, one of the most valuable outcomes in the advisory chain disappears even before the application patch is deployed. (docs.aws.amazon.com)

Why the severity drifted downward

GitHub’s current 4.8 vector assigns high attack complexity. That single change explains a lot. A high-complexity rating fits a chain where multiple boundaries have to align: upstream taint, a reachable sink, runtime acceptance, SSRF reachability, and a valuable downstream target. It does not fit the early impression many readers got from the headline summary, which sounded much closer to a low-friction remote compromise story. (GitHub)

No official source I reviewed gives a plain-language explanation for the score change, so the safest reading is an inference rather than a documented vendor statement. The most plausible interpretation is that later review weighed the conditions more heavily than the original summary did. That view lines up with three concrete facts in the public record: Node already rejects invalid header characters, Axios added explicit header validation of its own, and Axios’s threat model now talks about header injection and prototype-pollution guards as boundary controls rather than presenting a simple direct exploit primitive. (nodejs.org)

This is where the third-party disagreement becomes useful, even if you do not adopt it wholesale. Aikido’s analysis argued that the issue was not realistically exploitable in standard Node.js conditions and tied that assessment to Node’s existing validation behavior. Whether you fully agree or not, that argument is consistent with the later “high attack complexity” posture. It also explains why defenders should care less about the marketing value of a single score and more about whether their own environment looks like the chain the advisory assumes. (אייקידו)

The operational takeaway is simple. Lower severity metadata should change triage tone, not patch discipline. If you run standard Node services with tight egress, IMDSv2 enforced, and no obvious polluted-config sinks, the catastrophic reading is less likely to fit you. If you run legacy code with loose object handling, custom adapters, permissive proxies, or cloud metadata exposure, the later score downgrade is not a license to ignore the issue. (GitHub)

The affected versions and the version-string mess

The most stable reading across the public record is that the current 1.x line is fixed in 1.15.0 and the legacy 0.x line is fixed in 0.31.0. GitLab says exactly that. OSV also lists the 1.x range as introduced in 1.0.0 and fixed in 1.15.0, while marking the 0.x line fixed at 0.31.0. Axios v1.15.0 release notes confirm that the release includes the security fixes relevant here. (advisories.gitlab.com)

The awkward part is NVD’s current description, which says the issue is fixed in “1.15.0 and 0.3.1.” That conflicts with the rest of the official ecosystem. Since GitLab, OSV, the advisory references, and the Axios release path all point to 0.31.0, teams should treat 0.31.0 as the meaningful legacy fix and verify that exact version in package managers, lockfiles, image layers, and SBOMs. This is one of those cases where “official source” does not mean every field across every database is internally consistent. (NVD)

Version line	Publicly affected range	Practical fixed target
Axios 1.x	1.0.0 before 1.15.0	Upgrade to 1.15.0 or later
Axios 0.x	Legacy line before 0.31.0	Upgrade to 0.31.0 or later
Mixed estate with transitive dependencies	Depends on lockfile resolution	Verify the resolved package, not just the root manifest

Axios v1.15.0 is also worth deploying promptly for another reason: the same release includes a fix for a separate NO_PROXY hostname normalization issue, CVE-2025-62718. That issue can force requests through a proxy despite expected exclusions for loopback-like targets. So a single upgrade can close multiple outbound trust-boundary problems at once. (GitHub)

How to find Axios in real estates

The number one inventory mistake during package incidents is checking only the root package.json. Axios is often present as a transitive dependency, sometimes in multiple major lines at once, and sometimes buried in lockfiles or cached build layers long after developers think they have upgraded. Real response work has to include manifests, lockfiles, artifact registries, container layers, and SBOM output. (osv.dev)

For Node package managers, the fast path is still useful:

npm ls axios
pnpm why axios
yarn why axios

grep -n '"axios"' package-lock.json
grep -n 'axios@' pnpm-lock.yaml
grep -n 'axios@' yarn.lock

Those commands tell you where Axios is coming from, but they do not prove the deployed image is clean. Check CI cache layers, prebuilt artifacts, and mirrored registries too. That matters even more in 2026 because Axios also had a March supply-chain incident involving malicious published versions. A build system that resolves “the right range” but pulls the wrong artifact is not really patched. (GitHub)

If you manage dependency policy centrally, use overrides or resolutions to force safe versions while waiting for slower upstream packages to catch up:

{
  "overrides": {
    "axios": "^1.15.0"
  },
  "resolutions": {
    "axios": "^1.15.0"
  }
}

That approach is not glamorous, but it is often the difference between patching a monorepo this week and waiting for every dependent package maintainer to publish. Just make sure the resulting application still passes tests against the stricter header validation behavior introduced by the Axios fix. (GitHub)

How to test the risky path safely

The most productive test for CVE-2026-40175 is not “can I make Axios crash.” It is “can tainted or inherited data influence the request path I actually use.” That usually means four checks: whether inherited properties reach request configuration, whether hostile header values are rejected before the network call, whether the service can reach internal or metadata endpoints, and whether a patched version changes previously silent behavior. (GitHub)

Start with ownership and object-shape checks in your own wrappers. A lot of organizations do not call Axios directly. They build thin abstractions around it, often with convenience logic that merges user input, defaults, auth headers, or tracing data. That wrapper layer is where inherited properties can sneak in.

function buildHeaders(input) {
  const out = Object.create(null);

  for (const key of Object.keys(input)) {
    const value = input[key];
    if (typeof value !== "string") continue;
    if (/[\\r\\n]/.test(value)) {
      throw new Error(`Invalid header content for ${key}`);
    }
    out[key] = value;
  }

  return out;
}

That pattern does two useful things. It works only with own properties because Object.keys ignores inherited values, and it rejects CRLF before the header object reaches the request layer. MDN and OWASP both recommend this kind of ownership-aware handling as part of prototype-pollution prevention. Axios’s own patch now applies comparable validation inside the library, but application-side validation still helps when tainted input flows through wrappers before Axios ever sees it. (developer.mozilla.org)

Then test the network boundary directly. In a staging environment, validate whether the service can reach 169.254.169.254, loopback targets, or internal control endpoints it should never touch. CVE-2025-62718 showed that NO_PROXY edge cases can surprise developers by routing loopback-style targets through a proxy. CVE-2025-27152 showed that absolute URLs can override baseURL in ways that create SSRF and credential leakage risk. A service that is “safe” against one Axios issue but still has overly broad egress remains one boundary failure away from trouble. (NVD)

In larger estates, the hard part is rarely upgrading one service. It is proving that the dangerous path is gone across dozens of apps, wrappers, proxies, and cloud contexts. That is the niche where agentic testing and evidence collection become useful. Penligent has published directly on CVE-2026-40175 and also on what automated offensive validation looks like in 2026. If your team already uses that kind of workflow, fold this CVE into the same retest cycle you use for attack-surface checks and evidence capture, instead of treating it as a one-off package bump with no verification trail. (penligent.ai)

You should also expect patched behavior to flush out bad assumptions in older applications. One reason the Axios maintainers discussed compatibility in the patch thread is that stricter header validation can break code that used to limp along with lax assumptions. That is a security improvement, but it can still surface as a production regression if you do not test it before rollout. (GitHub)

A simple staged validation sequence usually works well:

# Search for loose object handling and dynamic header construction
rg -n "for\\s*\\(" src/
rg -n "Object\\.assign|deepmerge|merge" src/
rg -n "headers\\s*:" src/
rg -n "baseURL|proxy|allowAbsoluteUrls" src/

Then add a small regression test around your own HTTP wrapper. The goal is not to recreate a full exploit chain. The goal is to prove that inherited values are ignored, CRLF headers are rejected, absolute URL usage is intentional, and egress to special targets is either blocked or tightly justified. (GitHub)

Detection and telemetry that matter

One of the cleanest signals after upgrading is error telemetry. Node documents ERR_INVALID_CHAR for invalid header values. Axios’s patched header layer throws earlier as well. If you suddenly see these errors after moving to the fixed version, that is not necessarily a bad patch. It often means the upgrade surfaced request-construction behavior that was always unsafe and previously happened to be silent or inconsistent across adapters. (nodejs.org)

Egress telemetry matters just as much. Watch for attempts to reach 169.254.169.254, loopback-adjacent targets such as localhost. with a trailing dot, or odd proxy traversal patterns around internal destinations. The reason to include those specific shapes is that Axios has already had recent outbound-boundary issues involving metadata and proxy handling, not just CVE-2026-40175. Looking only for the new CVE’s exact pattern is too narrow. (NVD)

If you run a service mesh, egress proxy, or centralized HTTP gateway, keep logs that preserve destination, method, and enough header metadata to identify suspicious flows without overexposing secrets. For IMDSv2 specifically, even failed attempts are informative because the sequence requires a token-oriented request pattern rather than a simple one-shot fetch. That makes abnormal metadata traffic a good detection target even when the attacker does not get credentials out. (docs.aws.amazon.com)

Do not ignore build and artifact telemetry either. The March 2026 Axios supply-chain incident showed how a package problem can be both a code issue and a distribution issue. If a team investigates CVE-2026-40175 and upgrades Axios but never verifies what artifact was actually installed, they are solving only half the real risk surface around the library. (GitHub)

Hardening beyond the patch

The patch is necessary, but it is not the whole defense. The deeper fix is to stop treating outbound request configuration as a casual object merge problem. Use schema-validated inputs, null-prototype containers for sensitive config, explicit allowlists for headers, and ownership checks before data reaches the HTTP client. OWASP’s prototype-pollution guidance and MDN’s Object.hasOwn documentation are both directly relevant here. (cheatsheetseries.owasp.org)

A reasonable application-side pattern looks like this:

const ALLOWED_HEADERS = new Set([
  "accept",
  "content-type",
  "authorization",
  "user-agent"
]);

function normalizeOutboundHeaders(candidate) {
  const clean = Object.create(null);

  for (const key of Object.keys(candidate)) {
    const lower = key.toLowerCase();
    if (!ALLOWED_HEADERS.has(lower)) continue;

    const value = candidate[key];
    if (typeof value !== "string") {
      throw new Error(`Header ${key} must be a string`);
    }
    if (/[\\r\\n]/.test(value)) {
      throw new Error(`Header ${key} contains invalid characters`);
    }

    clean[lower] = value;
  }

  return clean;
}

That kind of explicitness is worth the extra lines. It narrows the sink, makes ownership rules obvious, and stops sensitive network behavior from being steered by arbitrary objects. Axios now rejects CRLF in header values on its own, but application-side control is still valuable because it keeps tainted data from influencing other request attributes before the library ever runs. (GitHub)

On the network side, harden the other boundaries that recent Axios issues keep hitting. If your application makes user-influenced outbound requests, limit or disable absolute URL overrides where appropriate. Axios’s threat model notes that allowAbsoluteUrls: false can prevent relative-path assumptions from being overridden. If your environment inherits proxy settings from the process environment, consider explicitly setting config.proxy = false when the application should not use those paths. Axios’s threat model calls out both absolute URL handling and proxy-env hijack concerns. (GitHub)

Cloud hardening belongs in the same checklist. Require IMDSv2, keep the hop limit tight, or disable metadata when the workload does not need it. That is not a substitute for patching Axios. It is a way to remove one of the highest-value outcomes from a whole family of SSRF-like paths, whether they originate in Axios, some other client library, or application code. (docs.aws.amazon.com)

Related Axios CVEs that point to the same design lesson

CVE-2026-40175 makes more sense when placed next to recent Axios issues. The pattern is not “Axios has one weird bug.” The pattern is that outbound HTTP clients sit at the intersection of URL control, header trust, proxy behavior, and credential handling. When those boundaries are loose, the impact can range from token leakage to SSRF to cloud exposure. (NVD)

CVE	Core issue	מדוע זה חשוב	Fixed version
CVE-2026-40175	Polluted data can flow into header-related request behavior	Turns untrusted object state into outbound request risk, with a worst-case chain toward SSRF and cloud abuse	1.15.0 and 0.31.0 in practice
CVE-2025-62718	NO_PROXY hostname normalization mismatch	Requests to loopback-like targets can go through a proxy unexpectedly, enabling proxy bypass and SSRF	1.15.0 and 0.31.0
CVE-2025-27152	Absolute URL overrides baseURL expectations	User-controlled absolute URLs can redirect outbound traffic and leak credentials	1.8.2
CVE-2023-45857	XSRF token sent to any host	Sensitive request metadata can leak across origin boundaries	1.5.1 was affected

CVE-2025-27152 is relevant because it shows how URL composition assumptions fail in real code. Developers often think baseURL confines requests to a trusted target, but Axios sent requests to absolute URLs when given one, creating SSRF and credential-leakage risk. That is the same trust-boundary lesson from a different angle: application intent is not a control unless the library and wrapper logic enforce it. (NVD)

CVE-2025-62718 is even closer to the present issue because it involves loopback and internal-service reachability through proxy behavior. If you are patching for CVE-2026-40175 and skipping the NO_PROXY fix, you are still leaving one of the surrounding outbound trust boundaries weaker than it should be. That is why the v1.15.0 release matters beyond a single advisory. (NVD)

CVE-2023-45857 rounds out the picture from a credential-handling angle. In that issue, Axios 1.5.1 could expose the XSRF token by including it in the X-XSRF-TOKEN header on requests to any host. That is not the same bug class, but it reinforces the same operational lesson: outbound clients do not just carry bytes. They carry trust decisions. (NVD)

The March 2026 supply-chain incident is separate, but it changes response priorities

Late March 2026 brought a separate Axios incident that should change how teams handle any Axios security work from this period. The maintainers disclosed that malicious versions 1.14.1 and 0.30.4 were published after a maintainer account compromise, remained live for roughly three hours, and pulled in a malicious plain-crypto-js dependency. The project’s postmortem recommended grepping for the malicious package and treating systems that installed those versions as potentially compromised. (GitHub)

That incident is not CVE-2026-40175, and it should not be conflated with it. But in real response work the distinction does not let you ignore either problem. Teams that upgrade Axios during this period need to answer two separate questions: did we eliminate the vulnerable sink, and did we verify the integrity of the artifact we deployed. A successful package upgrade that lands on a tainted build is not a successful remediation. (GitHub)

This is another place where evidence-driven retesting matters more than optimistic package management output. Know which version resolved, know which tarball was installed, know which environments got it, and keep enough provenance to prove the answer later. That discipline is not glamorous, but 2026 has already given defenders too many reasons to stop treating dependency upgrades as a single-command trust exercise. (GitHub)

Common mistakes during remediation

The first mistake is treating the current score as the whole truth. CVE-2026-40175 is a perfect example of why that fails. The record changed after disclosure, and different feeds still present different severities. If you look only at the harshest summary, you may overreact. If you look only at the later 4.8 score, you may under-test the paths that still matter. Read the patch, the runtime behavior, and the environment assumptions together. (NVD)

The second mistake is patching Axios while leaving the surrounding boundaries untouched. If a service can still reach internal assets freely, if IMDS is still looser than it should be, if absolute URLs are still too permissive, or if proxy inheritance is still accidental, then the next outbound-client issue will land harder than it needs to. Axios’s own threat model and recent CVE history make that pattern hard to ignore. (GitHub)

The third mistake is checking only direct dependencies. Axios frequently arrives transitively, and public version strings can be inconsistent across feeds. Inventory the resolved package, not just the top-level declaration. Verify it in your lockfiles and deployed artifacts, not only in source control. (osv.dev)

The fourth mistake is treating stricter validation as a regression to suppress. If a patched version now throws on an invalid header that used to slide through, that is usually evidence of unsafe request construction. Fix the calling code. Do not blindly work around the validation unless you are prepared to explain why your application legitimately needs header values that the runtime and the library both consider malformed. (nodejs.org)

The fifth mistake is mixing the March 2026 supply-chain incident into the CVE itself and then drawing the wrong conclusion from the confusion. One is a package-distribution compromise. The other is a security flaw in request handling. They are separate issues with overlapping operational response steps. Treat them as separate tracks and verify both. (GitHub)

What defenders should conclude

CVE-2026-40175 is not best understood as a single, universal “Axios RCE.” The official record describes a severe worst-case chain, but the current public severity posture, Node’s own header validation, Axios’s hardened patch, and later technical disagreement all point to a more conditional reality. In standard Node environments, the most dramatic exploit story is harder than early summaries implied. That does not make the issue unimportant. It makes it a boundary problem that has to be tested, not guessed. (NVD)

The right response is disciplined and boring in the best way. Upgrade to the fixed line. Confirm the resolved version in your real artifacts. Test your wrappers for inherited-property handling. Verify that CRLF-bearing header values are rejected. Audit whether the service can reach metadata and internal targets. Require IMDSv2 or disable metadata. Review absolute URL and proxy behavior. That is how you turn a fuzzy multi-stage advisory into concrete risk reduction. (advisories.gitlab.com)

The broader lesson is bigger than one CVE. Outbound HTTP clients are trust boundaries. They sit where user influence, application defaults, proxy logic, redirects, credentials, and cloud environment assumptions all meet. Whenever a library in that position changes how it validates input, defenders should pay attention even if the final score looks lower than the headline did on day one. (GitHub)

לקריאה נוספת

• GitHub advisory for CVE-2026-40175. (GitHub)
• NVD record for CVE-2026-40175, including change history. (NVD)
• GitLab advisory for CVE-2026-40175. (advisories.gitlab.com)
• OSV entry for CVE-2026-40175 and affected version ranges. (osv.dev)
• Axios v1.15.0 release notes. (GitHub)
• Axios patch and tests for header validation. (GitHub)
• Axios threat model. (GitHub)
• Node documentation for header validation and ERR_INVALID_CHAR. (nodejs.org)
• AWS IMDSv2 documentation and metadata hardening options. (docs.aws.amazon.com)
• NVD entries for related Axios issues, CVE-2025-62718, CVE-2025-27152, and CVE-2023-45857. (NVD)
• Axios March 2026 supply-chain postmortem. (GitHub)
• Penligent on CVE-2026-40175. (penligent.ai)
• Penligent on automated offense workflows in 2026. (penligent.ai)