Patched Ivanti Connect Secure on Oct 13? The root-escalation half of the chain is now on CISA KEV (CVE-2026-111357, CVE-2026-118527)

If you patched Ivanti Connect Secure on October 13, the appliance is still on a build with two of the three bugs an attacker chained to get root. CISA added CVE-2026-111357 and CVE-2026-118527 to its Known Exploited Vulnerabilities catalog on October 30. Both affect 25.1.1.2 and 22.8R2.5, the builds that fixed the login bypass two weeks ago. Ivanti shipped the fixes on October 29 in 25.1.1.3 and 22.8R2.6. CISA's federal deadline for CVE-2026-111357 is Monday, November 2, and it requires forensic triage, not only a patch.

This is a follow-up to our October 13 write-up of CVE-2026-104935, the login bypass at the front of the chain. The HOL Guard evidence pack for CVE-2026-111357 is the source record.

How to fix

Download the new build from the Ivanti License System (ILS) and install it on every node from the admin console (Maintenance, then System, then Upgrade/Downgrade).

The table above is the one Ivanti published on October 29, as reproduced by The Stack and the Canadian Centre for Cyber Security. If you skipped the October 13 round, go straight to the new build. 25.1.1.3 and 22.8R2.6 resolve all three CVEs on their lines.

If you think the box was hit, decide on evidence before you click upgrade. The upgrade reboots the appliance, and on this chain the useful evidence lives in memory. More on that below.

What the two new CVEs are

Volexity described the full chain on October 13 after investigating a customer appliance that was fully patched at the time (22.8R2.4). The attacker, which Volexity tracks as UTA0576, started on October 3. Three steps, each now with its own CVE:

1. Get past the login (CVE-2026-104935). A request to the public login script /dana-na/auth/url_default/welcome.cgi carries an X-DSCGI-PATH header naming a different, protected script. The appliance checks the URL to decide if the request is allowed and uses the header to decide where it goes. Fixed October 13.
2. Drop a file where you know its name (CVE-2026-118527). The upload handler wu.cgi writes the upload to /home/runtime/tmp/ under the MD5 of the client-supplied filename, then checks whether it is a ZIP and deletes it if not. The attacker uploaded a Perl script and fired parallel requests at the predictable path to run it before the delete. Ivanti scores this one 4.3. CISA describes the attacker as remote and authenticated, so on its own it needs a logged-in session.
3. Become root (CVE-2026-111357). The dsinvoked broker runs maintenance tasks as root and looks up which program each task runs in DSCache, a shared config store. The attacker patched the in-memory copy of libdsplibs.so in the cgi-server process, pointed a maintenance task at the Perl interpreter, and asked dsinvoked to run it. NVD's description: the broker "mishandles the manner in which" it "trusts DSCache configuration data, leading to privilege escalation to root."

Ivanti says it shipped the login-bypass fix first because that fix was already in QA, and it chose "to not delay getting a fix to customers" for the primary exploitation path. That was the right call for the front door. It also means the October 13 patch round left the rest of the chain in place for 16 days.

Why a clean integrity check proves nothing here

Three details from Volexity change how you investigate:

• The root step patches library code in memory only and puts the DSCache entry back afterward. Volexity says Ivanti's Integrity Checker Tool "does not detect any modifications."
• The payload trims recent entries out of /home/runtime/dlogs/debuglog and /var/log/audit/audit.log and rewrites both files, keeping older lines so nothing looks empty.
• There was no web shell or implant. The attacker re-ran the whole chain for every command and read the output in the HTTPS response.

So the evidence that survives is mostly off the box (your proxy, load balancer, WAF and domain controller logs) or in the appliance's memory until the next reboot. On a virtual appliance, a hypervisor snapshot that includes memory, taken before the upgrade, keeps the second option open. On hardware, talk to Ivanti support or your IR firm before rebooting if you have reason to suspect a hit. This is the part of CISA's "forensic triage" requirement that an upgrade-first habit quietly destroys.

Check whether you were hit

Two checks you can run without shell access to the appliance:

1. Edge logs. In whatever sits in front of the VPN and logs request headers, look for requests to /dana-na/auth/url_default/welcome.cgi that carry an X-DSCGI-PATH header pointing somewhere other than the login page. Volexity saw values like /home/webserver/htdocs/dana/fb/smb/wu.cgi and /home/runtime/tmp/ followed by a 32-character hash. Bursts of those requests in parallel are the race in step 2. Volexity expects other paths to work too, so flag any mismatch between URL and header, not only these two strings.
2. Your directory, not the VPN. The attacker used the appliance's Active Directory service account to search LDAP for LAPS local admin passwords, BitLocker recovery keys and userPassword / unixUserPassword attributes, then ran password spraying. If you have directory service access auditing, look for reads of those attributes by the Connect Secure service account. Volexity also saw packet captures from a renamed tcpdump (dsstatmond) in a hidden /data/.icscap/ directory, filtered for LDAP, HTTP, FTP and telnet.

If either check turns something up, treat it as a domain incident. Rotate the Connect Secure LDAP service account, the LAPS passwords and BitLocker keys it could read, and the credentials of anyone who logged in through the VPN during the window. Then follow Ivanti's 22.8x and 25x recovery steps for the appliance itself.

Who is not in scope

• People using the Ivanti Secure Access client on laptops. These are bugs in the gateway appliance.
• Ivanti Policy Secure, ZTA Gateways and Neurons for Secure Access. The October 29 table lists only Connect Secure.
• The 25.1.3 line (ISA4500, ISA6500, ISA8500 and rebuilt virtual appliances). The October 29 table does not list it as affected by the two new CVEs. Confirm your exact build against Ivanti's advisory before you close the ticket.
• Organizations outside the US federal civilian branch are not bound by the November 2 and November 13 dates. The exploitation is the same either way.

What this is not

This is not a new way in for strangers: the unauthenticated entry point was CVE-2026-104935, and the October 13 builds closed it, so on a box patched then, the two new bugs need a valid session or code already running on the appliance. Ivanti describes exploitation as limited to a small number of customers, CISA lists ransomware use as unknown, and none of the advisories reference public exploit code.

What do people ask about the Ivanti Connect Secure KEV additions?

I installed 25.1.1.2 on October 13. Am I still exposed?

Yes to the two new CVEs. 25.1.1.2 and 22.8R2.5 are listed as affected by CVE-2026-111357 and CVE-2026-118527. Install 25.1.1.3 or 22.8R2.6.

What are the CISA due dates?

November 2, 2026 for CVE-2026-111357, with forensic triage required. November 13, 2026 for CVE-2026-118527, without forensic triage. Both were added to KEV on October 30, 2026.

Will the Ivanti Integrity Checker show if I was compromised?

Not for this chain. Volexity found that the root step changes code in memory and restores the config store, so the Integrity Checker Tool did not detect it. Use edge logs, domain controller logs and memory forensics.

Is there a workaround if I cannot upgrade this weekend?

None of the published sources list one for these two CVEs. Watch edge logs for the header mismatch and take the first maintenance window you have.

References

• Ivanti Security Advisory: Ivanti Connect Secure (CVE-2026-104935, updated October 29 with CVE-2026-111357 and CVE-2026-118527)
• CISA: CISA Adds Two Known Exploited Vulnerabilities to Catalog (October 30, 2026)
• Volexity: A Series of Unauthenticated Events, Chained Exploitation of Ivanti Connect Secure Zero-Days
• NVD: CVE-2026-111357
• NVD: CVE-2026-118527
• Ivanti Connect Secure 22.8x and 25x Recovery Steps