Ivanti Connect Secure zero-days gave attackers root on VPN gateways

What happened

The incident response firm Volexity found a group it tracks as UTA0576 exploiting a chain of previously unknown flaws in Ivanti Connect Secure, Ivanti’s VPN gateway. According to Volexity, the attacks started on 3 October 2026 against an appliance that was fully patched at the time (22.8R2.4). The chain combines an authentication bypass in the welcome.cgi handler, a file-write flaw in wu.cgi and a privilege escalation, which together give the attacker root without logging in.

Once inside, the attackers went after Active Directory secrets, using a compromised service account to pull Windows LAPS passwords and BitLocker recovery keys over LDAP. They also deleted their traces from the Ivanti debug log and the Linux audit log. Because the exploit patches code only in memory, Volexity says Ivanti’s Integrity Checker Tool did not flag the compromise, so a clean result from that tool doesn’t prove the device is clean.

Ivanti fixed the authentication bypass (CVE-2026-104935) on 13 October and the remaining two flaws on 29 October. CISA added CVE-2026-111357 and CVE-2026-118527 to its Known Exploited Vulnerabilities catalog on 30 October 2026.

The three bugs

On its own, CVE-2026-118527 looks minor. In a chain, a low-scoring bug that lets you drop a file in a predictable place is often exactly the missing link. (The public CVE record scores CVE-2026-111357 at 7.0 rather than Ivanti’s 8.8, because they disagree on how hard it is to exploit.)

Which versions are affected

• CVE-2026-111357 and CVE-2026-118527: 25.1.1.2 and earlier, and 22.8R2.5 and earlier
• CVE-2026-104935: 25.1.1.1 and earlier, 25.1.2.2 and earlier, and 22.8R2.4 and earlier

Ivanti recommends moving from 22.8.x to 25.1.1.3 or later, and applying 22.8R2.6 only if you can’t migrate yet. It lists 25.1.3.0 and later on ISA4500, ISA6500 and ISA8500 hardware as unaffected.

How to check for compromise

Volexity’s guidance, which Rapid7 also summarises: Where you can, preserve memory and logs before you reboot or reset the appliance, because a reboot can destroy evidence.

• Look in web logs for high volumes of requests to /dana-na/auth/url_default/welcome.cgi, and for requests where the URL path and the X-DSCGI-PATH header don’t match.
• Review files in /tmp/, /data/.icscap/ and /home/runtime/tmp/.
• Check /var/log/audit/audit.log and the Ivanti debug log for signs that individual entries were deleted.
• Block and search for traffic to 108.165.147[.]64, an address Volexity links to UTA0576.

If you find anything, follow Ivanti’s recovery steps and assume that every credential the gateway handled is exposed. That means VPN user passwords, service accounts it used to talk to Active Directory, and, given what the attackers went after, LAPS passwords and BitLocker recovery keys.

Why VPN gateways are such a target

Edge devices such as VPNs, firewalls and file-transfer appliances sit on the internet by design, often run closed firmware that defenders can’t easily inspect, and hold the keys to the internal network. If you run one, treat its advisories like those for your most critical servers: patch outside your normal cycle, and send its logs somewhere the device itself can’t wipe.

Sources

• Volexity: Chained exploitation of Ivanti Connect Secure zero-days (opens in a new tab)
• Rapid7: Additional Ivanti Connect Secure zero-days exploited in the wild (opens in a new tab)
• CISA Known Exploited Vulnerabilities catalog (opens in a new tab)