Ivanti Connect Secure zero-day chain steals AD secrets

CVE-2026-104935

Volexity says a previously unknown actor chained an Ivanti Connect Secure (ICS) zero-day with a privilege escalation flaw to get root on fully patched VPN appliances. The attacker then used the appliance's own LDAP credentials to pull LAPS passwords and BitLocker recovery keys out of Active Directory. Ivanti has fixed CVE-2026-104935, but the root escalation is still unpatched, so treat any affected appliance as a possible identity incident.

What happened

Ivanti disclosed CVE-2026-104935 on October 13, 2026. It said it was aware of limited exploitation in the wild and told customers on impacted versions to act immediately. Rapid7 describes the flaw as authentication bypass by spoofing (CWE-290) with a CVSS score of 8.6, leading to unauthenticated command execution. CISA added it to the Known Exploited Vulnerabilities catalog the same day. BleepingComputer reported that federal agencies were ordered to secure their devices by Friday.

Volexity found the activity and attributes it to UTA0576, which it assesses with low confidence as criminally motivated. Exploitation began on October 3. The chain has three steps:

  • Authentication bypass: requests to /dana-na/auth/url_default/welcome.cgi carry an X-DSCGI-PATH header that routes the request to a protected CGI script.
  • Remote code execution as the cgi-server user, using a race condition in a file upload handler. The bypass and the RCE are tracked together as CVE-2026-104935.
  • Privilege escalation to root by patching an Ivanti library in memory. Volexity says Ivanti is working on a fix that will ship in a future release within weeks.

Fixed builds, per Rapid7 and BleepingComputer: 22.8R2.5 (for 22.8R2.4 and earlier), 25.1.3.0 and 25.1.3.1 (for 25.1.2.2 and earlier), and 25.1.1.2 (for 25.1.1.1 and earlier). Rapid7 says 22.7.x and below are not affected.

Patch status: the released builds fix CVE-2026-104935 only. Volexity, The Hacker News and Rapid7 all say the root escalation is still unpatched. BleepingComputer's October 14 article says the builds shipped on Tuesday, which matches Volexity's October 13 patch date.

Why it matters

The real damage happened behind the appliance. Volexity reports that UTA0576 extracted credentials stored on the VPN, including LDAP domain credentials. With those it searched Active Directory for LAPS local administrator passwords, BitLocker recovery keys and password-bearing attributes such as userPassword and unixUserPassword. A renamed tcpdump also captured plaintext LDAP and HTTP Basic credentials plus NTLM challenge-response hashes. The Hacker News adds that the actor ran password spraying against domain accounts and left no web shell or backdoor.

The lack of persistence is also why detection is hard. Volexity says the Integrity Checker Tool does not catch this chain, because the exploit modifies library code only in memory and restores the configuration data it changes. A clean ICT scan does not prove the appliance is clean.

A VPN appliance whose LDAP bind account can read LAPS and BitLocker attributes is effectively a privileged identity. Patching closes the way in, but anything that account could read stays exposed until you rotate it.

What to check in your environment

  • Inventory ICS appliances and upgrade to 22.8R2.5, 25.1.1.2, 25.1.3.0 or 25.1.3.1 now. Track Ivanti's advisory for the separate privilege escalation fix.
  • Hunt back to at least late September for large numbers of requests to /dana-na/auth/url_default/welcome.cgi, especially where X-DSCGI-PATH doesn't match the URL path. Also look for connections from 108.165.147[.]64.
  • Check /data/.icscap/ for a binary named dsstatmond and /tmp/ for Python scripts or staged data. Volexity recommends memory forensics, because the ICT may miss this chain.
  • If you suspect compromise, follow CISA's steps as reported by BleepingComputer: back up the configuration, factory reset, upgrade, and restore. Then reset all passwords, revoke and reissue certificates, and reset API keys and license credentials.
  • Find the LDAP and AD service accounts the appliance uses. Rotate their passwords and check whether they can read LAPS or BitLocker recovery attributes. Remove any read rights the VPN doesn't need.
  • If an appliance was exposed, rotate LAPS passwords and BitLocker recovery keys for the devices in scope, and review AD logs for password spraying from appliance or VPN address ranges.

References

Original source: Volexity