Ivanti Connect Secure Exploited Flaws: Patch and Check for Compromise

What to do today

This is the position as of 31 October 2026. Exploitation of the chain began in early October, before a fix existed for the privilege-escalation step, so the order matters: get onto a fixed build, then look for signs that someone was already inside.

Steps 1 to 3 need the appliance administrator. Step 4 needs forensic skills most IT teams do not keep to hand, so pass it on rather than improvising.

1. Establish whether you run Ivanti Connect Secure at all, including any appliance a supplier or managed service provider operates for you. Older remote-access gateways have a habit of outliving everyone's memory of them.
2. Record the exact software version the appliance is running, and whether its login page is reachable from the internet.
3. Schedule the upgrade to a fixed release for your branch (see the versions section) as an emergency change, not the next monthly window. Expect the appliance to be unavailable to remote users while it upgrades and restarts, so tell users first.
4. Arrange a compromise check for the same appliance, before or immediately around the upgrade, covering the points in the section on checking for compromise. Upgrading first is fine, but do not wipe evidence you may later need without a plan for it.
5. If you cannot upgrade within hours, take the appliance's internet-facing service offline until you can. Ivanti has not been reported to offer a workaround for these flaws, and I could not find one in the sources checked.

Which versions are affected and which are fixed

CISA lists Ivanti Connect Secure 25.1.1.2 and earlier, 25.1.2.2 and earlier, and 22.8R2.5 and earlier as affected. The Canadian Centre for Cyber Security words the same thing as affected versions before 25.1.1.3, before 25.1.3.1 and before 22.8R2.6. In practice that points to 25.1.1.3, 25.1.3.1 or 22.8R2.6 (or later) depending on your branch.

Reporting on Ivanti's updated guidance says to move to 25.1.1.3, or to 22.8R2.6 only where you cannot migrate straight away. CISA also notes that the 22.8 line reaches end of life on 31 January 2027, so 22.8R2.6 buys time rather than a destination. Ivanti's own advisory page would not load for us during research, so confirm the exact fixed build for your branch there before you schedule the work.

The CVE record for CVE-2026-111357 names 22.8R2.4 specifically, while CISA's wider list runs to 22.8R2.5. If you are on any 22.8R2 build, treat yourself as affected and move to R2.6.

What the three flaws do together

Think of it as a chain rather than three unrelated bugs. CVE-2026-104935 is an authentication bypass that Volexity found being used to run commands on the appliance without logging in. CVE-2026-111357 then lifts a low-privilege foothold to root, because a system component trusts configuration data it should not. CISA lists CVE-2026-118527 as a third entry that lets an authenticated attacker place files with attacker-controlled content at a known location, and says it can be chained with the other two. Public detail on exactly where it fits is thinner than for the other two.

CISA's catalogue describes CVE-2026-111357 as needing a local authenticated attacker, which sounds comfortable until you notice that the first flaw supplies the foothold. The catalogue title (Missing Authentication for Critical Function) and the weakness class on the CVE record (untrusted control sphere) do not match, so do not search logs for either phrase. Published severity scores also differ between sources, from 7.0 to 8.8. Ignore the number; the exploitation evidence is what sets the priority.

The consequence is a VPN gateway sitting between the internet and your network, controlled by someone else. Volexity reports the actor stole stored credentials, queried Active Directory, searched for LAPS passwords and BitLocker recovery keys, sniffed LDAP traffic and attempted password spraying.

Checking for compromise

Patching closes the door but does not evict anyone already inside. The chain is reported to patch code in memory only and restore configuration data afterwards, remove entries from the debug and audit logs, and delete its own scripts. Ivanti's Integrity Checker Tool is reported not to detect it. CISA says organisations checking for compromise need network and memory forensics.

Most administrators do not have a root shell on these appliances, so the realistic route is a specialist forensic review, often with Ivanti support. What you can usefully do yourself is gather context for them:

• Any proxy, WAF, firewall or packet capture in front of the appliance that records request headers: look for requests to the path /dana-na/auth/url_default/welcome.cgi carrying an X-DSCGI-PATH header whose value does not match the URL. Volexity suggests alerting on any mismatch.
• Volexity's published indicators include temporary files such as /tmp/ml.py, /tmp/rq5.py, /tmp/mk.py, /tmp/rr.py, /tmp/pu.txt, /tmp/sp_out.txt and /tmp/spray_hits.json, a hidden /data/.icscap directory, and a process named dsstatmond (a renamed packet-capture tool). Pass these to whoever examines the appliance rather than looking for them yourself.
• The attacker infrastructure Volexity named includes the address 108.165.147[.]64 (written defanged, so remove the brackets only inside a tool). Check firewall and VPN logs for it, remembering that other addresses may have been used.
• Anything the appliance could see: look at your domain controllers and directory logs for unusual queries, failed-logon bursts or password spraying that originated from the VPN appliance's internal address.

If you think the appliance was compromised

CISA's recovery guidance is to rebuild rather than clean. Several of these steps are disruptive, so plan them as an outage.

Because the appliance stores directory and other credentials, the password and certificate resets are not optional extras. A restored configuration is only as trustworthy as the point it was taken from, so have the forensic reviewer comment on that before you restore.

1. Back up the appliance configuration using Ivanti's archiving server procedure.
2. Factory reset the appliance and upgrade it to the latest version. For cloud and virtual deployments, rebuild the virtual instance and upgrade it.
3. Restore the configuration from the backup taken in step 1.
4. Reset passwords for all accounts - domain, administrator and local. Revoke and reissue stored certificates, and reset stored API keys and licence server credentials. Start with the service account the appliance uses to talk to your directory.
5. Confirm remote access works for a test user, and keep watching directory and VPN logs for unusual activity for the following weeks.

What is confirmed about real-world exploitation

CISA added all three CVEs to the Known Exploited Vulnerabilities catalogue on the basis of evidence of active exploitation: CVE-2026-104935 on 13 October and the other two on 30 October. NHS England's summary says Ivanti observed exploitation affecting a limited number of customers when the three are chained, and assesses further exploitation as highly likely.

Volexity tracks the activity as UTA0576 and dates it from 3 October 2026. It assesses with low confidence that the actor is criminal rather than espionage-motivated. Other sources give slightly different start dates, so treat early October as the safe description. CISA's catalogue lists ransomware use as unknown for the two new entries. We have not found a credible public source naming affected organisations, and we are not naming any.

The KEV due dates (2 November 2026 for CVE-2026-111357 and 13 November for CVE-2026-118527) apply to US federal civilian agencies under BOD 26-04. UK businesses are not bound by them, but they show how CISA ranks the urgency.