CRITICAL: Ivanti Patches Connect Secure Root Exploit Chain Under Attack

Remember the Ivanti Connect Secure chain from a few weeks ago, the one where a fully patched VPN appliance handed an attacker root anyway? The part Ivanti couldn't fix at the time finally has a patch, and CISA has given federal agencies until today to install it. On October 30, CISA added two more Connect Secure vulnerabilities, CVE-2026-111357 and CVE-2026-118527, to its Known Exploited Vulnerabilities catalog. They are the missing pieces of the chain that Volexity caught a threat actor called UTA0576 using in early October. With them, every link in that chain now has a CVE number, a fixed build, and a federal deadline.

The deadlines are the part that should get your attention. Federal civilian agencies have until November 2 to fix CVE-2026-111357, the privilege escalation flaw that turns a foothold into full control of the box, and CISA has flagged it for mandatory forensic triage. CVE-2026-118527 is due November 13. If you run Connect Secure anywhere, for a client or for yourself, this is a patch-it-today situation and not something to slot into next month's window.

A Quick Recap of the Chain

When Volexity published its findings on October 13, the story was unsettling because of how ordinary the victim was. The appliance was running Connect Secure 22.8R2.4, the newest build available, and nobody had skipped any patches. UTA0576 got in anyway, with exploitation confirmed as early as the first days of October. Defused Cyber later put the earliest activity at October 1.

The chain has three stages. The first is an authentication bypass in welcome.cgi, which Ivanti tracked as CVE-2026-104935 and which CISA added to the KEV catalog the same day the advisory went out. We covered that disclosure at the time. The second stage abuses a file write problem in wu.cgi so the attacker can put content of their choosing on disk. Together, those two steps give code execution as the low-privileged cgi-server user. The third stage abuses the way the dsinvoked broker trusts DSCache configuration data, and that is how the attacker gets from cgi-server to root.

In October, Ivanti had fixes for the first two stages and chose to ship them right away instead of holding them until the privilege escalation fix was ready. That was the right decision, but it left defenders with an awkward caveat. Patching broke the unauthenticated entry point, but the route to root inside the appliance was still there. Anyone who already had a low-privileged foothold, or who found another way in, could still use it.

What the New CVEs Actually Cover

CVE-2026-111357 is the privilege escalation. CISA's catalog describes it as missing authentication for a critical function that lets a local authenticated attacker escalate privileges, and it maps the bug to CWE-306, CWE-862, and CWE-345. That is a long way of saying a privileged broker process accepted data it had no business trusting. NVD's description is more specific. It says Connect Secure 22.8R2.4 mishandles the way the dsinvoked broker trusts DSCache configuration data, which leads to privilege escalation to root, "as exploited in the wild in October 2026." The Hacker News reports a CVSS score of 8.8, while the CVSS 3.1 vector MITRE submitted to NVD works out to 7.0. That vector rates the attack as local with high complexity. Don't let either number lull you. A local privilege escalation on an internet-facing VPN appliance, paired with a remote authentication bypass, matters a lot more than its standalone score suggests.

CVE-2026-118527 has a CVSS score of 4.3, and it looks harmless on paper. It is a predictable identifier flaw, CWE-340, that lets a remote authenticated attacker upload files with attacker-controlled content to a known location on disk. By itself, that is an annoyance. Chained behind an authentication bypass, it's how the attacker gets a payload to a place the privilege escalation can find. CISA's catalog entry says plainly that each of these flaws can be chained with the other two, so you should treat them as one problem with three CVE numbers.

Ivanti's fixes for both new CVEs are in Connect Secure 25.1.1.3 for the 25.1.x branch and 22.8R2.6 for the 22.8 branch. Anything at 25.1.1.2 or 22.8R2.5 and earlier is vulnerable. Ivanti says it had already found and fixed part of the privilege escalation through its own product security work in the July 25.1.3.0 release. It was still backporting that fix to the other supported versions when UTA0576 showed up. Ivanti explained that "our focus was initially centered on the disclosure of CVE-2026-104935," and that it "made the decision to not delay getting a fix to customers" once the escalation issue surfaced. A fix sitting in one branch while attackers exploit the same bug in another is a familiar story in this industry, and this one isn't anything new.

What the Attacker Did Once Inside

