CVE-2026-104935: Ivanti Connect Secure Zero-Day Gives Root Access

What happened: Volexity disclosed on October 13, 2026 that a threat actor it tracks as UTA0576 chained three Ivanti Connect Secure zero-day vulnerabilities to get unauthenticated, root-level access on a fully patched VPN appliance running version 22.8R2.4. Exploitation began October 3, 2026. Two of the three bugs are now tracked under a single CVE, CVE-2026-104935, rated 8.6 on the CVSS 3.0 scale; the third, a privilege-escalation flaw that completes the chain to root, has no CVE number and no patch yet. CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog the same day, with a remediation deadline of October 16, 2026, for federal agencies. If you run Ivanti Connect Secure, treat this as urgent: patch now, then assume compromise and hunt.

What Volexity found

Volexity says it began investigating suspicious activity on an Ivanti Connect Secure appliance belonging to one of its network security monitoring customers in early October 2026. The appliance was running 22.8R2.4 — the newest available build at the time — yet Volexity found clear evidence of successful, unauthenticated exploitation reaching root. In its October 13 report, Volexity attributed the intrusion to an actor it had not previously tracked, designated UTA0576, and said exploitation of the chain had been occurring since at least October 3, 2026.

This is a new, more serious turn in a story Pandromeda covered briefly around the CISA deadline on October 16. What has become clear since is the scale of what the attacker actually did on compromised boxes — not just gaining a foothold, but running a structured credential-harvesting operation against Active Directory while actively erasing its own tracks.

The three chained flaws

Volexity’s analysis describes the chain as three distinct bugs, each handling a separate stage of the compromise. Ivanti has so far issued one public CVE identifier, CVE-2026-104935, which per Ivanti’s own security advisory covers the authentication-bypass and remote-code-execution components. The third bug, a privilege-escalation flaw used to reach root, has not yet been assigned a CVE and has no available patch.

Because the first two bugs share a single CVE number, CVSS 8.6 (vector CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L per vendor and security-research reporting) describes the authentication bypass and code-execution portion of the chain rather than the full root-level impact Volexity observed in the wild. Ivanti has said it is still working on a fix for the third, privilege-escalation component and that one is planned for a future release.

Affected and fixed versions

Ivanti’s advisory lists Ivanti Connect Secure version 22.8R2.4 and prior, 25.1.1.1 and prior, and 25.1.2.2 and prior as affected by CVE-2026-104935 (also tracked in the National Vulnerability Database). Versions 22.7.x and earlier are not affected. The fixed releases are:

Notably, Ivanti told researchers it had already fixed part of the underlying issue internally in an earlier release (reporting on Ivanti’s advisory points to July 2026’s 25.1.3.0 build), before the full severity of the chain — and the fact it was already being exploited against a fully patched appliance — was understood. Because the privilege-escalation component remains unpatched, upgrading alone does not fully close the chain; it removes the unauthenticated entry point but Ivanti has not yet shipped a fix for the root-level escalation bug.

What the attacker did after breaking in

Once UTA0576 had root on a compromised appliance, Volexity says the group ran a deliberate, credential-focused post-compromise operation rather than immediately trying to move laterally or deploy ransomware. Observed activity included:

• Custom Kerberos tooling: a custom Python-based Kerberos utility, including Kerberoasting capability, used for credential testing against the victim’s domain.
• Active Directory password spraying: a helper script run against AD accounts, with results exfiltrated from the appliance.
• LAPS and BitLocker targeting: a custom Python LDAP tool that used the appliance’s own AD service account to search specifically for Local Administrator Password Solution (LAPS) passwords and BitLocker recovery keys, exporting results as compressed, encoded JSON.
• Authentication log review: searching stored logs on the appliance for valid usernames to inform further attacks.
• Traffic capture: renaming the tcpdump binary to disguise it, then capturing LDAP traffic to harvest plaintext credentials, HTTP Basic auth, and NTLM hashes.

What stands out most to Volexity’s researchers is what the attacker did not do: it never dropped a persistent backdoor or web shell on the device. Instead, UTA0576 re-ran the entire three-stage exploit chain for every single command it wanted to execute, passing commands and retrieving output directly over the same HTTPS requests used to exploit the appliance. Portions of the patch bypass modified code only in memory and restored configuration state (DSCache) afterward, which is why Ivanti’s Integrity Checker Tool — designed to flag unauthorized file-system changes — did not reliably catch the activity. The actor also removed its own entries from the appliance’s debug log and the underlying Linux audit log to cover its tracks.

Who is UTA0576, and what is the motive?

