DNS Security

Ivanti VPN Zero-Day Chain Gives Root Access

By Nattapong Sukkasem · Published 2026-10-15 · Updated 2026-10-21.

TL;DR — Ivanti patched CVE-2026-104935 on 13 October 2026 after Volexity found it chained with a third, still-unpatched flaw to give root on fully patched Connect Secure appliances. Exploitation runs from at least 3 October. The operator, tracked as UTA0576, planted no web shell and no malware — it re-ran the entire chain for every single command, then edited the logs behind itself. CISA added the CVE to its Known Exploited Vulnerabilities catalog the same day, with a 16 October federal deadline. Shadowserver counts more than 5,500 exposed instances.

A VPN concentrator is not where most teams file their DNS security work, but Ivanti Connect Secure resolves names for every client inside the tunnel. On 13 October 2026 Ivanti confirmed attackers had been running commands as root on fully patched appliances since at least 3 October. CVE-2026-104935, rated CVSS 8.6, is only part of the story: Volexity documented three flaws chained together, one of which had no patch at disclosure, and an operator who deliberately left nothing on disk to find.

What Ivanti shipped, and what it did not

Item	Detail
Advisory	Ivanti security advisory, 13 October 2026; Volexity analysis published the same day
Primary CVE	`CVE-2026-104935` — authentication bypass by spoofing (CWE-290), CVSS 8.6, remote and unauthenticated
Second stage	Remote code execution via an upload race condition in `wu.cgi` — covered by the same CVE
Third stage	Privilege escalation through the privileged `dsinvoked` service — no CVE, unpatched at disclosure
Affected	22.8R2.4 and earlier, 25.1.1.1 and earlier, 25.1.2.2 and earlier; the 22.7 branch and lower are not affected
Fixed builds	22.8R2.5, 25.1.1.2, 25.1.3.1 — plus 25.1.3.0, which carried a partial fix in July 2026
Exploited since	At least 3 October 2026 (Volexity); earliest signals reported from 1 October
Actor	UTA0576 — previously undocumented; criminal motivation assessed with low confidence
CISA KEV	Added 13 October 2026; federal remediation deadline 16 October 2026
Exposure	More than 5,500 internet-facing Connect Secure instances tracked by Shadowserver
Indicators	One published address, `108.165.147[.]64`. No malware, no web shell, no C2 domain
End of life	The 22.7 and 22.8 branches reach end of life on 31 January 2027

Ivanti chief product officer Srinivas Mukkamala, second from left, on a cybersecurity panel at Collision 2024, the vendor whose Connect Secure VPN zero-day vulnerability drives this DNS security report — Ivanti chief product officer Srinivas Mukkamala, second from left, on a security panel at the Collision conference in Toronto, June 2024. Connect Secure is the third consecutive year in which Ivanti has faced an undisclosed VPN flaw exploited before a patch existed. Photograph by Collision Conf, via Wikimedia Commons, licensed CC BY 2.0.

How the chain reaches root

The first flaw is routing confusion. A request to the public endpoint /dana-na/auth/url_default/welcome.cgi carries an X-DSCGI-PATH header. The access check reads the public URL and waves the request through; the header then decides which CGI script runs. That gap reaches protected functionality, specifically wu.cgi.

The second turns that reach into execution. wu.cgi writes an uploaded file — a Perl script disguised as a .zip — into /home/runtime/tmp/ before validating the contents. Validation fails and the file is deleted, but parallel requests referencing that path through the same header win the race and run the payload first. The result is execution as the unprivileged cgi-server account.

The third has no patch. The operator abuses the privileged dsinvoked service and the DSCache configuration store, modifying an Ivanti library in memory and altering a privileged maintenance task so dsinvoked executes attacker-supplied Perl as root. Ivanti says a fix follows in the coming weeks. Until then, patched appliances close two doors of three.

Then the chain tidies up. It restores the modified in-memory state, strips its own entries from Ivanti debug logs and from the Linux audit log, and — Volexity found — can evade Ivanti's own Integrity Checker Tool. Ivanti says a portion of the flaw was identified internally and addressed in the July 2026 25.1.3.0 release; the backport to other branches was still in flight when the attacks began.

Why a VPN flaw is a DNS security problem

Post-exploitation is what makes this more than an appliance zero-day vulnerability. Volexity watched UTA0576 harvest domain credentials stored on the appliance, pull Active Directory metadata, run a custom tool searching AD for LAPS passwords and BitLocker recovery keys, spray credentials with bespoke Kerberos tooling, capture LDAP traffic and parse authentication logs for valid usernames.

None of that is possible without name resolution. Finding a domain controller from a foothold is an SRV lookup — _ldap._tcp.dc._msdcs.<domain>, then _kerberos._tcp.<domain> — and Kerberos itself fails unless forward and reverse names agree. So in an intrusion with no implant, no web shell and no command-and-control domain, the resolver sitting behind the VPN is one of the very few places the reconnaissance is written down. Volexity's own guidance says as much: look for unusual VPN-originated traffic toward AD, LDAP, DNS and authentication systems.

That inverts the usual DNS security instinct. Protective DNS normally points at clients to catch beacons leaving the estate; here the signal is internal and the source is the appliance itself. If your Connect Secure box forwards to a resolver nobody logs, the single richest evidence trail in this campaign does not exist on your network.

