Ivanti Connect Secure CVE-2026-111357: Why the October 13 Patch Isn't Enough

Those builds fixed CVE-2026-104935 only. Rapid7 states that "the October 13 fixes in 25.1.1.2 and 22.8R2.5 do not remediate CVE-2026-111357 or CVE-2026-118527," and SecurityWeek says organizations that installed those releases will need to upgrade again.

Volexity's October 13 post described three exploits: an authentication bypass and code execution, both tracked as CVE-2026-104935 and patched that day, and a privilege escalation with no fix yet. That's why The Record reported two of three patched. Volexity's update says Ivanti patched the privilege escalation on October 29 as CVE-2026-111357. CVE-2026-118527 isn't in Volexity's post; Rapid7 says Ivanti's updated advisory added it as another component of the chain.

KEV dates and flags come from CISA's catalog feed. We worked from Rapid7's table of Ivanti's advisory, so confirm builds in the advisory itself.

CISA describes both remaining flaws as needing an authenticated attacker, and Rapid7 reports Ivanti's statement of exploitation "when these flaws are chained with CVE-2026-104935." That doesn't make an October 13 build safe to leave alone. Exploitation predates that patch, and CISA has described credential theft, so stolen credentials may already exist. The Record reported Ivanti working with a "limited number of customers" exploited through the first flaw.

Don't queue these by score. Ivanti rates CVE-2026-118527 at 4.3, yet CISA's entries say each "can be chained" with the others.

For the 25.1.1 branch, 25.1.1.3. For the 22.8 branch, 22.8R2.6 is the fix, and Rapid7 says Ivanti recommends moving from 22.8 to 25.1.1.3 or later, using 22.8R2.6 if migration can't happen right away. The Hacker News reports that 22.8 reaches end of life on January 31, 2027.

The 25.1.2 branch is easy to miss, because its numbers look newer than 25.1.1.3. Rapid7 lists 25.1.2.2 and prior as affected by CVE-2026-104935, the remote unauthenticated flaw, with fixes in 25.1.3.0 and 25.1.3.1. It also says Ivanti lists 25.1.3.0 and later on the ISA4500, ISA6500 and ISA8500 as unaffected. The sources we reviewed don't cover other hardware, so check Ivanti's advisory and record the build each appliance reports.

The tool looks for unexpected file changes on disk, and Volexity says it doesn't detect this chain: the "exploit chain patches library code in memory only and restores configuration store data, the tool does not detect any modifications." Volexity concludes that "forensic investigation is required to identify evidence of exploitation."

That puts memory ahead of the upgrade where you can manage it. Rapid7 advises teams to "preserve memory and logs before rebooting or resetting where feasible," and it also recommends emergency patching and investigating afterward. Volexity collected memory and disk images with Ivanti's help, so ask Ivanti support now how to capture from your model. If capture can't happen quickly, your CISO's office decides whether to patch first and record what was lost. Our PHP2Shell post covers the triage sequence under Binding Operational Directive (BOD) 26-04.

Appliance logs need a second copy to mean much. Volexity says recent entries were selectively removed from the runtime debug log and the Linux audit log, so where those logs or related events are forwarded off the box, compare the two. Disk evidence still exists, and Volexity publishes indicators and rules to start from.

The review also has to leave the appliance. Volexity reports the actor used the appliance's Active Directory service account to search for Local Administrator Password Solution (LAPS) passwords, BitLocker recovery information and password attributes, and ran password spraying. Pull directory logs for that account.

For the lookback, Volexity dates the exploitation it observed to October 3, and SecurityWeek reports Defused saw decoy targeting from October 1. Open the window no later than October 1, or earlier if logs allow.

Mitigation under BOD 26-04, plus triage where flagged. All three entries tell agencies to apply vendor mitigations or stop using the product if none are available, and to evaluate each asset's internet exposure. Only CVE-2026-118527 has its triage flag set to "No." We'd run triage on any appliance that ran an affected build, because the other two entries carry the flag, and your CISO's office decides.

Our KEV explainer describes how BOD 26-04 timelines work, including the December 7, 2026 date by which agencies start remediating on them. Our PHP2Shell post covers how the directive reaches contractor-run systems; your contracting officer decides how it applies to an appliance you operate.

Capture first, since a factory reset destroys what's on the appliance, then rebuild and treat what it held as exposed. The Hacker News reports CISA's October list as backing up the configuration, running a factory reset and upgrade (or rebuilding the instance for cloud and virtual systems), restoring the configuration, and resetting passwords for all accounts, including domain, administrator and local accounts. It also calls for revoking and reissuing stored certificates and resetting API keys and license server credentials.

That list predates the October 29 fixes, and Rapid7 notes that the recovery procedure linked from Ivanti's advisory includes older release references, so check any build it names. Include the Active Directory service account, decide with your identity team whether LAPS passwords and BitLocker recovery keys need rotation, and follow your agency's incident reporting process.

Appliance owners list every Connect Secure instance with its running build and internet exposure. Anything on 25.1.1.2, any 25.1.2 build, or 22.8R2.5 and earlier goes into an emergency change, and an October ticket doesn't count as proof of a fix. Anything staying on 22.8 gets a migration date.

Responders arrange capture with Ivanti support, review forwarded logs and directory activity, and don't rest a conclusion on the Integrity Checker Tool.