Three Zero-Days Chained Into Root Access on Fully Patched Ivanti VPNs

On October 13, Ivanti warned customers that a zero-day vulnerability in its Connect Secure VPN appliances was being exploited in the wild. The warning understates what happened. According to incident response firm Volexity, which found the attack, a previously unknown threat actor tracked as UTA0576 chained three zero-day flaws together to gain root-level code execution on a fully patched Ivanti Connect Secure appliance, without any login. The device was running version 22.8R2.4, the latest available at the time. Exploitation began on October 3, a full ten days before disclosure.

Ivanti says it is aware of "limited exploitation in the wild." Internet watchdog Shadowserver tracks more than 5,500 Connect Secure instances exposed online. CISA added the flaw, CVE-2026-104935, to its Known Exploited Vulnerabilities catalog the same day and urged immediate patching. The privilege escalation component of the chain, notably, is still unpatched.

How three bugs became root

Volexity reconstructed the full chain from memory forensics after discovering that the attacker had wiped the device's logs. It starts with an authentication bypass in the appliance's welcome.cgi handler. The attacker sends a request to a public login script that requires no credentials, but tucks a header (X-DSCGI-PATH) into the request pointing at a protected internal script. The appliance uses the URL to decide whether the request is allowed, and the header to decide where it goes, so a request that looks public lands in a trusted, authenticated context.

The second link is a file upload race condition in wu.cgi. The attacker uploads a Perl script with a .zip extension. The handler writes it to disk using an MD5 hash of the filename, then checks whether it is a valid ZIP file, deletes it when it is not. But for a brief window the file exists on disk, and by firing execution requests in parallel through the same header trick, the attacker runs the script before deletion wins the race.

The third link escalates from the cgi-server user to root. The appliance's privileged dsinvoked service looks up its maintenance tasks in a shared configuration store called DSCache. The attacker's in-memory code patches a library, rewrites a task entry to point at the Perl interpreter, asks dsinvoked to run the task, and gets root. It then restores the library and configuration to their original state, leaving no trace on disk.

The appliance was fully patched. The attacker needed no password. The device's own integrity checker saw nothing.

What the attacker did inside

Once in, UTA0576 went straight for credentials. Volexity found evidence that the attacker extracted domain credentials stored on the appliance, dumped and exfiltrated Active Directory metadata, and deployed a custom Python tool that searched the victim's Active Directory for Local Administrator Password Solution (LAPS) passwords, BitLocker recovery keys, and password-bearing account attributes, all via the appliance's own Active Directory service account. A second custom tool implemented Kerberos attacks, including Kerberoast functionality, and a password sprayer hammered Active Directory accounts.

The operational discipline is what stands out. UTA0576 deployed no malware, no backdoor, no web shell. Every command was executed by re-running the entire exploit chain, with results returned through the HTTPS response itself. The payload ran mostly in memory: the final Python stage arrived Base64-encoded and compressed, decoded and decompressed straight into exec(), so the raw script never touched disk. Temporary files were deleted after use. Exploitation-related entries were surgically removed from both the Ivanti debug log and the Linux audit log, with older entries preserved so nothing looked obviously tampered with.

Volexity assesses with high confidence that a human operator was interactively driving the session, based on the variety of commands and approaches, rather than an automated script. The firm's analysts also saw the attacker parsing the appliance's own packet capture file to harvest plaintext LDAP credentials and NTLM challenge-response material from network traffic flowing through the VPN.

Why this is worse than a patch cycle

Patching fixes the first two flaws, and Ivanti released fixed versions on October 13 (22.8R2.5, 25.1.1.2, 25.1.3.0, 25.1.3.1). But three things make this incident unusual. First, the privilege escalation component remains unpatched, with a fix promised in a future release "in the coming weeks," meaning the chain's final step is still available to anyone who can get code execution through other means.

Second, detection is a forensic problem, not a scanning problem. Ivanti's Integrity Checker Tool looks for unexpected file modifications on disk. Because this chain patches library code in memory only and restores the configuration store, the tool finds nothing. CISA explicitly warns that the checker "may not detect evidence of exploitation" and says organizations that suspect compromise need network and memory forensics. If a compromise is confirmed, the recommendation is severe: back up the configuration, factory-reset the appliance, upgrade to the fixed version, and restore. Patching alone does not evict an attacker who already owns the box.

Third, this is Ivanti's normal now. Hackers keep finding zero-days in the company's appliances because VPN gateways are ideal beachheads: internet-facing, trusted by the network, and stuffed with credentials. BleepingComputer notes that Ivanti has patched several actively exploited Connect Secure zero-days in recent years, including CVE-2023-46805 and CVE-2024-21887 in January 2024, CVE-2024-21893 two weeks later, CVE-2025-0282 in January 2025, and CVE-2025-22457, which China-linked actors exploited from March 2025. CISA has flagged 36 Ivanti vulnerabilities as actively exploited since November 2021. One more milestone: version 22.8 reaches end of life on January 31, 2027, so the clock is already ticking on the affected branch.

What to do now

If you run Ivanti Connect Secure, upgrade to a fixed release immediately: 22.8R2.5, 25.1.1.2, 25.1.3.0, or 25.1.3.1. Version 22.7R2.14 and earlier are not affected. Then assume the patch is the easy part. Review authentication logs, VPN session records, and Active Directory changes around the October 1 to October 13 window for signs of credential access. Rotate credentials that the appliance touches, including its Active Directory service account. And plan the 22.8 end-of-life migration now rather than under the pressure of the next zero-day, because at this point the next one is a matter of when, not if.