CVE-2026-104935 is an authentication bypass in Ivanti Connect Secure that lets an unauthenticated attacker run commands. Chained with CVE-2026-111357 and CVE-2026-118527, it was exploited from October 3, 2026, before most versions had a fix. You are exposed if an internet-facing appliance runs a build below 22.8R2.6 or 25.1.1.3, or any 25.1.2 build.
What is CVE-2026-104935?
It is the front door of a three-step chain against Ivanti Connect Secure (ICS), Ivanti's SSL VPN gateway. Ivanti rates it 8.6 (High): "authentication bypass by spoofing" that allows "a remote unauthenticated attacker to execute arbitrary commands."
Ivanti says exploitation happened when three CVEs were chained:
| CVE | What Ivanti says it is | CVSS (Ivanti) |
|---|---|---|
| CVE-2026-104935 | Authentication bypass by spoofing. Remote, unauthenticated command execution. | 8.6 High |
| CVE-2026-111357 | Missing authentication for a critical function. A local authenticated attacker escalates privileges (Volexity: to root). | 8.8 High |
| CVE-2026-118527 | Predictable filenames. A remote authenticated attacker uploads files with attacker-controlled content to a known location on disk. | 4.3 Medium |
On their own, the second and third need a foothold. The first one provides it. That is why a "medium" sits in a chain CISA treats as urgent.
Volexity, which found the activity, tracks the attacker as UTA0576. On the appliance it investigated, the actor used no webshell. It ran commands through the exploit chain itself, pulled stored LDAP credentials, queried Active Directory for LAPS passwords and BitLocker recovery keys, sprayed passwords, captured LDAP traffic, and selectively deleted log entries. Volexity assesses with medium confidence that the actor uses large language models for exploit development and post-exploitation work.
When was it disclosed, and was it exploited before the patch?
Yes. Exploitation started ten days before any fix existed for the 22.8 line, and the privilege escalation stayed unpatched for another 16 days after disclosure.
| Date (2026) | What happened |
|---|---|
| July | Ivanti fixes part of the flaw in 25.1.3.0, found by its own product security program. It is still backporting to other lines when exploitation starts. |
| Oct 3 | UTA0576 starts exploiting an appliance on 22.8R2.4, the latest build for that line at the time (Volexity). |
| Oct 5 | Volexity starts investigating at a monitoring customer. |
| Oct 13 | Ivanti discloses CVE-2026-104935 and ships 25.1.1.2, 25.1.3.x and 22.8R2.5. CISA adds it to KEV the same day. |
| Oct 16 | KEV remediation due date for CVE-2026-104935. |
| Oct 29 | Ivanti adds CVE-2026-111357 and CVE-2026-118527 and ships 25.1.1.3 and 22.8R2.6. |
| Oct 30 | CISA adds both to KEV and revises its alert. |
| Nov 2 / Nov 13 | KEV due dates for CVE-2026-111357 and CVE-2026-118527. |
| Jan 31, 2027 | End of life for the 22.7 and 22.8 lines (Ivanti). |
Zero days from disclosure to KEV is not unusual for this kind of device. In our analysis of CISA's 2026 data, 27% of new CVEs were confirmed exploited on the day they were published or earlier, and that same-day list is mostly VPNs, firewalls and gateways.
Does it matter for you? Three questions
Answer these in order. A "no" on the first one ends the conversation; a "yes" on all three is an incident, not a ticket.
- Is it exposed? Does a Connect Secure portal of yours answer from the internet? Not what the CMDB says. What actually responds. VPN gateways are internet-facing by design, so for most ICS customers the answer is yes.
- Is it exploited? Yes. Ivanti, Volexity and CISA all confirm exploitation in the wild, and all three CVEs are in KEV. CVSS 8.6 undersells this. A confirmed exploited vulnerability outranks a theoretical 10.
- Is it exploitable here? That comes down to version. CVE-2026-104935 needs no credentials and no special configuration that Ivanti mentions. If the build is in the affected range and the portal answers, assume it is exploitable.
How do you check exposure from the outside without exploiting anything?
Inventory, reachability, version. None of it requires sending exploit traffic, and you shouldn't.
- Find every portal. Pull hostnames from your DNS zones, certificate transparency logs, your attack surface tool and the firewall rules that NAT to the appliance. Look for the ones you forgot: the DR site, the acquired company's VPN, the lab box.
- Confirm it answers. From a network outside your perimeter, open the user sign-in page in a browser. Connect Secure portals sit under the
/dana-na/path. A normal page load is all you need. - Check the admin interface separately. If the admin sign-in page loads from a home connection, that is a finding of its own, whatever the version.
- Read the version from the admin console. External fingerprints from static files or headers are a hint, not proof. Until the console says otherwise, treat "unknown" as vulnerable.
- Compare with the fixed builds. Below 22.8R2.6, below 25.1.1.3, or anything on 25.1.2.x means you still need to act. 25.1.3.0 and later, and 22.7.x and lower, are outside the affected ranges.
The question that matters is "do we have one exposed?", and it should take hours, not days. In most organizations we talk to, it takes days, because the answer is spread across five tools and none of them looks at the perimeter the way an attacker does.
How do you fix it, and what if you were already exposed?
Upgrade to a resolved build, then investigate as if the appliance was reachable during the window, because it probably was.
Ivanti's guidance: move 22.8 customers to 25.1.1.3 or later, or to 22.8R2.6 if they can't move yet. ISA6000 and ISA8000 on 25.1.1.1 go to 25.1.1.3. 25.1.3.0 requires the new ISA4500, ISA6500 or ISA8500 platform, or a rebuild from the 25.1.3.0 template for virtual and cloud devices. Plan the 25.1 migration before January 31, 2027.
If a vulnerable appliance answered from the internet after October 3, patching is not the end. CISA warns that Ivanti's Integrity Checker Tool may not detect exploitation because the commands run in memory, and Volexity reported that it didn't. CISA's recovery steps:
- Back up the configuration.
- Factory reset and upgrade. For cloud and virtual systems, rebuild the instance.
- Restore the configuration.
- Reset passwords for all accounts, including domain, administrator and local accounts.
- Revoke and reissue stored certificates, and reset stored API keys and license server credentials.
For hunting, Volexity published the request patterns, including welcome.cgi requests whose X-DSCGI-PATH header doesn't match the URL path, plus artifacts in /tmp/. The actor deleted log entries, so a clean log is not proof of a clean box. Look at what the appliance did on your network, too: lateral movement and LDAP queries from the VPN's own address.
A fix in one code line is not a fix for you. Ivanti had part of this patched in July on the new platform. Appliances on the older lines were still exposed in October.
A "medium" in a chain is not a medium. CVE-2026-118527 scores 4.3 on its own and was part of an exploited path to root.
The VPN holds the keys. The actor went for LDAP credentials and AD secrets first. Rotate them if you were exposed.
FAQ
Was CVE-2026-104935 exploited as a zero-day?
Yes. Volexity saw exploitation from October 3 on an appliance running 22.8R2.4, the latest build for that line. Fixes for the affected lines shipped on October 13. The privilege escalation in the same chain, CVE-2026-111357, was fixed on October 29.
Which versions are affected?
CVE-2026-104935: 25.1.1.1 and prior, 25.1.2.2 and prior, 22.8R2.4 and prior. CVE-2026-111357 and CVE-2026-118527: 25.1.1.2 and prior, 22.8R2.5 and prior. 25.1.1.3, 22.8R2.6 and 25.1.3.0 or later resolve all three. Ivanti says 22.7.x and lower are not affected.
Will the Integrity Checker Tool catch it?
Not reliably. Volexity says it missed the modifications on the appliance it investigated. CISA says to use network and memory forensics.
Is patching enough?
Only if the appliance was never reachable while vulnerable. Otherwise, follow CISA's recovery steps and rotate every credential the appliance could see.
How do I check without running an exploit?
Find every portal hostname, confirm from outside that it answers, read the version from the admin console, and compare it with the fixed builds above.
Sources
- Ivanti, Security Advisory Ivanti Connect Secure (CVE-2026-104935) (October 13, 2026, updated October 29, 2026)
- Volexity, A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days (October 13, 2026, updated October 29, 2026)
- CISA, CISA Urges Patching Newly Exploited Vulnerability in Ivanti Connect Secure (October 13, 2026, revised October 30, 2026)
- CISA, Known Exploited Vulnerabilities Catalog, catalog version 2026.10.30
- CVE Program, CVE-2026-104935, CVE-2026-111357, and CVE-2026-118527 records; NIST NVD, CVE-2026-104935
- Rapid7, Ivanti Connect Secure zero-day exploited in the wild (CVE-2026-104935) (October 13, 2026)
- Cylent, Time to exploit in 2026 (CISA KEV analysis, updated monthly)