Back to Blog

Attackers Got Root Access to Fully Patched Ivanti VPNs. The Built-In Security Check Said Everything Was Fine.

There’s a category of security story that’s worse than “a patch was available and you didn’t apply it.” This is one of them. A threat actor compromised Ivanti Connect Secure VPN appliances that were fully up to date at the time. The devices had every available patch applied. And when affected organizations ran Ivanti’s own built-in security tool afterward, they got a clean result.

The incident response firm Volexity discovered this during an engagement for one of their customers earlier this month.[1] What they found was a three-zero-day attack chain that gave the attacker root-level access to the VPN appliance, with no authentication required to get started.

What is Ivanti Connect Secure?

It’s one of the most common remote-access VPN platforms in business IT. If your company uses a corporate VPN to let employees connect from home or from client sites to internal systems, there’s a real chance it runs on Ivanti Connect Secure (formerly called Pulse Secure). It’s not a niche product. Smaller businesses often use it through their IT providers, who manage the appliance on their behalf.

How the attack worked

The threat actor, tracked by researchers as UTA0576, chained three separate zero-day vulnerabilities in sequence to reach root access on the appliance.[1]

The entry point was CVE-2026-104935, an authentication bypass that lets a remote attacker execute commands on the device without logging in. CISA added it to the Known Exploited Vulnerabilities catalog on October 13.[3] From there, CVE-2026-118527 exploited a predictable identifier generation flaw to place arbitrary files on the system. Those files set the stage for CVE-2026-111357, a CVSS 8.8 privilege escalation that abuses a background maintenance service running as root.[2] Chain all three and you have unauthenticated root access to the VPN appliance.

Once inside, UTA0576 did what attackers do with that level of access. They harvested credentials, pulled data from the victim’s Active Directory environment, and extracted BitLocker recovery keys. Then they cleaned up after themselves, deleting their traces from Ivanti’s debug log and the Linux audit log on the device.[1]

The check that lied

Ivanti ships the Connect Secure appliance with an Integrity Checker Tool. The idea is that you run it and it tells you whether system files have been tampered with. After these incidents, affected appliances ran the ICT and received a clean result. The tool found nothing wrong. The appliances were not fine.

Rapid7 specifically warned administrators that a clean Integrity Checker result is not proof of safety in this case.[2] UTA0576 was careful enough that the standard verification path doesn’t catch it. If your team ran the Integrity Checker and checked the box, that assessment needs to be reopened.

This matters because it changes how you should think about your exposure window. Attacks began in early October. If your Ivanti appliance was running a vulnerable version any time since then, the question isn’t just “did I patch,” it’s “was I already hit before I patched.”

The patch situation and CISA deadlines

Patches for all three CVEs are now available. Versions 25.1.1.3 and 22.8R2.6 fix the full chain.[2] If you’re running anything earlier, you need to update.

CISA’s remediation deadline for CVE-2026-111357 was November 2. That was last week. The deadline for CVE-2026-118527 is November 13, this coming Thursday.[3] Federal agencies are legally required to hit those dates. For everyone else, treating them as your own target isn’t a bad idea.

What to actually do

First, find out whether you have Ivanti Connect Secure anywhere in your environment. If you don’t manage your own IT infrastructure, ask your provider. “Do we use Ivanti Connect Secure for remote access, and has it been updated to 25.1.1.3 or 22.8R2.6?” is a reasonable question to put to them today.

If you do have it, patch first. Then take the extra steps. Because UTA0576 was specifically after credentials, any accounts that authenticate through the VPN should have their passwords rotated. Active Directory logs going back to early October are worth reviewing for unusual activity, especially off-hours access or unexpected privilege changes.

Don’t rely on the Integrity Checker as the final word. It’s a useful tool under normal circumstances, but its limitations here have been documented explicitly. This is a case where treating the appliance as potentially compromised, running a credential rotation, and reviewing AD logs is the safer response than assuming the check would have caught it.

An attacker with root access to your VPN appliance is in the middle of every connection your employees make to internal systems. That’s not a narrow exposure. It’s the kind that tends to get used quietly for a while before anyone notices.