On October 13 Ivanti shipped a fix for CVE-2026-104935, an authentication bypass in Connect Secure that lets anyone on the internet run commands on the appliance. The same day, Volexity published what it found on a customer's VPN: an attacker had chained that bug with two others to get root on a box running 22.8R2.4, which was the newest build available at the time. Patched, current, and owned since October 3.
Two of the three bugs are now fixed. The third, a privilege escalation, is not. Ivanti says a fix is coming "in the coming weeks." And Ivanti's own Integrity Checker Tool, the thing it tells customers to run after every scare, reports a clean bill of health on a compromised appliance.
How the chain works
The entry point is a header. A request to the public welcome.cgi page carries an X-DSCGI-PATH header pointing at a protected script, wu.cgi. The web server checks access rights against the URL, then routes the request wherever the header says. That mismatch is the whole authentication bypass. CVSS 8.6, no credentials, no user interaction.
The second bug is in wu.cgi itself. It writes an uploaded file to disk, named by the MD5 of the client's filename, and only afterward checks whether the file is a valid ZIP. Invalid files get deleted, but there's a window between write and delete. The attacker fires parallel requests into that window and executes the file before cleanup runs. The payload is a Perl script that launches Bash, which launches Python code delivered as Base64, decompressed with zlib and run through exec(). Nothing touches disk for long.
Stage three gets root. The exploit patches the copy of libdsplibs.so that the cgi-server process has loaded in memory, rewrites a DSCache maintenance task so it launches Perl, and asks dsinvoked, a broker that runs as root, to execute the task. It confirms success by reading /etc/shadow. Then it puts the DSCache entry and the library back the way it found them.
There is no web shell. No implant. Every command the attacker wants to run goes through all three stages again, and results come back in the HTTP response. When they're done, they trim the recent entries from the debug log and the audit log and delete their temp files.
That design is why the Integrity Checker Tool misses it. The tool compares files on disk against the hashes it expects. This attack modifies a library in memory and restores a configuration entry before anyone looks. CISA's alert says it plainly: the tool "may not detect evidence of exploitation" because the commands execute in memory. If you want to know whether your appliance was hit, you need network captures or a memory image. Volexity only reconstructed the chain by pulling core dumps and memory images with Ivanti's help, because the attacker had already wiped the logs.
What the attacker did once inside
Volexity tracks the group as UTA0576 and had not seen them before. Their interest was the Windows domain behind the VPN, not the VPN itself.
They pulled the stored LDAP service account credentials out of the appliance configuration. They dropped a renamed copy of tcpdump into a hidden directory, called it dsstatmond, and sniffed plaintext ports for LDAP and HTTP Basic credentials and NTLM hashes, rotating through eight capture files. They scraped usernames from authentication logs and ran a password spray. With the compromised service account they queried Active Directory for LAPS local administrator passwords, BitLocker recovery keys, the userPassword and unixUserPassword attributes, and logon script paths. They brought a custom Kerberoasting tool.
Volexity assesses with high confidence that this was staging for lateral movement. The operation was caught and cut off before the final objective became clear. Volexity also notes, with medium confidence, that the exploit and the scripts run after it show signs of having been written with a large language model, citing repeated use of the exploit channel to run commands and scripts with hardcoded credentials baked in. Make of that what you want. The tooling worked.
Ivanti knew about part of this in July
Ivanti told The Register that its product security program had identified "a portion of this vulnerability" and fixed it in the July release, 25.1.3.0. The company was still backporting that fix to the other supported branches when exploitation started on October 1.
So for roughly three months, one code line had the fix and two did not. Customers on 22.8R2.4 were running the latest build for their branch and had no way to know that branch was behind. The advisory that would have told them did not exist until October 13. Ivanti did not say which portion of the chain the July fix covered, or why a security fix took more than a quarter to reach the other branches.
The fixed versions are 25.1.1.2, 25.1.3.0 or 25.1.3.1, and 22.8R2.5. Anything on 22.7.x or earlier is not affected, which is a small mercy for the people who never upgraded. The 22.8 branch reaches end of life on January 31, 2027, so if you're on it, this is the moment to plan the move rather than patch in place and forget.
CISA added the CVE to its Known Exploited Vulnerabilities catalog on October 13 and gave federal agencies until October 16 to patch and complete forensic triage. Shadowserver counts more than 5,600 Connect Secure hosts exposed to the internet, per BleepingComputer. Ivanti's statement says exploitation affected "a limited number of customers." Ivanti said something similar in January 2024, and thousands of appliances ended up compromised that month.
What I'd do this week
Patching closes the front door. It does not evict anyone who already walked through it, and it does not fix the privilege escalation. So the patch is step one of several.
- Upgrade to the fixed build for your branch today. Ivanti has an upgrade compatibility guide for hardware and virtual appliances; read it first, because the 22.x to 25.x jump is not a point release.
- Search your web logs for requests to /dana-na/auth/url_default/welcome.cgi where the X-DSCGI-PATH header does not match the URL, especially values ending in wu.cgi or pointing into /home/runtime/tmp/. Volexity's indicators are on GitHub.
- Look for a hidden .icscap directory under /data and a process named dsstatmond. Either one means you've been sniffed.
- If you find anything, follow CISA's recovery steps in full: back up the config, factory reset or rebuild the virtual appliance, upgrade, restore, then reset every password the appliance held. That includes the LDAP bind account, local admins, API keys and license credentials. Revoke and reissue the certificates stored on the box.
Step four is the expensive one, and it's the one people skip. The LDAP service account on a Connect Secure appliance usually has read access to the whole directory. That's what UTA0576 used to go shopping for LAPS passwords. If your appliance was reachable from the internet between October 1 and your patch date, treat that account as burned whether or not you found the sniffer.
This is the third year in a row with Connect Secure zero-days under active exploitation: January 2024, January 2025, and now October 2026. The appliance keeps getting owned through the same class of bug, CGI handlers that trust what the client tells them. I've run VPN concentrators from several vendors over the years, and the pattern that holds is that an edge device with a Perl CGI web stack and a domain service account is the most valuable box on the network to an attacker and the least watched by its owner. Ivanti will ship the privilege escalation fix in a few weeks. Somebody else will find the fourth bug in the same handler before next October.
