Ivanti Connect Secure CVE-2026-104935: exploited auth bypass, patch now

Ivanti disclosed CVE-2026-104935 on October 13, 2026: an authentication bypass by spoofing in Ivanti Connect Secure that lets a remote, unauthenticated attacker execute arbitrary commands on the appliance. Ivanti scored it CVSS 8.6 and — this is the part that moves it to the top of the queue — confirmed it is already being exploited, "affecting a limited number of customers at the time of disclosure," with credit to Volexity for assistance. CISA added it to the Known Exploited Vulnerabilities catalog the same day and set a federal remediation deadline of October 16.

Developing story — first published 17:23 CEST (15:23 UTC), October 13, 2026. Updated as the vendor and CISA publish more.

Update — October 13, 2026 23:32 CEST

Three things firmed up in the hours after first publication, all from primary sources:

• NVD finished its analysis. The NVD record is now in the Analyzed state with a published CVSS 3.1 vector, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L, and NVD's own base score of 8.6 High matches Ivanti's — network-reachable, low complexity, no privileges, no user interaction. NVD's CISA-ADP decision scores it exploitation: active, automatable: yes, technical impact: total. "Automatable: yes" is the one to watch: it is the property that turns a limited campaign into untargeted mass scanning.
• CISA now requires forensic triage. The KEV entry (catalog version 2026.10.13) carries forensicTriage: Yes — federal agencies must preserve and examine evidence, not just patch, ahead of the October 16 deadline. Treat that as the baseline for everyone, not only civilian agencies: an exploited auth bypass on a device that edits its own logs is exactly the case where "patched, case closed" hides a live intrusion.
• Unchanged: still no public proof-of-concept, no CVE-specific IOCs from Ivanti, and no named threat actor beyond the Volexity credit.

At a glance

CVE	CVE-2026-104935
Product / affected versions	Ivanti Connect Secure · 25.1.1.1 and prior · 25.1.2.2 and prior · 22.8R2.4 and prior (22.7R2.14 and prior not affected)
Fixed in	25.1.1.2 · 25.1.3.0 and 25.1.3.1 · 22.8R2.5 — disclosed October 13, 2026
CVSS	8.6 High · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L · NVD and Ivanti (CNA) agree
Exploited in the wild	Yes · Ivanti confirms limited exploitation at disclosure; Volexity credited; NVD/CISA SSVC: exploitation active, automatable
CISA KEV	Added 2026-10-13; federal due date 2026-10-16 (BOD 26-04, forensic triage required)
Public PoC	None public as of October 13, 2026
Official advisory	Ivanti October 2026 Security Update

What happened

The weakness is classed as CWE-290, authentication bypass by spoofing: the appliance can be convinced an unauthenticated request carries an identity it never proved. From there the attacker reaches functionality that should sit behind the login, and — per CISA's own summary — turns that access into arbitrary command execution. Ivanti's 8.6 is a High, not a 10, but the number undersells the operational reality: no credentials, remote, and the target is the device that terminates your remote-access tunnels and sees every session that crosses it.

Ivanti says exploitation is limited so far and that it is working directly with affected organizations. That framing is the start of the window, not the all-clear. Ivanti Connect Secure has been one of the most reliably exploited edge products of the last two years; the April 2025 CVE-2025-22457 campaign was tied by Ivanti and Mandiant to the China-nexus actor UNC5221, with non-persistent droppers targeting the /home/bin/web process and anti-forensics built in. "Limited at disclosure" is how most of those started.

Who is exposed — and how to check your version

Three branches are in scope, each with its own fixed build. The one fact that cuts against panic: Ivanti states the flaw does not affect 22.7R2.14 or prior.

Affected branch	Fixed in
25.1.1.1 and prior (ISA6000 / ISA8000)	25.1.1.2
25.1.2.2 and prior	25.1.3.0 or 25.1.3.1
22.8R2.4 and prior	22.8R2.5

Read your running build from the admin console (System → Status) or the device's maintenance page. Note that 22.7 and 22.8 both reach end of life on January 31, 2027 — if you are on either, the fixed build is a bridge, not a destination.

Remediation

There is no workaround. For an actively exploited auth bypass on an internet-facing concentrator, the honest runbook assumes exposure until proven otherwise.

