Vulnerabilities
Ivanti Connect Secure zero-day chain: patch, then hunt
CVE-2026-104935 let UTA0576 reach root on fully patched Ivanti VPNs. Fixed builds, the unpatched third flaw, and how to check a gateway you can't trust.
Ivanti disclosed CVE-2026-104935 in Connect Secure (ICS), its SSL VPN appliance, on October 13. Ivanti rates it CVSS 8.6 and describes it as an authentication bypass that lets a remote attacker with no account run commands on the gateway. Affected builds are 22.8R2.4 and earlier, 25.1.1.1 and earlier, and 25.1.2.2 and earlier. Ivanti says 22.7 releases are not affected. CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog the same day and published an alert urging organisations to patch.
The same day, Volexity published how it was used. An actor it tracks as UTA0576 chained three flaws to get unauthenticated root on an appliance running 22.8R2.4, which was the newest build at the time. CVE-2026-104935 covers two of them. The third, a privilege escalation, has no fix yet, and the actor left nothing on disk that Ivanti's own Integrity Checker Tool (ICT) would find. If you run ICS, upgrade today and then work out whether the gateway was already used against you.
How it works
ICS serves its web pages through CGI handlers. Some, like welcome.cgi, which draws the login page, have to be reachable without a session. Others, like wu.cgi, sit behind authentication. According to Volexity, the appliance makes two separate decisions about each request: it uses the URL to decide whether the request is allowed, and an X-DSCGI-PATH request header to decide which script actually handles it. An attacker requests the public welcome.cgi and sets that header to point at wu.cgi. The access check passes on the URL, and the protected script runs anyway. That mismatch is the authentication bypass, classed as CWE-290 (authentication bypass by spoofing).
The second flaw is a file write in wu.cgi. Volexity reports that the upload handler writes the file to disk before checking that it is a valid ZIP archive, so a Perl script sent with a .zip name exists for a short window before it is deleted. Running it inside that window gives code execution on the appliance. Ivanti tracks both of these flaws under CVE-2026-104935.
The third step turns that foothold into root. Volexity describes it as a flaw in how dsinvoked, a broker process on the appliance, trusts cached configuration data (DSCache). Ivanti has said a fix will come in a future release in the coming weeks. Until then, a fixed build blocks the chain only by closing the first two steps; anyone who reaches code execution another way can still use the escalation.
Ivanti told reporters it found part of the problem through its own security work and fixed it in 25.1.3.0 through the normal release cycle, without an out-of-band patch, because it had no sign of exploitation then. The fix had not reached the 22.8 and older 25.1 branches when UTA0576 started using it.
What attackers are doing
Volexity says UTA0576 exploited its customer's appliance repeatedly from October 3, and began its own investigation on October 5 after spotting suspicious activity. One other write-up puts the first sign of exploitation at October 1; we could not confirm that against Volexity's report, so treat October 3 as the documented start. Ivanti says it knows of exploitation affecting a limited number of customers, and Volexity has described one confirmed victim.
The actor installed no web shell, backdoor or malware. It ran the whole chain again for every command and read the output from the HTTPS response, so there was no separate command and control channel to spot. It also deleted the matching entries from the Ivanti debug log and the Linux audit log. Volexity says the exploit changes library code only in memory and restores the configuration data it alters, which is why the ICT reports a clean appliance. Volexity rebuilt the chain from memory images of the device.
Once in, UTA0576 went after the rest of the network. It took credentials stored on the appliance, including the LDAP account the VPN uses to query the domain, then searched Active Directory for Local Administrator Password Solution (LAPS) passwords and BitLocker recovery keys. It ran password spraying against domain accounts, tested credentials with a custom Kerberos tool and tried to pull credentials out of captured network traffic. Volexity assesses with low confidence that the motive is criminal rather than espionage, based on this single case.
What to do
1. Upgrade to a fixed build today
Move each appliance to the fixed build for its branch: 22.8R2.4 and earlier to 22.8R2.5, 25.1.1.1 and earlier to 25.1.1.2, and 25.1.2.2 and earlier to 25.1.3.0 or 25.1.3.1. Do every node in a cluster. Ivanti has not published a workaround that closes the bypass without upgrading, and it has given no mitigation for the unpatched privilege escalation. If you cannot upgrade within the day, the only real choice is taking the gateway off the internet until you can.
Plan a second upgrade for when the privilege escalation fix ships.
2. Check for compromise from outside the appliance
A clean ICT scan does not clear you, and the attacker edited the logs that live on the box. Use records the appliance cannot change:
- Web proxy, load balancer or web application firewall logs in front of ICS: look for requests to
welcome.cgicarrying anX-DSCGI-PATHheader, especially one namingwu.cgi, and for a high volume ofwelcome.cgirequests from one source. Volexity flags both. - Firewall and NetFlow records for the published indicator
108.165.147[.]64, which reports describe as a VPS running OpenVPN tied to the operation. - On the appliance, if your support process lets you inspect it, the directory
/data/.icscap/, which Volexity lists as an indicator. - Domain controller logs from October 1 onwards: Kerberos pre-authentication failures (event 4771) and failed logons (4625) spread across many accounts from the VPN's internal address, and LDAP reads of the LAPS password attribute (
ms-Mcs-AdmPwdormsLAPS-Password) and of BitLocker recovery objects by the ICS service account.
If you find a hit or cannot rule one out, Volexity's advice is a full forensic investigation including memory capture of the appliance, before it is rebooted or upgraded.
3. Rotate what the appliance held
Assume anything stored on the gateway is in the attacker's hands. Reset the LDAP or Active Directory bind account ICS uses, any local admin accounts on the appliance, RADIUS shared secrets, and the TLS certificate private key if it was generated or stored on the box. Then rotate the LAPS passwords and review the BitLocker recovery keys that the bind account could read, since those are what UTA0576 searched for.
4. If compromised, rebuild
Do not upgrade in place over an appliance someone else had root on. Factory reset it, install a fixed build, and restore a configuration you have reviewed line by line for added admin accounts, authentication servers and resource policies you did not create. Ivanti support can confirm the recovery procedure for your branch.
Edge devices need monitoring that does not run on them
UTA0576 kept no files on the box and cleaned the logs it could reach. A gateway you cannot inspect from inside has to be watched from the systems around it: request logs from a device in front of it, flow records from the firewall behind it, and the domain controller logs that show what its service account is doing. It also helps to give the VPN's directory account the narrowest read rights it needs, so it cannot read LAPS or BitLocker attributes in the first place.
Our attack surface management work keeps a current list of the VPN and edge devices you expose and their versions, and our security operations team sets up the outside-in logging that a case like this depends on. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: CISA alert, Volexity, BleepingComputer, SecurityWeek, CyberScoop, Rapid7, The Hacker News, iTnews, GovInfoSecurity.