Most Connect Secure intrusions over the past few years followed the same pattern. The attacker dropped a web shell or a custom implant and then hoped nobody looked too closely. UTA0576 didn't bother with that. Volexity found no malware and no web shell. The exploit patched library code in memory and then restored the configuration store data it had touched, so nothing on disk looked out of place.

With root access, the actor pulled credentials and a limited amount of Active Directory metadata. It also ran host reconnaissance, captured LDAP traffic passing through the appliance, and exfiltrated configuration data. It specifically searched for local administrator passwords and BitLocker recovery keys. Then it cleaned up behind itself, modifying logs and removing temporary execution artifacts. Volexity said with high confidence that the activity looked like preparation for lateral movement and a broader network compromise. It also said with low confidence that the actor was more likely criminal than espionage-driven. The intrusion was caught and disrupted before the final objective became clear, and Ivanti says only a limited number of customers were affected.

That's good news for the victims Volexity caught. It's not much comfort for everyone else, though, because the cleanup routine was clearly built to defeat the tools most teams rely on.

Why Your Integrity Checker Won't Save You Here

This is the part that should change how you run your incident response. Ivanti's Integrity Checker Tool has been the go-to answer for every Connect Secure scare since 2024, and Volexity says it won't detect this chain. The exploit patches code only in memory and puts the configuration store back the way it found it, so the checker sees a clean appliance and reports one. A clean ICT scan on a box that was exposed during October tells you almost nothing.

Finding evidence takes real forensic work, meaning memory captures and crash dump analysis and a close look at the appliance's network behavior. Volexity has published indicators of compromise in its GitHub repository, and that is the first place to start. Beyond the device itself, look at what an attacker with root on your VPN concentrator could have touched. Check for odd LDAP binds coming from the appliance's address and for authentication by service accounts the appliance uses at unusual hours. Watch for any lookups of BitLocker recovery keys in Active Directory. Windows Server logs those reads under directory service access auditing if you have it turned on, and if you don't, this is a good week to change that.

What to Do Right Now

Upgrade first. Move 25.1.x appliances to 25.1.1.3 or later and 22.8 appliances to 22.8R2.6 or later, and confirm the build after the reboot instead of trusting that the change ticket closed. If an appliance is on an unsupported branch, you're past the point of debating whether to replace it.

Next, assume compromise for any appliance that was internet-facing and unpatched against CVE-2026-104935 at any point since the first of October. CISA's forensic triage requirement for federal agencies is a sensible bar for everyone else. Collect evidence before you wipe, then follow Ivanti's recovery guidance, which in past incidents has meant a factory reset and a clean rebuild instead of patching in place.

Then rotate secrets on the assumption they're gone. That includes every credential the appliance stores or brokers, the service accounts it uses to bind to LDAP and Active Directory, and any local administrator passwords that could have been exposed. If BitLocker recovery keys are escrowed in AD and your appliance was in scope, plan to regenerate them on affected endpoints. That job is tedious, but finding a stolen recovery key the hard way is worse.

Finally, take a hard look at what the appliance can reach. A VPN concentrator that can freely query every domain controller is an attacker's dream. Segmenting it, restricting its service accounts to the minimum, and sending its logs to a SIEM it can't tamper with make the next chain a lot less painful. Given Ivanti's track record, plan for another one.

The Bigger Picture

Edge appliances have been the favorite way into corporate networks for a few years now, and this chain shows why. Attackers chained three bugs, including a 4.3 most scanners would bury on page six, and got root on a box that sits on the internet and holds the keys to the directory. The patch sequencing was messy, and the anti-forensics were good enough to beat the vendor's own checker. None of this is new for Connect Secure, but each round asks a bit more of the defenders who have to clean it up.

If you've patched for CVE-2026-104935 and stopped there, you're not done. Install the new builds, do the forensic work, rotate the credentials, and assume any VPN that was exposed and unpatched in October has secrets that are already in someone else's hands.

The MSP Angle

Every client running Connect Secure needs a compromise assessment along with the patch, because the Integrity Checker can't clear an appliance this time. That makes a fixed-fee edge device forensics and credential rotation package an easy sell. It also opens a conversation about managed SASE or ZTNA for clients who are tired of patching around Ivanti's release schedule.