1. Am I affected? Inventory every Connect Secure appliance, internal and perimeter, and read each build against the table above. Anything on 25.1.1.1-and-prior, 25.1.2.2-and-prior, or 22.8R2.4-and-prior is vulnerable. Prioritize the ones reachable from the internet.
2. Patch — exact fixed versions. Upgrade to 25.1.1.2, 25.1.3.0 / 25.1.3.1, or 22.8R2.5 for your branch. Ivanti also recommends moving 22.8.x estates onto 25.1.1.2 or later rather than lingering on a build weeks from end of life.
3. Can't patch this hour? Reduce exposure. No vendor workaround exists, so shrink the attack surface: restrict management-interface access to trusted IPs, and where you can, pull the web/VPN front end behind an allowlist or a filtering layer until the upgrade lands. Treat the gap as hostile, not quiet.
4. Hunt for compromise. Ivanti has not published CVE-specific IOCs for CVE-2026-104935, so do not wait for a hash list. Run the Integrity Checker Tool (ICT) — but read the next section first, because on a compromised ICS the ICT is exactly what a competent intruder neutralizes. Map the hunt to MITRE ATT&CK T1190 (Exploit Public-Facing Application), T1556 (Modify Authentication Process — the spoofing primitive itself), T1505.003 (Web Shell), and T1070 (Indicator Removal) — the last because Ivanti post-exploitation has historically erased its own tracks on the box.
5. Eradicate and verify. If the ICT or your network evidence shows tampering, Ivanti's standing guidance is a factory reset followed by redeployment on a fixed build — patching over a live implant does not remove it. Then rotate everything the appliance could have handled while exposed: VPN session secrets, admin credentials, any certificates or API keys stored on or reachable from it, and the directory credentials it authenticates against. Confirm clean after the rebuild, not before.

Detection and hunting — why the box can't be the only witness

Here is the uncomfortable property of this class of bug. An authentication-bypass-to-command-execution on the appliance means the attacker's first prize is the very system you would ask "were you compromised?" Ivanti's ICT runs on the device; the logs you would review are on the device; and the documented UNC5221 playbook on this product includes defeating integrity checks and running non-persistent, self-deleting droppers. When the witness and the suspect are the same machine, one honest source of truth remains.

"The ICT came back clean." "The ICT runs on the box the attacker already owns. What did the wire show — did that appliance open sessions inward it has never opened before?"

That is the detection you can trust: the traffic the concentrator generates toward the inside of your network. A compromised VPN gateway betrays itself not by a signature but by behavior — a device that historically only terminated inbound tunnels suddenly initiating outbound or lateral connections, beaconing to an unfamiliar ASN, or fanning out to internal hosts it never spoke to. This is precisely the gap Zero Hunt's AI Traffic Analysis pillar was built for: a proprietary deep-learning model with four parallel inference heads (suspicious traffic, malware classification, attack-type identification, application fingerprinting), trained on billions of PCAP sequences and running locally on the appliance GPU at 2.7+ Gbit/s. It profiles what normal looks like in front of your Ivanti gateway, so the pivot inward surfaces while it is happening — not in next morning's SIEM digest, and not dependent on a self-report from a device the intruder controls.

Patching closes the door; it does not tell you whether someone already walked through. That is the second question an autonomous AI red team answers. Because no public PoC exists for CVE-2026-104935 and Ivanti's patches on this product have been bypassed before, Zero Hunt's 10-agent swarm fingerprints the exact Connect Secure build and has a sealed coding agent generate a per-target proof-of-concept against it in an ephemeral container — black-box, the way an unauthenticated attacker meets the login-free path — to show whether the bypass actually lands on your appliance and whether the upgrade genuinely closed it. It runs on-premise on private models, so nothing about the device under test leaves your rack, and every exploitation step waits on a human-in-the-loop gate. The result is a reproduced, signed finding filed with the campaign — evidence, not a version string copied into a ticket. If your validation cadence is still an annual engagement, our note on automated penetration testing covers why edge-appliance disclosures demand a faster loop, and our earlier CitrixBleed 3 analysis shows this is a recurring pattern across remote-access gear, not an Ivanti quirk.

What is not known yet

As of this update (see the Update section above, which supersedes what first publication could not confirm): Ivanti has published no CVE-specific IOCs, no named threat actor beyond crediting Volexity for assistance, and no customer count beyond "a limited number." CISA's KEV entry lists no known ransomware use. There is still no public proof-of-concept. We will keep updating this post as exploitation attribution, IOCs, or a public PoC land.