CRITICAL: Ivanti Connect Secure Zero-Days Chained for Root Access

If you were hoping Ivanti Connect Secure would make it through 2026 without another zero-day chain, I have some bad news and a long weekend of patching for you. Volexity disclosed on October 13 that an unknown attacker chained three previously unknown flaws in Ivanti's flagship VPN appliance to execute commands as root without ever logging in. Ivanti has fixed two of the three bugs under CVE-2026-104935. The third, a privilege escalation that turns a foothold into full control of the box, is still waiting on a patch that Ivanti says will arrive "in a future release in the coming weeks."

Read that again, because it matters. The victim appliance was fully patched when it was compromised. It was running 22.8R2.4, the newest build available at the time, and it still fell over. CISA added CVE-2026-104935 to its Known Exploited Vulnerabilities catalog the same day the advisory dropped and gave federal civilian agencies until October 16 to act. That is a three-day window, which is CISA's polite way of saying drop everything.

What Volexity Found

Volexity tracks the attacker as UTA0576 and says exploitation of its customer's appliance began on October 3, 2026. The firm started investigating suspicious activity two days later and spent the following week reconstructing the chain from memory images and crash dumps, because the device itself was doing a very good impression of being clean.

The first link in the chain is an authentication bypass. The attacker sends a request to a public, unauthenticated login script on the appliance, specifically /dana-na/auth/url_default/welcome.cgi, and includes an X-DSCGI-PATH header that points at a protected script. The appliance validates the URL path, decides everything looks fine, and then routes the request using the header instead. That mismatch is exactly the kind of bug that makes you wonder how many other appliances check one thing and act on another.

The second link is a remote code execution bug in a file upload handler. The handler writes the uploaded file to disk before it checks whether the file is actually a valid ZIP archive. In that brief window, the attacker races to execute a Perl script, which gets them code execution as the appliance's cgi-server user. Ivanti rolled these first two flaws together under a single identifier, CVE-2026-104935, and classifies it as CWE-290, authentication bypass by spoofing.

The third link is the one still sitting open. The attacker tampers with a shared in-memory configuration store and tricks a maintenance service that runs as root into executing attacker code. Once the job is done, the exploit restores the original configuration state. Volexity's summary of the end result is blunt. It is unauthenticated root-level code execution.

The CVSS Score Undersells This

Ivanti's own CVSS 3.1 rating for CVE-2026-104935 is 8.6, with a vector of AV:N/AC:L/PR:N/UI:N and high confidentiality impact but only low integrity and availability impact. On paper that is "high," not "critical." In practice, the score only describes the two patched bugs on their own. It does not account for the unpatched privilege escalation that the same attacker is already pairing with it in the wild. CISA's own enrichment of the CVE record marks exploitation as active, the flaw as automatable, and the technical impact as total. When CISA and the vendor disagree that much, side with the folks who also set a 72-hour deadline.

There is also the small matter of where this appliance lives. Connect Secure sits on the edge of the network, talks to Active Directory, and holds service account credentials so it can authenticate your users. An attacker with root on that box is not just on your perimeter. They are wearing your perimeter as a costume.

Stealth Was the Whole Point

What makes UTA0576 interesting, and frankly a bit unnerving, is how little it left behind. There was no web shell and no persistent backdoor. Instead, the attacker reran the entire exploit chain for every single command and read the output straight out of the HTTPS response. The exploit modified library code only in memory, put the altered configuration data back the way it found it, and scrubbed matching entries from both the Ivanti debug logs and the Linux audit logs.

The practical consequence is that Ivanti's Integrity Checker Tool, which most of us have been told to run after every Connect Secure scare since early 2024, does not catch this chain. Volexity says outright that the tool "does not detect any modifications." If your incident response plan for edge appliance compromise begins and ends with running the ICT, this is your sign to write a better plan.

