Ivanti Fixes Two More Exploited Connect Secure Flaws 16 Days After Its First Advisory, and Two Builds That Advisory Called Fixed Are Now Affected

Ivanti has released new builds of Connect Secure, its SSL VPN gateway, that fix two more flaws attackers chained with the authentication bypass it disclosed on October 13, and two of the builds that first advisory called fixed are now on the affected list. Ivanti added CVE-2026-111357, a privilege-escalation flaw, and CVE-2026-118527, a file-upload flaw, to its existing advisory on Thursday, October 29, with fixes in versions 25.1.1.3 and 22.8R2.6. CISA added both to its Known Exploited Vulnerabilities (KEV) catalog on Friday, October 30. Federal civilian agencies have until Monday, November 2 for the first and Friday, November 13 for the second.

None of this is a surprise to anyone who read Volexity’s October 13 report, which described all three steps of the chain and said Ivanti was still working on a fix for the privilege-escalation step, due in “a future release in the coming weeks.” What October 29 adds is the fix, a second upgrade for every appliance that moved to 25.1.1.2 or 22.8R2.5, and public records that disagree with each other in ways that matter to defenders. Our October 13 post covers the chain, the attacker’s actions and the artifacts to hunt for. This one covers what changed.

What Ivanti changed on October 29

As far as we can see, Ivanti did not announce the update separately. Its October security update blog post still reads “Last updated: October 13, 2026,” and the newest item in its security advisory feed is that same post. The change shows up only in the October 13 advisory, which now opens with “Update 29 Oct: Updated versions of Ivanti Connect Secure have been released which address two additional vulnerabilities.” Its summary says Ivanti is “aware of exploitation in the wild affecting a limited number of customers at the time of disclosure when CVE-2026-104935, CVE-2026-111357 and CVE-2026-118527 are chained.” The advisory now lists three flaws:

The FAQ explains why the two were missing on October 13: “At the time of discovery of exploitation, Ivanti had a fix developed for CVE-2026-104935 which was already in QA for supported versions, and we made the decision to not delay getting a fix to customers that resolved the primary exploitation path when the LPE was discovered.” Another answer says “A fix is available now for all vulnerabilities which were chained and exploited in the wild,” and repeats that Ivanti “initially discovered a portion of this vulnerability as part of our product security program and patched it in the July release 25.1.3.0.”

Two details matter for anyone who acted on October 13. First, the affected range for the new CVEs ends at 25.1.1.2 and 22.8R2.5, the very builds the first advisory listed as fixed, so those appliances need another upgrade. SecurityWeek says the same. Second, Volexity’s report says the remote code execution and authentication bypass components of the chain are both tracked under CVE-2026-104935, while the new CVE-2026-118527 is described as predictable filenames and an upload to a known location. Volexity’s account of the code-execution step involves an upload handler that names each file after an MD5 hash of the client-supplied file name, so we read the new CVE as that part of the chain. Neither company says so. If the reading is right, the October 13 builds removed the unauthenticated route to the upload but not the upload flaw itself, and the reading we gave on October 13, that those builds closed the first two steps, was incomplete.

Which build to run now

Ivanti’s Solution section recommends that 22.8 customers move to 25.1.1.3 or later, and says customers who cannot move at once can take 22.8R2.6, which “resolves all vulnerabilities in this disclosure.” For 25.1.1.1 on ISA6000 or ISA8000 hardware it names 25.1.1.3 for the same reason. The table sets the two advisories side by side; the last column is our reading of the updated tables and Solution text.

Two more facts sit behind that table. Ivanti says 22.7 and 22.8 both reach end of life on January 31, 2027, less than three months away, and calls 22.8 “only meant to be a temporary bridge from 22.7 to 25.1.” Moving to 25.1.3.0 needs the newer platform: ISA4500, ISA6500 or ISA8500 hardware, or virtual and cloud devices built from the 25.1.3.0 template.

Timeline

By our arithmetic, Ivanti’s fix for the privilege-escalation flaw arrived 16 days after its first advisory, 26 days after Volexity says exploitation of its customer began, and 14 days after the CVE record for the flaw became public. MITRE, not Ivanti, is the assigner on that record, which says “Ivanti Connect Secure 22.8R2.4 mishandles the manner in which the dsinvoked broker trusts DSCache configuration data, leading to privilege escalation to root, as exploited in the wild in October 2026.” Canada’s Cyber Centre added an update to its advisory AV26-1035 saying “Open-source reporting indicates that CVE-2026-111357 is being exploited in the wild.”

CISA’s own data on CVE-2026-111357 did not show exploitation until October 30. The history of its SSVC entry on CVE.org and in its Vulnrichment repository shows exploitation set to none from the entry’s first appearance on October 16 until 17:26 UTC on October 30, the day of the KEV listing, when it became active. NVD’s record now shows active beside an October 15 timestamp. That stamp is stale, not a sign that CISA rated the flaw active on October 15.

