On 29 October 2026 Ivanti released fixes for two more Ivanti Connect Secure zero-days, CVE-2026-111357 and CVE-2026-118527, which attackers had chained with the earlier CVE-2026-104935 to get unauthenticated root code execution. The “fully patched” description fits the build Volexity examined (22.8R2.4 at the time of its report), not the new fixed builds. Volexity tracks the actor as UTA0576 and saw the chain in use from 3 October, and NCSC-NL’s advisory notes that 25.1.1.2, earlier treated as patched, is still vulnerable to the two new flaws.

If you ran 25.1.1.2 or 22.8R2.5 and closed the ticket, a VPN appliance compromise is an open question for you. The fixed builds are 25.1.1.3 and 22.8R2.6. Installing them is necessary and tells you nothing about what happened before you did.

Confirm the affected and fixed builds directly in Ivanti’s advisory, CISA’s alert and Volexity’s write-up; we could not read those pages in full and worked from reporting around them. NCSC-2026-0416 is not a new advisory: it was first published on 13 October and later updated with the two new CVEs.

What the Ivanti Connect Secure chain does to your evidence

The three flaws are an authentication bypass (CVE-2026-104935, CVSS 8.6), a privilege escalation (CVE-2026-111357, CVSS 8.8) and a file-upload flaw through predictable identifiers (CVE-2026-118527, CVSS 4.3). The privilege escalation had no fix available when the attacks came to light. Volexity reports that UTA0576 deployed no malware and no web shell. It re-exploited the device for every command, selectively modified logs, removed temporary execution artifacts and restored altered system state, which evaded Ivanti’s Integrity Checker Tool.

Volexity also says it could not establish that every cleanup operation succeeded. That is the one useful weakness: tampering is imperfect, but you will only catch it if you hold a second copy of the record that the attacker never touched.

Volexity assesses the actor as criminally motivated rather than espionage-driven, with low confidence. Scope is unknown; Ivanti said a limited number of customers were hit, and Volexity’s report covers one investigated device. Plan for the worst case on your own appliance, not the average one.

One report says Ivanti states dependable indicators of compromise are not available; check Ivanti’s advisory. Either way, a clean result from the vendor’s checker is weak evidence when the checker is the thing that was evaded.

Patch-then-hunt: the incident response checklist we would run

The tension is simple. Rapid7 advises preserving memory and logs before rebooting or resetting where feasible, and Volexity found the full chain in memory. Volexity also warns that a suspected compromise needs memory, disk and network analysis together.

  1. Restrict exposure first. If the portal can be limited to known source ranges, or taken offline until you have captured evidence, do that before anything else. One report says Ivanti published no supported workaround for the two new CVEs, so this is our interim advice, not Ivanti’s.
  2. Ask Ivanti before you act, then capture memory and disk. We have not verified a method for pulling a memory image from the appliance, so ask Ivanti support and your incident-response provider how to do it on your build before you touch the power. Then take the memory image, then a disk image or backup, and store both off the appliance.
  3. Upgrade to 25.1.1.3 or 22.8R2.6. Ivanti recommends 22.8.x customers move to 25.1.1.3 or later; one source reports 22.7 and 22.8 reach end of life on 31 January 2027, so check the date with Ivanti.
  4. Hunt from the outside in, using the evidence in the next section.
  5. Rotate, then decide on rebuild.

If you cannot afford the capture step, patch anyway and accept the loss. An exploited, unpatched appliance is worse than an unexamined one.

Evidence that must live outside the appliance

This is not the usual “ship your logs off the box” advice. Here the vendor’s own integrity checker was evaded and the local logs were selectively edited, so the off-box copy is your only independent record. We run a 24/7 SOC, and in our SecOps service customer logs are stored in our datacenters and seen only by EU staff; whatever stack you use, keep the log somewhere the appliance cannot edit.

When the integrity checker can be evaded, the only honest witness is the copy that left the box before the attacker arrived.

  • Forwarded syslog and SIEM copies from before 3 October. Compare them with the local logs. A gap, or a local log shorter than the forwarded one, is a possible tamper indicator.
  • Firewall and proxy logs in front of the appliance. Volexity saw no malware or web shell, and it re-exploited the device for every command, so look for repeated requests to the portal, their volume and their source addresses.
  • Flow data and packet captures from the segment behind it.
  • Domain controller logs for everything the appliance’s internal address and its service accounts touched.
  • The memory image you took before the reboot.

Edge device threat hunting: look behind the appliance

Hunt behind the device: look at what the attacker did next, because that happens on systems you control. Volexity saw credential theft, Active Directory reconnaissance and data exfiltration, including LDAP packet capture and a Python LDAP tool searching for administrator passwords and BitLocker recovery keys. Other reporting adds VPN credential extraction, LAPS password searches and password spraying.

  • LDAP queries from the appliance or its bind account that read password-related attributes, LAPS attributes or BitLocker recovery objects, especially in bulk.
  • Failed-logon patterns that look like spraying from the VPN’s internal address range.
  • VPN sessions for users who were not working, or that originate from unexpected sources, since at least 3 October.
  • Outbound transfers from file servers or the appliance’s segment that match no backup or sync job.

Treat IOC lists as a supplement. Volexity’s indicators are reportedly published on GitHub; validate them there rather than from aggregators, and do not let a no-match result end the hunt.

What to rotate

CISA’s recovery sequence, as relayed by a secondary source, runs: back up, factory reset and upgrade, restore, reset all passwords, reissue certificates, reset API keys and license server credentials. CISA’s earlier advisory for a different Ivanti flaw (CVE-2025-22457, April 2025) added resetting the admin enable password, stored API keys and local user and service-account passwords. It also added resetting on-premises passwords twice, revoking Kerberos tickets and revoking cloud tokens. That was another CVE, so check it against the current Ivanti and CISA text before you adopt it.

Scope the rotation by what the actor went looking for, not by what you can prove was read:

  • Every credential that touched the appliance: LDAP bind accounts, local accounts, admin and enable passwords.
  • Certificates and private keys held on it, plus API keys and license server credentials.
  • Directory secrets the actor searched for: LAPS-managed passwords, and BitLocker recovery keys if you have any reason to think they were read.
  • Sessions and tokens: Kerberos tickets and cloud tokens for accounts that authenticated through the VPN.

Factory reset is conservative guidance, not proof of persistence. We found no source establishing that 25.1.1.3 or 22.8R2.6 fully removes an attacker’s access if the device was already compromised. We would rebuild.

Count from 3 October, not from the KEV due date

CISA added both new CVEs to KEV on 30 October 2026, and federal due dates were reported as 2 November and 13 November; confirm them in the catalog. The CISA KEV due dates tell you when exploitation became undeniable, not when it began. Volexity saw UTA0576 using the chain from 3 October, so your window to examine runs from at least then, not from the day you upgraded.

Sources