UTA0576 is a designation Volexity uses for a threat cluster it had not previously tracked; it is not yet linked publicly to a known ransomware crew, access broker, or nation-state group. Volexity explicitly flags its motive assessment as an assessment, not a confirmed fact: the firm says it has only low confidence that UTA0576 is financially or criminally motivated rather than conducting espionage, because the operation was detected and disrupted before its ultimate objective became clear. Separately, Volexity says the pattern of post-exploitation activity — heavy focus on domain credentials, LAPS, and BitLocker keys — is consistent with preparation for broader lateral movement inside the victim’s network, though again that is Volexity’s assessment of intent rather than a confirmed next stage that was observed.

Ivanti, for its part, has said only that it is aware of exploitation in the wild prior to public disclosure, affecting “a limited number of customers,” and that its investigation is ongoing.

CISA’s KEV listing and what the deadline means

CISA added CVE-2026-104935 to its Known Exploited Vulnerabilities catalog on October 13, 2026, listing it as an “Ivanti Connect Secure Authentication Bypass by Spoofing Vulnerability” and setting a remediation due date of October 16, 2026, for Federal Civilian Executive Branch agencies under Binding Operational Directive 26-04. KEV listings legally bind only federal agencies to that timeline, but security teams across the private sector widely treat a KEV addition — especially one tied to a VPN appliance already confirmed exploited against a fully patched target — as a signal to prioritize the fix above routine patch-cycle scheduling. CISA’s guidance for this entry also tells agencies to apply Ivanti’s mitigations and, where mitigations are unavailable, to consider discontinuing use of the affected product and conducting forensic triage rather than assuming a clean patch resolves the incident.

Why this matters more than the average VPN bug

Ivanti Connect Secure appliances have been a recurring target for sophisticated attackers over the past several years, and this incident follows that pattern in one especially concerning way: the victim device was fully up to date. A patch regime alone did not prevent compromise, because the exploited flaws were unknown — true zero-days — at the time of the attack. That is a meaningfully different risk profile than “an organization failed to patch a known bug,” and it is why CISA moved quickly to add the flaw to its KEV catalog with a short remediation window, and why incident responders are treating every internet-facing Connect Secure appliance as a potential target regardless of patch level at the time of the October 3 campaign start.

It is also a reminder of the stakes of VPN appliance compromise generally: a VPN gateway sits at the perimeter with privileged access to internal directory services, which is exactly what let UTA0576 pivot straight into LAPS and BitLocker data without needing to touch an endpoint first. Readers weighing VPN architecture decisions more broadly may find our comparison of VPN and Tor privacy models useful background, though enterprise remote-access appliances like Connect Secure carry a different risk profile than consumer VPN clients.

How this compares to other recent edge-device bugs

This disclosure lands in a year that has already seen a steady drumbeat of actively exploited edge and infrastructure bugs added to CISA’s KEV catalog, including an Atlassian flaw facing its own recent patch deadline. What sets the UTA0576 campaign apart is the combination of three previously unknown bugs chained together, the fact the target device was fully patched at the time of compromise, and the attacker’s unusually disciplined anti-forensic tradecraft — no implant, no web shell, just repeated live exploitation and log cleanup on every single command.

What Ivanti Connect Secure admins should do now

If you operate Ivanti Connect Secure in any supported branch, security teams recommend treating this as an active-incident-response situation, not a routine patch cycle:

1. Patch immediately to 22.8R2.5, 25.1.1.2, 25.1.3.0, or 25.1.3.1 depending on your branch, even though this does not close the unpatched privilege-escalation component of the chain.
2. Run Ivanti’s Integrity Checker Tool on a recurring basis, understanding that it did not catch every artifact of this specific chain because key modifications were made in memory and configuration was restored afterward — a clean ICT scan is not a guarantee of no compromise.
3. Assume compromise and hunt rather than relying solely on the patch: review authentication and debug logs for signs of tampering or gaps, check for unusual LDAP query volume from the appliance’s service account, and look for renamed or unexpected processes (the campaign used a disguised tcpdump binary).
4. Rotate credentials broadly if compromise is suspected or confirmed, including the appliance’s own AD service account, any LAPS-managed local administrator passwords, and BitLocker recovery keys that may have been queried or exported.
5. Review Volexity’s published indicators of compromise and share findings with your incident response provider or CISA if you find evidence of exploitation.
6. Treat internet-facing management interfaces as high-value targets going forward — restrict exposure where feasible and monitor appliance logs for the specific exploitation and log-tampering patterns Volexity described.

Ivanti says its investigation into the scope of exploitation is ongoing and that it will release further guidance, including the pending fix for the unpatched privilege-escalation flaw, as it becomes available. Organizations that have not yet reviewed their exposure should do so immediately, given that CISA’s own federal deadline for remediation has already passed.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage