Skip to content
HACKTECH
Exploited vulnerabilitiesReported Published 6 sources

Ivanti Connect Secure zero-day chain gave attackers root on fully patched VPNs

On 13 October 2026 Ivanti disclosed and patched CVE-2026-104935, an authentication bypass in Connect Secure that lets a remote unauthenticated attacker execute arbitrary commands, and said a limited number of customers were affected. Volexity found it being exploited by a previously undocumented actor it tracks as UTA0576. According to Volexity, the actor chained it with a privilege escalation flaw to get unauthenticated root-level code execution on an appliance running 22.8R2.4, the latest release at the time. Ivanti fixed the remaining chained flaws, CVE-2026-111357 and CVE-2026-118527, on 29 October, and CISA added both to its KEV catalogue the next day.

  • Ivanti
  • Connect Secure
  • VPN
  • zero-days
  • exploit chains
  • Active Directory
  • CISA KEV

What the sources report

  • Volexity's report says exploitation of the appliance it investigated began on 3 October 2026, and Volexity told CyberScoop the earliest confirmed exploitation was on 1 October. Defused separately reported the first signs of CVE-2026-104935 exploitation from 1 October, before public disclosure (BleepingComputer, SecurityWeek).
  • The chain sent requests carrying an X-DSCGI-PATH header to the public welcome.cgi page to reach the protected wu.cgi upload handler, then used parallel requests to run an uploaded Perl script before it was deleted. To gain root it patched a library in memory and altered a DSCache entry so that the root-level dsinvoked service ran the attacker's code, then restored both (Volexity).
  • After exploitation the actor went after identity data. It extracted domain credentials stored on the appliance, used a custom LDAP tool to search Active Directory for LAPS passwords and BitLocker recovery keys, ran a custom Kerberos tool, sprayed passwords and parsed an existing LDAP packet capture (Volexity).
  • Volexity found no web shell or backdoor. The actor re-exploited the device for each command and removed entries from debug and audit logs. Volexity said Ivanti's Integrity Checker Tool did not detect the in-memory changes, and assessed with low confidence that UTA0576 has criminal rather than espionage motivations.
  • SecurityWeek listed 22.8R2.5, 25.1.1.2, 25.1.3.0 and 25.1.3.1 as fixed versions for CVE-2026-104935. CVE-2026-111357 (CVSS 8.8) and CVE-2026-118527 (CVSS 4.3) required 25.1.1.3 or 22.8R2.6, so organisations that installed the releases from the initial advisory had to upgrade again.
  • CISA added CVE-2026-104935 to KEV on 13 October with a 16 October deadline, and the other two on 30 October. Ivanti told CyberScoop that part of the flaw was found in internal checks in June but did not meet its threshold for an out-of-band release. Shadowserver tracked over 5,500 Connect Secure instances exposed online (BleepingComputer).

What it means for your organisation

Ivanti found part of this flaw internally in June and scheduled the fix for its normal release cycle; SecurityWeek reports that fix shipped in version 25.1.3.0 in July, while the 22.8R2.4 appliance Volexity investigated was fully patched and still exploited in October. Because the actor ran commands in memory and edited logs, Ivanti's integrity checker found nothing, and CISA said organisations would need network and memory forensics to check for compromise. A VPN appliance that holds a directory service account and sees plaintext LDAP traffic gives an intruder a short path into identity systems, so that account should be able to read only what authentication needs, not LAPS passwords or BitLocker recovery keys.

What we check

  • Confirm every Connect Secure appliance runs a release that fixes all three chained flaws (22.8R2.6 or 25.1.1.3 on those branches), including appliances updated only for the 13 October advisory.
  • Review what the VPN's Active Directory service account can read, especially LAPS password and BitLocker recovery attributes, and cut it back to what authentication needs.
  • Look for requests to /dana-na/auth/url_default/welcome.cgi that carry X-DSCGI-PATH headers, gaps in debug and audit logs, and processes running from hidden paths such as /data/.icscap.
  • Identify plaintext LDAP, HTTP Basic and NTLM authentication passing through the appliance, and move directory binds to LDAPS.
  • Check domain controller logs for password spraying and Kerberos activity coming from the appliance's internal address.

Sources

Services that cover these checks

  • Network & infrastructure testing

    Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.

    Duration: 5 to 12 working days

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • Red team & purple team

    Objective-based adversary simulation: we agree the objectives, try to reach them over several weeks and measure what your detection and response do along the way. Purple mode runs the same scenarios with your defenders in the room, tuning detection as each technique is replayed.

    Duration: 3 to 6 weeks

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works