Where the sources disagree

What CISA’s deadlines mean

CVE-2026-111357 is due Monday, November 2, three days after listing, and carries CISA’s forensic triage flag. CVE-2026-118527 is due Friday, November 13, 14 days after listing, with no triage flag. The gap comes from Table 1 in BOD 26-04: a publicly exposed asset with a KEV entry gets three days plus forensic triage if the exploit gives total control, and 14 days if the exploit is not automatable and gives only partial control. CISA’s data for CVE-2026-111357 says automatable no and technical impact total, which is the first case. The 14-day entry for CVE-2026-118527 is consistent with the second, but CISA has published no SSVC data for it because its CVE record does not exist yet, so that mapping is our inference.

That puts agencies in an awkward spot. An appliance upgraded to 25.1.1.2 or 22.8R2.5 to meet the October 16 date has 17 days between deadlines, and the second asks for fresh forensic triage on a chain that, by Volexity’s account, defeats Ivanti’s own file-integrity tool. CISA’s implementation guidance says “Do not alter or remediate systems prior to evidence/artifact collection when possible” and warns that “patching may jeopardize the availability of artifacts.” Volexity says the chain “patches library code in memory only and restores configuration store data,” so “the tool does not detect any modifications” and “forensic investigation is required.” Ivanti’s FAQ still tells customers to “run the Integrity Checker Tool regularly.”

By our count of the KEV feed (catalog version 2026.10.30), CISA now lists 38 Ivanti entries, 12 with known ransomware use, which matches BleepingComputer’s tally. The three October entries are its first for Connect Secure since CVE-2025-22457 in April 2025, and CISA lists ransomware use as Unknown for all three.

What we still do not know

• How many customers were hit. Ivanti says “a limited number” of customers at the time of disclosure and gives no count. BleepingComputer cites Shadowserver for more than 5,000 internet-exposed appliances, with no data on how many are patched; we did not check the dashboard.
• Whether anyone used the new flaws against the October 13 builds. Ivanti’s exploitation statement is about the time of disclosure, and we found no later report in anything we read. That is a gap in our reading, not evidence that it did not happen.
• Whether an authenticated attacker could still reach root on those builds. Ivanti scores both new flaws as needing a low-privileged account and calls the first one local, and says its October 13 fix “resolved the primary exploitation path.” The advisory does not say what other route to code execution an attacker would need, and the actor in Volexity’s report took credentials stored on the appliance.
• Whether the Integrity Checker Tool can now see this chain. The advisory does not say.
• Whether 25.1.2.x builds are affected by the new flaws. The new table has no 25.1.2.x row, and the October 13 table sent those builds to 25.1.3.0 or 25.1.3.1.
• Whether there is a workaround. The advisory offers upgrades only.

What to do

1. Check every build against the table. An appliance on 22.8 before R2.6, on the 25.1.1 branch before 25.1.1.3, or on 25.1.2.2 or earlier is affected by at least one of the three flaws.
2. Collect evidence before upgrading if the appliance was internet-facing while it ran a build affected by CVE-2026-104935. That is CISA’s sequence for federal agencies, and Volexity’s findings explain why it fits this chain. Our October 13 post lists the request pattern and artifacts Volexity published.
3. Upgrade to 25.1.1.3 or 22.8R2.6, or move to 25.1.3.x on the newer platform. Ivanti recommends 25.1.1.3 or later for 22.8 customers.
4. Rotate what the appliance held. Volexity says the actor took credentials stored on the appliance, such as the domain credentials used with LDAP, and searched Active Directory for LAPS passwords and BitLocker recovery keys through a compromised service account.
5. Plan the exit from 22.x before January 31, 2027. Both 22.7 and 22.8 reach end of life that day.

Sources and method

We read Ivanti’s advisory, a JavaScript page that we rendered in a headless browser to read its tables and FAQ, together with Ivanti’s blog post and advisory feed; Volexity’s report, including the update note about Ivanti’s October 29 patch, and its indicator folder, which has had one commit, on October 13; Defused’s post; CISA’s KEV feed (catalog 2026.10.30), alert, BOD 26-04 text and Table 1 image, and implementation guidance; the CVE.org and NVD records, checked at 10:22 UTC on November 2, and the commit histories of CISA’s SSVC data in cvelistV5 and Vulnrichment; the Canadian Cyber Centre’s advisory; and reporting from SecurityWeek and BleepingComputer. The advisory’s timestamps carry no time zone, so we use dates only. Ivanti’s recovery-steps article needs a customer login and we could not read it. We did not test anything on an appliance, and the mapping of CVE-2026-118527 to Volexity’s second step and of the 14-day deadline to Table 1 are our readings.