Monday, November 2, 2026
News

Ivanti VPN patched in October? 22.8R2.5 and 25.1.1.2 are still open

Ivanti's October builds closed the login bypass in an exploited attack chain but left the other two steps open. Those are fixed in 25.1.1.3 and 22.8R2.6. CISA's federal deadline for the worst of them is November 2.

Close-up of a computer motherboard cpu socket

CISA added two more Ivanti Connect Secure flaws to its Known Exploited Vulnerabilities catalog on October 30, a day after Ivanti shipped fixes for them. They are the second and third steps of an attack chain that Volexity, the security firm, caught in early October. The first step, CVE-2026-104935, went on the list on October 13. The new two are CVE-2026-118527 and CVE-2026-111357. Federal civilian agencies have until November 2 to deal with CVE-2026-111357, forensic triage included, and until November 13 for CVE-2026-118527.

The catch is in the version numbers. Teams that moved quickly in October installed 25.1.1.2 (released October 5) or 22.8R2.5 (October 12). Those builds fixed the login bypass and nothing else. Both are listed as affected by the two new flaws, so a VPN appliance patched in October has spent between 17 and 24 days on a build that is still exposed. Ivanti's advisory, as quoted by Security Affairs, says the company decided not to hold back the fix for the main way in while it worked on the rest.

The three flaws

CVE What it does Score
CVE-2026-104935 Bypasses login; lets a remote attacker with no account run commands 8.6
CVE-2026-118527 Lets a logged-in attacker upload files to a predictable location 4.3
CVE-2026-111357 Missing authentication on a critical function; local escalation to root 8.8 from Ivanti, 7.0 in NVD

Chained, they take an attacker from the internet to root on the appliance. Ivanti says exploitation has hit "a limited number of customers" and has not given a count.

Which build to install

You run Exposed to the new flaws? Move to
22.8R2.5 or earlier Yes 22.8R2.6
25.1.1.2 or earlier Yes 25.1.1.3
25.1.2.x Possibly; sources disagree A fixed line; confirm with Ivanti
25.1.3.0 Check 25.1.3.1
22.7.x or earlier No None for this chain

The 25.1.3 line is where the sources disagree. Ivanti fixed part of the flaw in 25.1.3.0 in July, but the Canadian Centre for Cyber Security's advisory, last updated October 30, lists Connect Secure versions before 25.1.3.1 as affected. We could not open Ivanti's own advisory to settle it, so 25.1.3.0 owners should confirm there before deciding they are done. Ivanti offers no workaround: the fix is the upgrade.

The 22.7 and 22.8 lines lose support on January 31, 2027, and Ivanti tells customers to move to 25.1 before then, according to ITdaily. Anyone upgrading under pressure this week may want to plan that jump at the same time.

Why a clean scan is not enough

Volexity found the attack on an appliance running 22.8R2.4, which was fully patched at the time. The group it tracks as UTA0576 installed no web shell or malware. It took stored credentials, Active Directory data, local admin passwords and BitLocker recovery keys, recorded LDAP traffic passing through the appliance, then cleaned up the logs. Volexity said Ivanti's Integrity Checker Tool does not detect the changes this chain makes, and CISA warned the tool can miss the activity because the commands run in memory.

Threat intelligence firm Defused first saw the activity on October 1. Volexity rates its own view that the group is criminal, not state-backed, as low confidence.

What IT teams should do

  1. List every Connect Secure appliance, including virtual and cloud instances and any an MSP runs for you, with its exact build.
  2. Upgrade anything on 22.8R2.5, 25.1.1.2 or earlier to 22.8R2.6 or 25.1.1.3. Do not count an October upgrade as done.
  3. If you run 25.1.3.0 or 25.1.2.x, check Ivanti's advisory for the build to install.
  4. Search web logs stored off the appliance, back to late September, for requests to /dana-na/auth/url_default/welcome.cgi that carry an X-DSCGI-PATH header.
  5. In Active Directory, look for Kerberos and failed-logon events (4769, 4771, 4625) from the appliance's IP or service account.
  6. Rotate the LDAP service account the appliance uses, and think about new LAPS passwords and BitLocker recovery keys for any machine whose secrets the appliance could read.
  7. If anything looks wrong, follow Ivanti's recovery steps: back up the configuration, factory reset, upgrade, restore, and reset every account password and certificate on the device.

Related: Cisco's ASA and FTD VPN zero-day, due November 1 and three VeloCloud zero-days since July.

Sources