Ivanti Connect Secure CVE-2026-111357: Exploited Chain, Patch Again

If you patched Ivanti Connect Secure on October 13 and closed the ticket, your VPN appliance was, according to the version guidance tied to CISA's October 30 listing, still running a build exposed to the rest of the exploited chain. On October 30, the US Cybersecurity and Infrastructure Security Agency (CISA) put two more Connect Secure bugs on its Known Exploited Vulnerabilities (KEV) list: CVE-2026-118527 and CVE-2026-111357. Both belong to the chain behind the October 13 zero-day. The builds that fixed the first bug are the last builds exposed to the other two. The October fix did not close the chain, and the hunt for what happened during those weeks matters as much as the upgrade.

Connect Secure (ICS) is Ivanti's remote-access VPN gateway, the box that sits on the internet edge and lets staff into the internal network. BleepingComputer reported on October 13 that Volexity, which found the attacks, saw a previously unknown group it tracks as UTA0576 chaining three flaws into unauthenticated, root-level code execution on fully patched devices, with the earliest activity traced to October 3.

Which Ivanti Connect Secure builds are still exposed?

Any appliance on 25.1.1.2 or earlier, or 22.8R2.5 or earlier, is still exposed to the two flaws CISA listed on October 30. Those are exactly the builds that fixed CVE-2026-104935 two weeks earlier. The fixes for the full chain are 25.1.1.3 and 22.8R2.6, per the Hacker News write-up of the KEV listing.

One discrepancy is worth knowing about. BleepingComputer's October 13 report said Ivanti had already fixed two of the three flaws by then, with only the privilege escalation outstanding. The later version guidance, repeated by The Hacker News and Security Affairs, lists the October builds as affected by both newly listed CVEs. Go with the later guidance: it is the one tied to the KEV entries, and upgrading costs less than being wrong.

The three links, as described in the KEV entries and coverage:

• CVE-2026-104935 (CVSS 8.6): the entry point. A stranger with no account can get the appliance to execute commands. KEV listed it on October 13; the vulnerable range topped out at 22.8R2.4, 25.1.1.1 and 25.1.2.2 on their respective lines.

• CVE-2026-118527 (CVSS 4.3): the appliance generates guessable IDs, so a user who is already logged in can plant a file of their choosing at a location they can predict.

• CVE-2026-111357 (CVSS 8.8): a sensitive function that never checks who is calling it. Code already running on the box uses it to climb to root.

For the 25.1.3 line, the Canadian Centre for Cyber Security advisory lists versions before 25.1.3.1 as affected. Ivanti's account is that its own engineers had caught part of the root-escalation bug and shipped a fix for it in July, then were still porting it to older lines when UTA0576 showed up. Confirm the exact build for your line against Ivanti's advisory before you call it done.

The federal deadline for CVE-2026-111357 was November 2; CVE-2026-118527 follows on November 13. Everyone else should treat today's date as the deadline.

Why a 4.3 CVE belongs at the top of the queue

CVE-2026-118527 scores 4.3. Plenty of patch policies triage by CVSS and would park it for a monthly cycle. That is the wrong read. On its own it is a file-write primitive for someone already authenticated. Next to an authentication bypass, it is the bridge that turns a foothold into the file the privilege escalation needs. KEV listing is the signal to follow here, not the score, and any automation that gates edge-device patches on CVSS 7 or above would have skipped a link the attackers used.

The same goes for compliance dashboards. A report that marked Connect Secure "remediated" on October 13 is now wrong, because the version it recorded as safe is the version KEV says is exploitable. If your scanner keys on CVE-2026-104935 alone, it will keep showing green.

The appliance will not tell you it was breached

The detail that changes the response is how UTA0576 operated after getting in. According to Volexity's findings as reported by BleepingComputer, the group dropped no malware and no web shell. Every command meant a fresh run of the exploit, nothing stayed resident, and the group edited logs afterwards. That editing is how it slipped past Ivanti's Integrity Checker Tool. Reporting on the October 30 listing describes the goal: pulling credentials and some directory data out of Active Directory, poking around the host, and hunting for admin passwords, LAPS secrets and BitLocker recovery keys.

Put those together and the on-box checks most teams rely on come up empty. There is no implant to find, the local logs are suspect, and the integrity check has already been beaten once. The evidence lives elsewhere: on the domain controllers the VPN talks to, in syslog you forwarded off the appliance before anyone touched it, and in network flows from the appliance's internal interface.

That makes the VPN's own directory account the thing to examine. A remote-access gateway usually holds a service account that can query Active Directory to authenticate users. An attacker with root on the box inherits that account and whatever it can read. If it can read local administrator passwords managed by LAPS (Microsoft's Local Administrator Password Solution) or BitLocker recovery keys, the blast radius is every machine those secrets open, not the VPN.

Volexity did not publish indicators of compromise in the coverage we read, so the block below is not an IOC list. It maps the reported behavior to the observables it should leave, and where to look for each one.

T1190      Exploit Public-Facing Application
           Bursts of unauthenticated requests to the ICS web interface, repeating
           once per attacker command, with no session that survives between them
T1070      Indicator Removal
           Gaps or edits in appliance event/access logs; diff against the copy
           already forwarded to your syslog collector
T1087.002  Account Discovery: Domain Account
           LDAP searches from the ICS internal IP that do not match the normal
           user-authentication bind pattern (broad filters, admin groups)
T1552      Unsecured Credentials
           DC Security event 4662 (needs attribute auditing) where the ICS
           service account reads ms-Mcs-AdmPwd, msLAPS-Password, or
           msFVE-RecoveryInformation objects
T1021      Remote Services
           New SMB, RDP, or WinRM sessions sourced from the ICS internal IP

The 4662 check only works if auditing was already enabled on those attributes. If it was not, you cannot prove a negative, and the safe assumption is that anything the service account could read was read.

This is the pattern we flagged when Ivanti Sentry customers who patched were still breached, and again with the NetScaler dual zero-day and the BeyondTrust Remote Support bypass, which was listed in KEV alongside CVE-2026-104935. Edge appliances that authenticate against the directory keep turning a single bug into a domain problem.

Upgrade to 25.1.1.3 or 22.8R2.6, then rotate what the VPN could read

Order matters, because rotating secrets on a box that can still be re-exploited just hands the attacker the new ones.

1. Upgrade first. Move to 25.1.1.3 or 22.8R2.6, or the build Ivanti lists for your line. If you upgraded on October 13, you are not finished.

2. Pull evidence from outside the appliance. Go back to at least October 1, since one threat intelligence firm, Defused, reported first signs that day. Review forwarded syslog, firewall flows from the ICS internal IP, and DC logs for the service account.

3. Rotate the ICS directory service account and scope its read rights down to what authentication needs. Nothing about logging users in requires reading LAPS or BitLocker attributes.

4. Rotate exposed secrets. If the account could read LAPS passwords or BitLocker keys during the window, rotate them, starting with servers and admin workstations.

5. Look for lateral movement from the VPN, the one investigation step Volexity's guidance specifically calls out.

Shadowserver counted more than 5,500 Connect Secure instances exposed online in mid-October, with no way to say how many were already secured. Expect the gap between the first fix and the full fix to be where this campaign does its damage. Alerts on directory reads from the VPN's own account, from a managed detection service or your own SIEM, are what catch the next chain like this one before the appliance vendor has finished patching it.