Ivanti Connect Secure Zero-Day CVE-2026-104935: Attackers Went Straight for AD Secrets
Security

Ivanti Connect Secure Zero-Day CVE-2026-104935: Attackers Went Straight for AD Secrets

An unauthenticated Ivanti Connect Secure chain was exploited from 3 October. CISA's deadline is 16 October, and the attackers used the appliance's LDAP account to pull LAPS and BitLocker secrets.

AB
Anthony Bahn IT Director & Cybersecurity Consultant
ivantivpn appliancezero-dayactive directorycisa kev

What happened

Ivanti published fixes on 13 October 2026 for CVE-2026-104935, an authentication bypass by spoofing in Ivanti Connect Secure that lets a remote attacker with no credentials run commands on the appliance. CISA added it to the Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until 16 October to act. That deadline is tomorrow.

The exploitation was found by Volexity. It started looking into suspicious activity at a network security monitoring customer on 5 October, and traced the first exploitation back to 3 October. That means attackers had a ten-day head start on every defender who learned about this from the advisory. Volexity tracks the actor as UTA0576. It is a previously unknown cluster, and Volexity assesses with low confidence that the motive is criminal rather than espionage.

What matters most for defenders is what came after the appliance fell. The attackers did not stop at the VPN box. They used the credentials it held to query Active Directory for LAPS local administrator passwords and BitLocker recovery information. A patch closes the door, but it does not take back the secrets.

Who is affected

Ivanti's advisory, as relayed in watchTowr's FAQ, lists the following affected and fixed builds:

  • ISA6000 and ISA8000 appliances: 25.1.1.1 and prior are affected; fixed in 25.1.1.2.
  • ISA4500, ISA6500 and ISA8500 appliances: 25.1.2.2 and prior are affected; fixed in 25.1.3.0 and 25.1.3.1.
  • The 22.8.X branch: 22.8R2.4 and prior are affected; fixed in 22.8R2.5.

Ivanti says 22.7.X and earlier, including 22.7R2.14, are not affected. The 22.8 line is described as a temporary bridge to 25.1, and the guidance is to move directly to 25.1.1.2 or later rather than stopping at 22.8R2.5. Ivanti also says its own product security program found part of the flaw and fixed that portion in the July 25.1.3.0 release before backporting it. That July build is a fixed version only for ISA4500, ISA6500 and ISA8500 appliances. ISA6000 and ISA8000 appliances need 25.1.1.2, and the 22.8 branch needs 22.8R2.5, so check the platform and build together rather than assuming a July update covered you.

One gap remains. Volexity describes a third, unnumbered privilege-escalation flaw that lets code on the appliance run as root. Ivanti has promised that fix in a future release in the coming weeks. watchTowr's FAQ does not mention it, and the CVE record covers only the bypass and remote code execution parts. Treat a patched appliance as still carrying a known local escalation path until Ivanti ships the follow-up.

No CVSS score had been published on the CVE record at the time of writing.

Technical analysis

Volexity describes a chain of three weaknesses. The first is an authentication bypass in the CGI request routing that lets an unauthenticated request reach CGI handlers that should require a login. The second is a race condition in a file-write path that turns that access into code execution. The third is the unpatched escalation, which abuses how a privileged broker process trusts cached configuration data.

The chain also defeats the tool most Ivanti customers run first. It patches the in-memory copy of a shared library and restores the cached configuration afterwards, so nothing on disk changes. Ivanti's Integrity Checker Tool reported nothing on the compromised appliance Volexity examined. Ivanti itself says no reliable indicators of compromise are available yet. We cover why that is a structural problem, not a one-off miss, in Why a Clean Integrity Check Cannot Clear a Compromised Appliance.

Once on the box, UTA0576 went after identity:

  • It extracted credentials stored on the appliance, including the domain account used for LDAP authentication.
  • It ran a custom Python LDAP tool under that service account to search for LAPS local administrator passwords, BitLocker recovery information, the userPassword and unixUserPassword attributes, logon script paths and account metadata. Results were compressed, encoded and staged in /tmp/ before being sent out.
  • It deployed a custom Kerberos tool with Kerberoasting capability, ran password spraying and tested credentials.
  • It ran a renamed tcpdump binary as a sniffer for LDAP and other plaintext protocols and harvested credentials, including NTLM challenge-response material.
  • It read the appliance's authentication logs to build a list of valid usernames, then tampered with logs.

Why that service account can see so much depends on how it was delegated. We break that down in What an Appliance's LDAP Service Account Can Read in Active Directory.

Immediate actions

  1. Inventory and patch. Identify every Connect Secure appliance, its hardware platform and its build, and move it to the fixed version for that platform. Prefer 25.1.1.2 or later over the 22.8R2.5 bridge release. Ivanti lists no workaround.
  2. Preserve before you patch. Ivanti's guidance is to keep logs, configuration backups and system images before making changes. Because this chain lives in memory, a reboot or upgrade can destroy the most useful evidence. Our earlier guide, How to Preserve Forensic Evidence on a Network Appliance Before You Patch It, covers the order of operations.
  3. Hunt the request pattern. Volexity points to repeated requests to /dana-na/auth/url_default/welcome.cgi that carry an X-DSCGI-PATH header pointing at a protected CGI or a temporary file. Alert on any mismatch between the requested URL path and that header value.
  4. Look for on-box artifacts. Volexity lists JSON output, Python helper scripts and spray results under /tmp/, a hidden .icscap directory with capture files under /data/.icscap/, and a tcpdump copy renamed dsstatmond. Log tampering was seen in /home/runtime/dlogs/debuglog and /var/log/audit/audit.log, so a quiet log is not proof of a clean box.
  5. Assume the directory secrets are gone. If an appliance was reachable from the internet between 3 and 13 October, rotate its LDAP and service-account credentials, rotate LAPS passwords and BitLocker recovery keys in scope of that account, and reset accounts that may have been sprayed or Kerberoasted. The sequence is laid out in How to Contain Active Directory Exposure After a VPN Appliance Is Compromised.
  6. Review AD from the other side. Look for LDAP queries and Kerberos service-ticket requests sourced from the appliance's service account, and for unusual outbound or lateral traffic from the appliance itself.

Long-term outlook

watchTowr's FAQ lists five earlier Connect Secure flaws already in the KEV catalog, going back to the January 2024 chain. Edge VPN appliances keep failing in the same way. They are internet-facing, hold directory credentials, and run a closed operating system that defenders cannot easily instrument. This campaign adds a lesson that should change how these boxes are provisioned. The appliance's LDAP bind account had enough read access to reach recovery keys and local admin passwords. An authentication proxy needs to validate users. It does not need to read secrets.

The pending privilege-escalation fix also means this story is not finished. Track Ivanti's next release, and remember that patching the gateway does not evict anyone already inside. We made that case for GlobalProtect earlier this week in Why Patching Your VPN Gateway Does Not Evict the Attacker Already Inside, and it applies here with more force, because this time the attacker left with the keys to the endpoints too.

Sources

← Back to all news