Ivanti's corporate wordmark. Connect Secure terminates remote sessions and resolves names for everything inside the tunnel, which places a VPN appliance squarely inside the server infrastructure that enterprise IT security teams audit last. Official wordmark via Wikimedia Commons, licensed CC BY-SA 4.0.

The operator, and the machine-assistance question

UTA0576 was unknown to Volexity before this campaign. The researchers assess with low confidence that the motivation is criminal rather than espionage, and with medium confidence that the operator used large language models for exploit development and post-exploitation — citing repeated use of the exploit channel to push one command at a time, and highly specific scripts carrying hardcoded credentials. Both assessments are hedged, and worth repeating at that strength.

The pattern around Ivanti is firmer. This is the third year running that Connect Secure has carried an exploited flaw before disclosure, after the January 2024 and January 2025 incidents. CISA has flagged 36 Ivanti vulnerabilities as exploited since November 2021, a dozen of them abused by ransomware crews.

Official seal of the Cybersecurity and Infrastructure Security Agency, which added CVE-2026-104935 to its Known Exploited Vulnerabilities catalog with a 16 October federal remediation deadline — CISA added `CVE-2026-104935` to the Known Exploited Vulnerabilities catalog on 13 October 2026, giving federal civilian agencies until 16 October to remediate — three days, which is the agency's signal that it expects wider exploitation. Official seal, public domain, via Wikimedia Commons.

What to do before the deadline

Patch, but read the hardware note first. 22.8R2.5, 25.1.1.2 and 25.1.3.1 are the fixed builds. The 25.1.3.x branch requires ISA4500, ISA6500 or ISA8500 hardware — physical deployments need new appliances, virtual ones a rebuild from the current template. That is procurement, not a maintenance window, so 22.8R2.5 is the realistic interim step.
Treat every stored credential as burned. Domain service accounts configured on the appliance, anything that authenticated through it, and the LAPS and BitLocker material the actor was hunting. Rotate rather than audit.
Hunt the HTTP shape, not a hash. Volume to /dana-na/auth/url_default/welcome.cgi; any mismatch between the requested URL and the X-DSCGI-PATH value, especially one naming wu.cgi or a file under /home/runtime/tmp/; unexplained scripts in /tmp/; activity in /data/.icscap/.
Do not accept a clean Integrity Checker result as proof. The chain was observed evading it, and the logs it reads were edited. A clean ICT run is the absence of evidence, not evidence of absence.
Pull resolver telemetry from behind the tunnel. SRV queries for _ldap._tcp and _kerberos._tcp sourced from the appliance, or reverse lookups sweeping internal ranges, are the fingerprint of the reconnaissance above. Query logging is the cheapest DNS security control here; reconstructing the week afterwards is not.
Re-baseline what you expose. Confirm the public address and published names of every remote-access appliance you own with a public IP address check, and verify the records behind them with a DNS record lookup. Shadowserver finds 5,500 of these online; a fair number belong to people who think they decommissioned them.

DNS Benchmark Pro results ranking public resolvers by DNS server performance, used to baseline resolution before and after emergency VPN appliance patching — Resolver rankings by **DNS server performance**. An emergency appliance rebuild changes which resolver the tunnel hands to clients — measure before the change, so the complaint afterwards is a number and not an argument. Original capture of the DNS Benchmark Pro engine.

Network latency comparison across public DNS resolvers, a standard network diagnostic tool check for IT security and cloud security teams validating resolver behaviour after a VPN outage — Per-resolver **network latency** distribution. Used as a **network diagnostic tool**, it separates a genuinely slow resolver from a saturated tunnel — the distinction a help desk cannot make from ticket text alone.

Industry impact

The edge-appliance pattern is tediously consistent. Citrix in late September, Fortinet and Cisco in early October, Ivanti now: the device terminating every remote session has the smallest maintenance team, the longest change-approval queue and the least telemetry. It is one appliance, so nobody treats it as server infrastructure; it is on the perimeter, so everybody depends on it.

The deliberate absence of an implant is the part worth internalising. Re-running the full chain per command is slow and leaves more noise in HTTP logs than a web shell would — UTA0576 took that trade anyway, because it defeats every control looking for a file. For IT security teams whose detection strategy is a list of artefacts, this campaign returns nothing. The same blind spot carries into cloud security, where an appliance image rebuilt from an unpatched template quietly reinstates the flaw the change ticket just closed.

One practical caution. When a VPN concentrator is rooted, misbehaving or mid-rebuild, what reaches the service desk is slow logins and patchy name resolution — symptoms reading like congestion or a DDoS attack long before anyone suspects an intrusion. Worth remembering before an incident is filed as a capacity problem.

The last point is the one this site keeps returning to. Encrypted transports help users and hinder defenders in equal measure: if your estate sends DNS over HTTPS to a resolver outside your control, the queries that would have exposed this reconnaissance never cross a device you own. Good DNS security is not a choice between encryption and visibility — it is pointing the encrypted path at a resolver you actually log.

Sources

DNS angle

Review resolver logs for the systems discussed above and compare unexpected names with your approved services. A successful lookup does not establish that a destination is safe. Use the DNS lookup tool to inspect current answers, then compare them with your own resolver and incident records.

Source: BleepingComputer — Ivanti warns of Connect Secure zero-day exploited in attacks (2026-10-13).