Ivanti Connect Secure zero-days: why you need to patch again

Short read

This post covers the Ivanti Connect Secure VPN zero-days that attackers chained together to get root access on appliances that were fully patched at the time. Ivanti shipped the final fixes on 29 October, and if you patched in mid-October you need to upgrade again.

You'll learn what the attackers did once they were in, why Ivanti's own integrity checker couldn't see it, and the practical steps to take now if you or your customers run Connect Secure.

The Ivanti Connect Secure zero-days are back in the news, and this time the advice is awkward: if you patched your VPN in mid-October, you are not finished. On 29 October Ivanti released fixes for two more vulnerabilities, CVE-2026-111357 and CVE-2026-118527, that attackers had chained with an authentication bypass disclosed earlier in the month. SecurityWeek reports that the US Cybersecurity and Infrastructure Security Agency (CISA) added both to its Known Exploited Vulnerabilities catalogue on Friday, with a federal deadline of today, 2 November, for the more serious one.

This article explains what happened, what the attackers went after, and what to do now.

What the Ivanti Connect Secure attack chain does

Connect Secure (ICS) is Ivanti's SSL VPN appliance, the box that lets staff reach internal systems from outside. Because it sits on the internet edge and talks to Active Directory, it is a high-value target.

Volexity found a previously unknown group it tracks as UTA0576 exploiting the appliance from 3 October. The group combined three flaws:

• An authentication bypass that let unauthenticated requests reach scripts that should need a login.
• A file write flaw that let the attacker upload and run a script during a brief window before it was deleted. Ivanti tracks this and the bypass together as CVE-2026-104935, fixed on 13 October.
• A privilege escalation flaw, now CVE-2026-111357 (CVSS 8.8), that turned that foothold into root. No fix existed when the attacks came to light.

The third bug, CVE-2026-118527 (CVSS 4.3), lets an authenticated attacker upload files to a predictable location. Together, Volexity says, they gave unauthenticated code execution as root on an appliance running what was then the latest version.

Why "we patched in October" isn't enough

The 13 October releases (25.1.1.2 and 22.8R2.5) closed the way in, but not the privilege escalation. Ivanti has explained that it shipped the first fix without waiting, because it closed the main route of attack. The full fix is in 25.1.1.3 and 22.8R2.6. According to SecurityWeek, organisations that installed the October releases need to upgrade again.

It is also worth knowing that threat intelligence firm Defused reported attacks it believes targeted CVE-2026-104935 hitting its decoys from 1 October, before the flaw was public. Patching quickly matters, but some victims were compromised before any patch existed.

What the attackers did once inside

This is the part that should concern security leads most. Volexity reports that UTA0576 went straight for credentials and reconnaissance:

• Pulled domain credentials stored on the appliance and used its Active Directory service account to search for LAPS local administrator passwords and BitLocker recovery keys.
• Exported Active Directory data and ran password-spraying attacks against AD accounts.
• Ran a disguised packet sniffer to harvest plaintext LDAP and HTTP credentials and NTLM hashes from traffic passing through the VPN.
• Removed its own entries from the appliance's debug log and the Linux audit log.

The attackers installed no web shell and no backdoor. They re-ran the exploit chain for every command, and patched code only in memory before putting it back. Volexity notes that, as a result, Ivanti's Integrity Checker Tool did not detect any changes. Volexity also assesses, with medium confidence, that the group used large language models for exploit development.

In other words, the VPN looked clean, its logs looked clean, and the attacker was preparing to move into the wider network.

What to do now

If you, or customers you look after, run Ivanti Connect Secure:

1. Upgrade to 25.1.1.3 or 22.8R2.6, even if you patched on 13 October.
2. Don't rely on the integrity checker alone. Volexity says forensic investigation, including memory and network analysis, is needed to confirm whether a device was compromised.
3. Look for the request pattern Volexity describes: large numbers of requests to /dana-na/auth/url_default/welcome.cgi, especially with an X-DSCGI-PATH header that doesn't match the URL. Check /tmp/ on the appliance for leftover files.
4. Watch what the VPN does next. Attempts to move laterally from the VPN appliance are a sign of compromise, according to Volexity. Look in your domain controller and identity logs for unusual LDAP queries from the VPN's service account, password spraying, and Kerberos activity.
5. Assume exposed secrets are exposed. If there's any sign of compromise, rotate the VPN's Active Directory service account, LAPS passwords and BitLocker recovery keys, and review any credentials that passed through the device.
6. Know your edge. Make sure you have a full list of the VPNs and remote-access appliances you expose to the internet, and their versions. You can't patch a box nobody remembers.

The bigger lesson for edge devices

This is the same story we covered with the ESXi logging flaw last week: when attackers can wipe or avoid the logs on one device, the evidence has to come from everything around it. A VPN appliance that quietly queries Active Directory for every LAPS password is unusual behaviour, even if the appliance itself reports nothing.

For smaller businesses and MSPs, that means two things. Keep an up-to-date picture of what you expose to the internet, and make sure someone is watching identity and network activity around those devices around the clock, not just checking the appliance's own health report.

Sources: SecurityWeek, Volexity, Ivanti security advisory, SANS Internet Storm Center.