Ivanti Connect Secure: Three Chained Flaws, Root Access, and Why Patching Is Not the End of It

Installing Ivanti's 29 October fixes closes the Ivanti Connect Secure vulnerability chain. It does not tell you whether someone was already inside.

Volexity dates the first attacks it saw to 3 October, 10 days before Ivanti's first fix and 26 days before the second. So when the attacks began, a box on 22.8 or 25.1.1 had no patch to install. On the appliance Volexity examined, the attacker left no backdoor or web shell, removed entries from the logs, and got nothing flagged by Ivanti's own Integrity Checker Tool.

If you run one of these appliances with no security team watching it, applying the update is where your job starts: work out your exposure from dates rather than from a clean scan, then decide which secrets the box was holding.

Is the Ivanti Connect Secure vulnerability being actively exploited?

Yes. The Ivanti Connect Secure vulnerability chain is being used in real attacks, and CISA lists all three flaws in its Known Exploited Vulnerabilities catalog. Ivanti called the exploitation limited when it disclosed on 13 October 2026. No source has published a victim count, so the true scale is not public.

The 3 October date is Volexity's, not Ivanti's, and no Ivanti page we could read endorses it. Defused's date shows it is not a safe outer limit either. The earliest date any source we read reports is 1 October, and that is not a proven start. In fairness to Ivanti, part of the first flaw was already fixed in July, and Rapid7 reports the attacks happened while Ivanti was backporting that fix to its other supported versions.

Two more figures need care. Shadowserver tracked over 5,500 exposed Connect Secure instances as of BleepingComputer's 13 October report, but that counts boxes visible online, not vulnerable or compromised ones, and it may include honeypots. CISA gave US federal civilian agencies until 2 November and 13 November to deal with the two newer flaws. Those dates do not bind you, though they are a fair yardstick.

Volexity assesses with low confidence that the actor is criminal rather than espionage, and with medium confidence that it used large language models to develop its exploit. Neither changes what you need to do.

Which Ivanti Connect Secure versions are affected and which are fixed?

CISA lists Ivanti Connect Secure 25.1.1.2 and prior, 25.1.2.2 and prior, and 22.8R2.5 and prior as affected. The builds reported to fix the two newer flaws are 25.1.1.3 and 22.8R2.6. The 13 October builds fixed only the first flaw, so anyone who stopped at 25.1.1.2 or 22.8R2.5 has to upgrade again.

Rapid7 reports that Ivanti lists 25.1.3.0 and later on the ISA4500, ISA6500 and ISA8500 as unaffected. No source we could read covers 25.1.3.x on virtual or other platforms, so do not assume that line is safe in general. For older software, Rapid7 reports that versions 22.7.x and below are unaffected by CVE-2026-104935. No source we could read covers 22.7 against the two newer flaws.

SecurityWeek quotes Ivanti saying the latest release "addresses all vulnerabilities which were chained and exploited in the wild". Ivanti's advice for 22.8.X customers is to move to 25.1.1.3 or later, or to 22.8R2.6 if they cannot migrate right away. CISA notes that version 22.8 reaches end of life on 31 January 2027.

One caveat on sourcing. Ivanti's advisory did not load for us when we checked it, so the fixed builds above come from Rapid7, The Stack and SecurityWeek reporting it, and they agree. Confirm your target build on that page before you schedule the work.

How do CVE-2026-104935, CVE-2026-111357 and CVE-2026-118527 chain to root?

The Ivanti chain runs in three stages: get past the login, write and run a file, then borrow a service that runs as root. CISA's catalog entry for CVE-2026-111357 says it can be chained with the other two. Volexity published the technical account, though it never names CVE-2026-118527, so the mapping below is not perfectly clean.

1. Get past the login. A request goes to the public welcome.cgi page carrying an X-DSCGI-PATH header aimed at a protected script. One part of the system looks at the URL to decide whether the request is allowed, and another follows the header to decide where it goes. Volexity assigns this to CVE-2026-104935.
2. Write and run a file. wu.cgi saves an upload to a path built from an MD5 of the file name the client sent, so the attacker can work out the location in advance. A script sent as a .zip lands on disk before validation, and parallel requests run it before it is deleted. Volexity puts this under CVE-2026-104935 too. Rapid7, reporting Ivanti's advisory, describes CVE-2026-118527 as a remote authenticated file upload to a known path, so it likely relates to this step. That link is our inference.
3. Become root. The appliance has a background service, dsinvoked, that runs maintenance tasks as root. The attacker patches a library in the memory of the cgi-server process and alters a DSCache task so the service runs their script. Then the exploit puts the entry and the library back. Volexity assigns this to CVE-2026-111357.

Read those labels again, because the plain wording is the useful part. A service that does not check who is asking, and a file location that can be guessed, are old and ordinary mistakes.

