Ivanti Connect Secure Chain Gets a Second Patch Deadline as Root-Level Exploitation Stays Active

Ivanti Connect Secure Chain Gets a Second Patch Deadline as Root-Level Exploitation Stays Active

Organizations that patched Ivanti Connect Secure after the first October disclosure still need to revisit the appliance. Two additional flaws in the same attack chain entered CISA's Known Exploited Vulnerabilities catalog on October 30, and the first federal remediation deadline is November 2.

What changed

Volexity observed an attacker it tracks as UTA0576 chaining an authentication bypass and remote code execution flaw tracked as CVE-2026-104935 with a privilege-escalation flaw that was later assigned CVE-2026-111357. The chain reached unauthenticated root-level code execution on a Connect Secure appliance, even one running the then-current 22.8R2.4 build.

Ivanti published the root-escalation fix on October 29. CISA added CVE-2026-111357 and CVE-2026-118527 to the KEV catalog the following day. CVE-2026-118527 covers another file-upload weakness used in the chain. The result is a remediation problem that cannot be closed by checking whether the appliance received the first October update: administrators must verify the complete fixed build for their hardware or virtual appliance.

Why a clean integrity check is not enough

Volexity's forensic analysis found that the attacker used in-memory library changes and restored the altered state after obtaining root. The actor also removed selected entries from Ivanti and Linux audit logs. Ivanti's Integrity Checker therefore cannot be treated as a definitive answer to whether a device was compromised.

After gaining access, UTA0576 extracted credentials stored on the appliance, queried Active Directory for LAPS passwords and BitLocker recovery keys, captured LDAP traffic, tested credentials, and performed network reconnaissance. That turns a VPN appliance compromise into a potential identity and lateral-movement incident rather than a contained edge-device patch.

The remediation queue

• Inventory every Ivanti Connect Secure appliance, exact release train, exposure, and authentication integration.
• Follow Ivanti's current advisory for the fixed release: reported fixed builds include 25.1.1.3 and 22.8R2.6, with the 25.1.3 line applying to supported hardware paths. Do not infer safety from the October 13 patch alone.
• If the appliance was exposed while vulnerable, preserve configuration, memory, network, and authentication evidence before rebuilding or factory-resetting it.
• Rotate every credential, certificate, API key, and license-server secret that the appliance could access. Review LDAP service accounts first, then investigate possible Active Directory and VPN-session abuse.
• Hunt for mismatched URL and X-DSCGI-PATH values, suspicious requests involving welcome.cgi or wu.cgi, unexpected files under /tmp, packet-capture activity, and gaps or selective edits in appliance audit logs.

The operational lesson is straightforward: a security gateway can be the first foothold and the credential collection point at the same time. Patch the complete chain today, then treat the investigation as an incident response exercise whenever exposure or suspicious telemetry exists.

The chain also illustrates why a zero-day on a perimeter appliance deserves a response plan beyond version checking. The original path combined authentication bypass, remote code execution, and privilege escalation; fixing one link does not erase evidence that the device may already have been used.

References

1. A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days
2. Ivanti security advisory (AV26-1035) - Update 2
3. Known Exploited Vulnerabilities Catalog
4. Security Advisory Ivanti Connect Secure (CVE-2026-104935)