Once inside, the attacker went after identity. Using the appliance's own Active Directory service account, it queried for LAPS local administrator passwords and BitLocker recovery keys. It ran a custom Kerberos tool, sprayed passwords against domain accounts, and launched a renamed packet capture utility from a hidden folder at /data/.icscap/ to sniff plaintext LDAP, HTTP, FTP and telnet traffic for credentials and NTLM hashes. Volexity assessed with high confidence that the actor was staging for lateral movement when it was detected and disrupted. The firm also assessed, with medium confidence, that the attacker leaned on large language models to build its exploits and tooling, based on the volume of single-use scripts and the complexity of the chain. Its read on motive, at low confidence, is criminal rather than espionage.

Who Is Affected

According to the CVE record Ivanti published, Connect Secure versions before 25.1.3.0 are vulnerable, with 22.8R2.5, 25.1.3.0 and 25.1.3.1 listed as unaffected. Versions 22.7R2.14 and earlier are not impacted at all, which suggests the vulnerable code arrived with the 22.8 branch. The 25.1.3.0 release notes date to July 2026, so shops that had already moved to the 25.x line may be in better shape than those sitting on 22.8. Ivanti's advisory and the CVE record have not explicitly addressed Policy Secure or ZTA gateways, so check Ivanti's portal directly if you run those.

Ivanti describes the situation as "limited exploitation in the wild," and Volexity has confirmed one victim. Nobody has said how many other appliances were hit. Given that the attack was nearly invisible to the vendor's own integrity tooling, I would not take "limited" as a promise.

What to Do Right Now

Start by upgrading every Connect Secure appliance on the 22.8 branch to 22.8R2.5, or move to 25.1.3.0 or later, and do it today rather than at the next maintenance window. Ivanti has told customers on affected versions to "act immediately," and that is one of the rare vendor phrases I take literally. Patching closes the authentication bypass and the RCE, which means the unpatched privilege escalation no longer has a front door. Keep an eye out for the follow-up release that fixes the third bug and apply it the moment it lands.

Patching does not undo a compromise that already happened, so the next step is hunting. Pull your web logs and look for bursts of requests to /dana-na/auth/url_default/welcome.cgi, particularly requests carrying an X-DSCGI-PATH header whose value does not match the requested URL path. Check the appliance for the existence of /data/.icscap/ and for unexpected scripts or JSON files in temporary directories. Search your firewall and proxy logs for connections involving 108.165.147[.]64, the attacker host Volexity identified. Because the chain lives in memory and cleans up after itself, Volexity says confirming a compromise really requires network and memory forensics. CISA flagged this KEV entry for forensic triage, which tells you how seriously it takes that point.

If anything looks off, or if you simply cannot rule it out, assume the appliance's credentials are burned. Rotate the Active Directory service account Connect Secure uses, rotate LAPS passwords across the estate, and reissue BitLocker recovery keys. Review domain controller logs for unusual Kerberos ticket requests and password spraying patterns sourced from the appliance's address, and look hard at any account that authenticated through the VPN between October 3 and the day you patched.

Longer term, this is another nudge to treat VPN appliances as untrusted hosts that happen to sit in a privileged position. Give the appliance's directory account the least privilege it can live with, make sure it cannot read LAPS or BitLocker attributes, and stop letting cleartext LDAP and legacy protocols cross the segment it sits on. An appliance that cannot sniff anything useful is a much less exciting place for an attacker to spend a week.

The Bigger Picture

This is far from the first time Connect Secure has been on the wrong end of a chained zero-day, and it will not be the last. What stands out here is not the bug class. Header confusion and upload race conditions are old tricks. What stands out is the discipline of the operator, the refusal to leave persistence behind, and the very real possibility that a model helped stitch the chain together faster than defenders could find it. If that assessment holds, the time between a new appliance release and a working exploit chain is going to keep shrinking, and "fully patched" will mean less every quarter.

Ivanti also disclosed two unrelated critical flaws this week, CVE-2026-106042 in Xtraction and CVE-2026-109412 in Neurons Patch for Intune, both rated 9.9 and neither known to be exploited yet. Patch those too, but do Connect Secure first.

MSP Angle

Every client running Connect Secure needs a same-day patch call and a compromise assessment, and that is a billable incident response engagement rather than a routine ticket. It is also a natural moment to pitch identity threat detection and a managed migration away from legacy VPN appliances toward a zero trust access model.