The scores are the trap. A patch list sorted by score would put a 4.3 near the bottom. Ivanti rates the newer flaws as needing authentication on their own, local in the case of CVE-2026-111357. Rapid7's view is that the combination calls for emergency action whatever the individual numbers say. Patching on schedule did not help either: Volexity found the chain on an appliance that was fully up to date at the time, on 22.8R2.4. PHP2Shell had the same attacks-before-patch shape last month.

If I already patched, could my VPN appliance still be compromised?

Yes. A patched Ivanti Connect Secure appliance can still be compromised, because a patch closes the way in and removes nothing an attacker already took. Stolen domain credentials stay valid after the update. A box on 22.8 or 25.1.1 had at least 10 days with no fix for the first flaw, and at least 26 days for the two newer ones.

CISA's federal directive, BOD 26-04, makes a similar point: it sets expectations for when agencies must check whether attackers got in before the patch went on, and calls for a forensic triage on flagged flaws. CVE-2026-104935 and CVE-2026-111357 carry the catalog's forensic triage flag, and CVE-2026-118527 does not. The directive binds federal civilian agencies, not you, but the reasoning carries over.

Here is how we would read your own dates. This table is our judgement, not Ivanti's or CISA's.

The second row is easy to underrate. The 13 October build shut the unauthenticated door, but CVE-2026-118527 still works for a remote logged-in attacker and CVE-2026-111357 for a local authenticated one, so a login stolen before then may still have been useful. That is our reading of the two facts together, not a reported attack.

Does the Ivanti integrity checker prove an appliance is clean?

No. The Ivanti Integrity Checker Tool cannot prove an appliance is clean, because this chain is built to leave it nothing to compare. Volexity reports that "the tool does not detect any modifications", since the library is changed only in memory and the configuration data is restored. CISA says the tool "may not detect" this exploitation.

Rapid7 reaches the same conclusion, "so a clean result does not rule out compromise". Ivanti's 13 October update advises running the tool regularly, and you should. Just read the result in one direction: a finding tells you something, and a pass tells you very little.

The other usual checks are weak here too:

• No backdoor or web shell. Volexity identified no first-stage malware or web shell, and the full chain was re-run for each command. The Stack, summarising Volexity, says commands and results moved inside the exploit's own HTTPS requests.
• Logs on the box cannot be trusted. Volexity says the attacker deleted evidence from the appliance's debug and audit logs, though it has not fully established how far each cleanup step succeeded. Either way, an empty log proves nothing.
• Few indicators, but not none. Volexity's indicator file holds one IP address, and Rapid7 lists 108.165.147[.]64 as the exploitation IP. Rapid7 also reports that Volexity provides YARA rules. Volexity and Rapid7 also name files to check: /tmp, /data/.icscap (including a process named dsstatmond) and /home/runtime/tmp. Give these to whoever examines the box. Finding them matters, but their absence is not an all-clear. CISA says finding out needs network and memory forensics.

One network clue also helps. Volexity advises watching for large numbers of requests to /dana-na/auth/url_default/welcome.cgi and, if possible, for a URL path and an X-DSCGI-PATH header that do not match. Rapid7 repeats this guidance. Search for these in records the attacker could not edit, which means a device that decrypts the traffic, such as a TLS-terminating proxy, load balancer or WAF. A plain firewall cannot see URLs or headers inside HTTPS. Our own advice, which neither source gives, is to check it anyway for connections from 108.165.147[.]64 and unusual spikes to the appliance. Finding them is a strong signal. Not finding them is not an all-clear.

Evidence also depends on order. Rapid7 says to save memory and logs before any reboot or reset, where that is feasible, and CISA's guidance for federal agencies warns that patching can destroy artifacts. If you have already patched, some of that evidence may be gone. Most small teams cannot run memory forensics anyway. So our advice is to stop trying to prove the box clean and decide on exposure instead.

What should I rotate after a suspected VPN appliance compromise?

After a suspected compromise of a VPN appliance, rotate every secret the box stored or could see, and do it after the rebuild, or the attacker may read the new values too. CISA's list covers all domain, administrator and local account passwords, stored certificates, stored API keys and license server credentials. Volexity's findings show why that list reaches well past the VPN.

Some of those rows need a plain caveat. Rapid7's advice is to rotate potentially exposed credentials, and Volexity's own statements are observations: it does not itself recommend rotating anything. The attacker's parser was built to pull plaintext LDAP and HTTP Basic credentials and NTLM hashes from the capture; Volexity does not say what it recovered. The live-session warning comes from February 2024 and concerns different CVEs.

No source says this attacker took a SAML certificate. Check whether the appliance acts as your SAML identity provider. Ivanti's Cloud Secure help describes that role, with Connect Secure signing SAML responses with a private key. If yours does, it holds the signing key, and that key belongs with the stored certificates above. If the identity provider is a separate system, its signing key is not among what CISA lists.

