CVE-2026-104935 — the Ivanti Connect Secure auth bypass added to CISA KEV on October 13 — isn’t a new vulnerability. It’s a new instance of an old pattern: an appliance accepts a request as authenticated because a spoofable header or cookie matches a trusted value, and the check happens on a code path separate from the real login flow.

CWE-290 (Authentication Bypass by Spoofing) describes it precisely. The attacker forges the signal the appliance uses to confirm identity, and the appliance treats the forged signal as genuine. No password. No session. Just a crafted header.

Why this keeps happening

Identity appliances — VPN gateways, SAML IdPs, API gateways, management consoles — sit between unauthenticated traffic and privileged operations. They need to decide: is this request from someone who already logged in?

The naive answer is “check the session cookie.” But session cookies expire. Users come back. So appliances introduce “remember me” tokens, SAML assertions, client certificates, or internal forwarding headers. Each new mechanism is a new check. Each new check is a new code path. And each code path has a chance of accepting input it shouldn’t.

The pattern:

  1. Two paths to the same resource. The normal authenticated path and a secondary path (forwarding header, cached token, SAML assertion, internal proxy header).
  2. The secondary path is checked first. It says “trusted” and short-circuits the real auth.
  3. The attacker controls the secondary signal. Either the header isn’t validated against a shared secret, the cookie isn’t bound to a session, or the SAML issuer isn’t checked.
  4. The secondary path is forgotten during maintenance. The primary auth path is well-tested. The secondary path lives in a utility function nobody looks at after the initial PR.

CVE-2026-104935 follows this exactly. Ivanti’s advisory says the bypass “uses a path separate from normal authentication.” The attacker crafts a request that hits that path, spoofs the trust signal, and the appliance executes commands without a login.

Other examples

This isn’t isolated. The same pattern shows up across vendors:

  • Citrix NetScaler (CVE-2020-8193): A forward-compatibility header (CitrixGatewaySessionPresenceRequest) triggered a code path that returned “authenticated” for any request, bypassing session validation entirely. CVSS 9.8. Patched by adding the header check to the session validation logic.

  • SolarWinds Orion (CVE-2020-12817): An AuthenticationCookie header could be set by the attacker to a forged cookie value, bypassing the normal authentication check. CVSS 9.8. The cookie wasn’t validated against the session store.

  • Apache Struts (CVE-2019-0230): A query parameter action: prefix triggered an OGNL evaluation path that bypassed the normal type conversion, allowing expression injection in URL parameters. CVSS 9.8.

  • CVE-2026-55040 (SharePoint JWT Handler): A secondary JWT validation path accepted a forged token with a null entity ID, trusting the IdP without verifying the issuer. CVE-2026-55040, CVSS 9.1.

Each one is CWE-290. Each one exploits a secondary auth path. Each one is CVSS 9.1–9.8 because unauthenticated command execution or data access is the result.

What the CVSS tells you (and what it doesn’t)

CVE-2026-104935 scored 8.6 (High) on CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L.

That’s accurate but misleading. “High” suggests a researcher found something worth fixing in the next release. The reality: unauthenticated remote command execution on a network-facing appliance, exploited in the wild, added to CISA KEV with a 72-hour due date.

CVSS measures impact and exploitability in isolation. It doesn’t measure how many appliances run the vulnerable version, how exposed they are, or how easy the exploit is for a scripted attacker. For that you need KEV (is it being exploited now?) and EPSS (what’s the probability?).

When CWE-290 appears in a network-accessible appliance with AV:N and AC:L, it’s almost always P1 until proven otherwise.

How to detect it

Detection is straightforward because spoofing leaves a signature: a request arrives on a secondary path with a valid-looking auth signal but no corresponding session entry.

1. Enable logging on all secondary auth paths (headers, cookies, tokens).
2. For each request that bypasses auth via a secondary path, check: does a session entry exist?
3. Alert when the secondary-path bypass count exceeds normal baseline.

For Ivanti specifically: look for requests to the command execution endpoint (pmcgi.exe or similar) with a valid-looking AuthenticationCookie or forwarding header but no session cookie in the same request. These are the spoofed requests.

The fix (and why it’s usually simple)

The fix for auth-by-spoofing is rarely architectural. It’s almost always one of:

  1. Validate the spoofable signal against the session store. Don’t trust the cookie/headers alone — check that the session exists and matches.
  2. Add a shared-secret check. The appliance signs the header with a secret; the validator checks the signature.
  3. Check the issuer. If the signal is a SAML assertion or JWT, verify the issuer is trusted, not just present.
  4. Merge the paths. Make the secondary path feed into the primary auth logic instead of short-circuiting it.

CVE-2026-104935 was fixed in Ivanti 25.1.3.0 (and backported to 25.1.1.2, 22.8R2.5) by ensuring the spoofable signal is validated against the session store before granting access.

Why you should care right now

Ivanti Connect Secure is deployed at thousands of organizations as their primary VPN gateway. The 22.8.X bridge release line (which Ivanti had not fully patched at the time of the advisory) was particularly exposed. The KEV due date was October 16, 2026 — three days from the CISA listing.

But the broader lesson: audit your appliances for secondary auth paths. Every VPN, every SAML IdP, every API gateway has at least one. The question isn’t whether it can be spoofed. It’s whether you’ve tested it.

Further reading