Ivanti Connect Secure Zero-Day Can Evade Integrity Checks: What Admins Should Do

Ivanti has released emergency updates for an actively exploited Connect Secure vulnerability that attackers used to breach a fully patched VPN appliance, steal credentials and prepare to move deeper into a victim’s network.

The flaw, CVE-2026-104935, lets an unauthenticated attacker reach protected code and briefly write an executable file to the appliance. In attacks investigated by Volexity, a separate, still-unpatched privilege-escalation flaw then turned that access into root-level command execution. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on October 13 and set an October 16 remediation deadline for federal civilian agencies.

This is not a patch-and-close-the-ticket incident. The observed operator removed log entries, restored altered in-memory state and did not leave a web shell behind. Volexity found that those techniques could leave Ivanti’s Integrity Checker Tool with nothing persistent to flag. Organizations that exposed a vulnerable appliance should patch immediately, but they also need to treat the device as a possible entry point for credential theft.

Ivanti patched two links in a three-stage chain

Volexity’s investigation began after it traced suspicious activity to an Ivanti Connect Secure appliance running 22.8R2.4, then the latest build for that branch. The firm found exploitation starting October 3 by a previously unknown actor it tracks as UTA0576.

The chain crossed three boundaries:

1. Authentication bypass: A request to the public /dana-na/auth/url_default/welcome.cgi endpoint supplied an X-DSCGI-PATH header pointing at the protected wu.cgi handler. The appliance checked access against the public URL but routed the request according to the header.
2. Remote code execution: The attacker uploaded a Perl script disguised with a .zip extension. The handler wrote the file before verifying that it was a valid archive. Parallel requests raced the validation and deletion step, executing the file during that short window.
3. Privilege escalation: Code running as the lower-privileged cgi-server user patched an Ivanti library in process memory, changed a trusted maintenance task in the DSCache configuration store and asked the root-level dsinvoked service to run the attacker’s Perl code.

Ivanti tracks the first two components under CVE-2026-104935 and fixed them in the October 13 updates. The company is still developing a fix for the separate privilege-escalation bug, according to Volexity. Closing the unauthenticated entry point blocks the observed chain, but administrators should still install the later privilege-escalation update when it becomes available.

Why a clean Integrity Checker result is not enough

UTA0576 avoided the usual persistent foothold. It re-ran the exploit chain for each command and sent the output back in the corresponding HTTPS response instead of installing a backdoor or maintaining a separate command-and-control channel.

The root stage restored the modified DSCache entry and the patched library byte after use. It also filtered recent records from /home/runtime/dlogs/debuglog and /var/log/audit/audit.log, deleted temporary scripts and results, and redirected cleanup-process output to /dev/null. Because the important library change happened in memory and was reversed, Ivanti’s disk-oriented Integrity Checker could miss the compromise.

CISA’s response guidance therefore calls for network and memory forensics when organizations need to determine whether an appliance was breached. A successful update or clean integrity scan establishes neither that earlier exploitation failed nor that credentials reachable through the VPN remain trustworthy.

The attackers went after Active Directory secrets

The observed activity quickly moved beyond the appliance. Volexity found the operator extracting domain credentials used for LDAP, collecting limited Active Directory metadata and inspecting authentication logs for valid usernames.

Custom scripts queried the directory for Windows Local Administrator Password Solution credentials, BitLocker recovery keys and password-bearing attributes such as userPassword and unixUserPassword. The operator also deployed Kerberos tooling with credential-testing and Kerberoasting capabilities, ran password-spraying attempts, and searched internal DNS data.

A renamed packet-capture utility watched traffic for plaintext protocols including LDAP, HTTP, FTP and Telnet. Volexity found attempts to recover credentials, HTTP Basic Authentication data and NTLM challenge-response material from traffic already passing through the VPN appliance. This placement makes a compromised gateway more than a single-device problem: it can expose secrets used to authenticate the gateway to the rest of the network.

Which Connect Secure versions need updates

Rapid7 summarized Ivanti’s fixed builds as follows:

Ivanti says 22.7R2.14 and earlier are not affected by this CVE. That should not be read as a reason to move backward: CISA notes that the 22.8 branch reaches end of life on January 31, 2027, so teams remaining on older releases should check support status and plan a supported migration.

Internet scanning accelerated after disclosure. Previdian’s sensors were still recording attempts on October 15, and researchers observed probes using the same X-DSCGI-PATH mechanism described in the original investigation. Public scanning activity does not prove every source successfully compromised a device, but it narrows the time available for administrators to respond.

What administrators should do now

1. Inventory every appliance and verify the exact build. Include hardware, virtual and cloud instances, along with standby nodes. Do not infer patch state from a management console that has not refreshed.
2. Apply the fixed release immediately. Follow Ivanti’s upgrade and migration compatibility guidance, then confirm every cluster member actually booted the intended version.
3. Preserve evidence before destructive recovery. Capture relevant network telemetry and, where possible, memory and disk evidence. A rushed factory reset can remove the volatile artifacts needed to determine what the attacker accessed.
4. Hunt for mismatched request routing. Review upstream proxy, load balancer and network logs for repeated requests to /dana-na/auth/url_default/welcome.cgi paired with an X-DSCGI-PATH header targeting wu.cgi, /home/runtime/tmp/ or another unexpected path.
5. Check for lateral movement from the gateway. Investigate LDAP queries, password spraying, unusual Kerberos activity, DNS reconnaissance and outbound connections originating from the appliance. Review domain-controller logs for use of the VPN’s service account.
6. Rotate what the appliance could expose. If compromise is suspected, CISA recommends resetting domain, administrator and local account passwords, revoking and reissuing stored certificates, and replacing stored API keys and license-server credentials. Prioritize the LDAP bind account and any secrets accessible through Active Directory attributes.
7. Rebuild compromised systems. CISA advises backing up the configuration, factory-resetting and upgrading physical appliances, or rebuilding cloud and virtual instances, before restoring a reviewed configuration.
8. Track the remaining fix. The October update blocks the documented unauthenticated route, but the privilege-escalation component still needs a later Ivanti patch. Add that release to the change queue now rather than treating this week’s update as the end of the incident.

Detection has to extend beyond the appliance

The strongest evidence may sit outside Connect Secure. Logs from reverse proxies, firewalls, domain controllers, identity systems, DNS and endpoint tools can retain the request patterns and follow-on behavior that the appliance’s altered logs no longer show.

That makes the practical response sequence straightforward: patch to stop new entry, preserve volatile evidence, investigate the VPN’s interactions with internal identity systems, and rotate secrets according to what the appliance could reach. For this attack, a green integrity check is one data point, not an all-clear.