For a heavier model, look at CISA's 2024 direction on earlier Ivanti flaws. It told agencies to assume associated domain accounts were compromised, reset on-premises passwords twice, revoke Kerberos tickets and revoke cloud tokens in hybrid setups. CISA has not repeated this in its 2026 alert, and it concerns different CVEs. We would use it if your evidence suggests the directory itself was reached. Separately, CISA's February 2024 advisory, AA24-060B, warned that a sophisticated actor might survive a factory reset. No 2026 source reports that here, and Volexity saw no backdoor or web shell at all.

Rotation is faster when you already know where every secret lives, which was also the lesson of October's hosting platform leaks. If this list surprised you, it is worth making your own.

What should I do this week about the Ivanti Connect Secure vulnerability?

Responding to the Ivanti Connect Secure vulnerability should start today if the appliance is reachable from the internet. Steps one to three are one person's work, and the order matters because an upgrade or a reset can destroy evidence.

1. Write down one build and your dates. Note the build on the box now, the date of each October upgrade, and whether the appliance faced the internet. If an IT provider runs it, send one line: "Which build is our Ivanti Connect Secure on, when was each October update installed, and was memory captured first?"
2. If it is still on an affected build, capture before you change it. Save memory and logs where you can, and export what the admin console offers. Do not let this hold up the upgrade for long, because an open box is the bigger risk.
3. Upgrade, then check the build number afterwards. Confirm the target on Ivanti's advisory. If you are on 22.8, plan your move off it before 31 January 2027.
4. Run the Integrity Checker and record the result. A finding means stop and get help. A pass changes nothing in this list.
5. Search the records the attacker could not edit. On a device that decrypts the traffic, such as a TLS-terminating proxy, load balancer or WAF, look for bursts of requests to welcome.cgi. A plain firewall cannot see URLs inside HTTPS, so our own advice is to check it for connections from 108.165.147[.]64 and unusual spikes to the appliance. On your domain controllers, look for the VPN's service account signing in from anywhere else, and for failed logins spread across many accounts.
6. Make the call and write it down. If the box was reachable on an affected build and you cannot show otherwise, treat it as compromised. That is our judgement, not a requirement from Ivanti or CISA. If you see signs of someone working inside your network, bring in an incident response firm with memory forensics experience before you clean anything up.
7. Recover in CISA's order. Back up the configuration, factory reset and upgrade (rebuild cloud and virtual instances), restore the configuration, then rotate everything in the table above. We would end all live sessions at the same moment.
8. Make the next one smaller. Give the LDAP service account only what it needs, so it cannot read LAPS passwords or BitLocker keys. Encrypt LDAP traffic so a packet capture yields nothing readable. Send appliance logs to somewhere off the box. And put the VPN at the top of your list of internet-facing systems that get patched first.

There will probably be a next one. The Stack counted 26 Ivanti vulnerabilities added to CISA's catalog since the start of 2024, across all Ivanti products, six of them in 2026, in a report published on 29 October, the day before CISA's latest two additions. Our own count of the catalog's 30 October version, which includes those two, is also 26, with eight in 2026. Those are counts of flaws, not a comparison with other vendors, but they are a fair reason to plan for the appliance being attacked again. As we have written before, attackers increasingly log in rather than break in, and a compromised VPN box can hand them a login.

Find out how far a stolen VPN login would get

The question that matters after this incident is how far someone gets once they hold your VPN box and its service account. A penetration test answers that directly. Our VAPT service covers external and internal networks and servers, scores every finding with CVSS so you fix the worst first, retests for free once you have, and gives you a signed letter for customers, auditors or regulators. Our security and compliance team handles the follow-through: access reviews, logging and tested incident runbooks.

A penetration test is not forensics, so if you have signs of an intrusion today, start with an incident response firm. Once that is done, tell us what sits behind your VPN and book a discovery call. We will tell you what we would test first.

Part of our guide to AI security.

Sources: Volexity's technical report (first exploitation date, the chain, credential theft, log tampering and its limits, Integrity Checker result, hunting guidance), CISA's 13 October alert (affected versions, recovery and rotation steps), CISA's 30 October alert (catalog additions, BOD 26-04), CISA's KEV catalog (chaining, forensic triage flags, Ivanti count), CISA's BOD 26-04 directive (forensic triage), CISA's BOD 26-04 guidance (preserving evidence), Rapid7 on the newer CVEs and on CVE-2026-104935 (fixed builds, scores, clean-result warning, 22.7), SecurityWeek (Defused's date, federal deadlines, Ivanti's statement), The Stack (fixed builds, KEV count), Ivanti's 13 October update (limited exploitation, Integrity Checker advice), Ivanti's Cloud Secure help (SAML identity provider role and signing key), BleepingComputer (Shadowserver count), the CVE records for CVE-2026-104935 and CVE-2026-111357 (scores), and CISA's 2024 Ivanti advisory and supplemental direction (older guidance on different CVEs). Verified against these sources on 2 November 2026.