Your VPN gateway is supposed to be the fortress door — the one control that keeps attackers out of your network. But what if an adversary can not only pick the lock without credentials, but also quietly erase every footprint from the audit trail after walking in? That is exactly what happened when a previously unknown threat actor, tracked by Volexity as UTA0576, chained three zero-day vulnerabilities in Ivanti Connect Secure to gain unauthenticated root-level access to fully patched VPN appliances — and left investigators wondering whether the Integrity Checker tool could even catch them.

On 13 October 2026, Ivanti disclosed CVE-2026-104935 — an authentication bypass scored CVSS 8.6 — after Volexity caught UTA0576 exploiting it against a fully patched appliance running ICS 22.8R2.4. CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog the same day, setting a federal agency patch deadline of 16 October 2026. Seventeen days later, CISA returned to add two more CVEs from the same Ivanti chain on 30 October, confirming ongoing exploitation and elevating the urgency for every enterprise with an ICS deployment.

If your organisation is running Ivanti Connect Secure and has not yet moved to a fixed version, treat this as a fire-drill-now situation.


🔒 Key Takeaways

  • CVE-2026-104935 (CVSS 8.6) — authentication bypass by spoofing — is the anchor of a three-flaw zero-day chain in Ivanti Connect Secure VPN.
  • Threat actor UTA0576 exploited the chain on fully patched appliances from 1–3 October 2026, achieving unauthenticated root execution with no malware left on disk.
  • The attacker wiped both Ivanti debug logs and Linux audit logs; Ivanti’s own Integrity Checker may return clean on a compromised device.
  • CISA has added flaws from this chain to its KEV catalog on two separate dates (13 Oct and 30 Oct 2026).
  • Fixed builds: 22.8R2.5, 25.1.1.2, 25.1.3.0, 25.1.3.1. Affected: 22.8R2.4 and prior; 25.1.1.1 and prior; 25.1.2.2 and prior.
  • Volexity assessed UTA0576 likely used LLM-assisted tooling to craft the exploit chain — a signal that AI-augmented adversaries are accelerating zero-day weaponisation.

Why Ivanti Connect Secure Is a High-Value Target

Ivanti Connect Secure (formerly Pulse Connect Secure) is among the world’s most widely deployed SSL VPN platforms. It is common across financial services, healthcare, government, and critical infrastructure — exactly the sectors UTA0576 appears to be targeting. In India, mid-sized enterprises and large PSUs that have standardised on ICS as their remote-access backbone are directly in the crosshairs.

This is not Ivanti’s first rodeo with serious zero-days. Since 2024, the platform has seen a string of critical vulnerabilities exploited in the wild by nation-state actors, prompting repeated CISA emergency directives. Yet enterprise patch cadences remain slow. The CVE-2026-104935 chain was exploited against a fully patched device — meaning even organisations that were current found themselves vulnerable the moment the zero-day was weaponised. This is why zero-trust network architecture, which we covered in depth for campus deployments, becomes the backstop when perimeter VPN controls fail.

The Three-Zero-Day Chain: A Technical Breakdown

Volexity’s full write-up (titled “A Series of Unauthenticated Events”) walks through how UTA0576 assembled three vulnerabilities into a seamless remote-to-root exploit. Here is the chain as verified across Volexity’s disclosure and SecurityWeek’s analysis:

Stage Component Mechanism Outcome
1 welcome.cgi Abuses X-DSCGI-PATH header to route requests to authentication-protected CGI endpoints Authentication bypass — unauthenticated access to wu.cgi
2 wu.cgi Race condition in file-write path allows attacker to write arbitrary files to predictable disk locations Remote code execution (RCE) as a non-root user
3 dsinvoked broker / DSCache Privilege escalation: broker process trusts attacker-controlled DSCache data to execute commands Full root access on the appliance

What makes this chain especially dangerous is what happens next. UTA0576 did not drop a web shell or persistent implant — instead, the actor re-ran the entire exploit chain for each subsequent command, patching code in memory only and restoring original state afterward. The result: Ivanti’s own Integrity Checker Tool (ICT) returns a clean bill of health even on a compromised device. The attacker also deleted its entries from both the Ivanti debug log and the Linux system audit log (auditd), meaning standard log-review and SIEM alerting pipelines see nothing out of the ordinary.

Post-exploitation activity confirmed by Volexity includes credential harvesting (session tokens and stored credentials), network reconnaissance, and data exfiltration. The scope of confirmed victims is limited, but Ivanti acknowledged exploitation across a small number of customers.

One more chilling data point: Volexity assesses with medium confidence that UTA0576 used large-language-model (LLM) tooling to help build the exploit chain. This aligns with the growing trend of AI-augmented adversaries we have been tracking — the same threat vector highlighted in our coverage of China’s ARTEX campaign that used AI agents to breach Microsoft 365 tenants.

Scope and Exposure: Who Is at Risk?

Ivanti Connect Secure is deployed globally. If your organisation is running any of the following builds, you are in the vulnerable range:

  • 22.8R2.4 and all prior 22.x builds
  • 25.1.1.1 and prior
  • 25.1.2.2 and prior

The fixed builds are: 22.8R2.5, 25.1.1.2, 25.1.3.0, and 25.1.3.1. Note that as of the original disclosure, the privilege-escalation (Stage 3) flaw was still pending a patch from Ivanti, with a fix described as “coming in the following weeks.” Verify the current advisory status at Ivanti’s security portal before assuming all three stages are patched in your target build.

The CISA alert also recommends that patching alone is insufficient. After upgrading, organisations should assume compromise on any previously vulnerable appliance and undertake full credential rotation — including API keys, stored secrets, and VPN user passwords — and reissue any certificates that transited the appliance.

This is a pattern we saw play out with the Cisco ASA/FTD SSL VPN zero-day we covered earlier — where 51,000 perimeter devices were left at risk even after initial patches shipped, because organisations underestimated attacker dwell time.

What You Should Do Right Now: Sanjay Seth’s Expert Checklist

Having managed enterprise network perimeters for three decades, I have seen how VPN compromise cascades into full network breach — not because the vulnerability was impossible to patch, but because patch validation was inadequate. Here is the immediate action list:

  1. Identify every ICS instance in your environment. This includes cloud-hosted, branch office, and managed-service deployments. If you have outsourced VPN management to an MSSP, contact them today and demand a version report.
  2. Upgrade to a fixed build immediately. Target 25.1.3.1 or 22.8R2.5 depending on your current release track. Do not treat a partial upgrade as sufficient.
  3. Do not trust the Integrity Checker Tool alone. Volexity has confirmed the ICT can miss active exploitation. Run a memory-forensics sweep if you suspect compromise.
  4. Pull and review out-of-band logs. Because ICS and Linux audit logs may have been cleared, check upstream syslog servers, your SIEM, and perimeter firewall logs for unusual CGI request patterns — specifically requests to /dana-na/auth/welcome.cgi with non-standard headers.
  5. Rotate all credentials that could have transited the appliance. CISA’s guidance is explicit: reset all passwords and reissue all API keys and certificates stored on or flowing through any appliance that was running a vulnerable build after October 1, 2026.
  6. Harden network segmentation immediately. If your ICS gateway has lateral-movement paths into internal segments, constrain them now with firewall micro-segmentation. Zero-trust principles — default-deny, continuous verification — are the architectural response that makes a compromised VPN gateway survivable without turning into a full-breach event.
  7. Alert your SOC to pattern-match on re-exploit behavior. Because UTA0576 re-runs the chain per command, you may see repeated short-lived anomalous CGI calls rather than persistent shell activity. Tune your EDR/NDR rules accordingly.

The Bigger Picture: VPN Gateways as Soft Underbelly

The pattern is clear and accelerating. SSL VPN and remote-access gateways — Ivanti, Cisco, Palo Alto, Fortinet — have become the preferred initial-access vector for both nation-state and financially motivated threat actors. The reasons are structural: they sit at the perimeter, they are always internet-facing, they aggregate credentials, and they are notoriously difficult to patch without service interruption.

For Indian enterprises operating in sectors under CERT-In’s mandatory 6-hour incident reporting window, a compromised VPN gateway that has been silently exfiltrating credentials for weeks is a regulatory nightmare on top of a security one. The answer is not to run VPN gateways more carefully — it is to architect your network so that a compromised gateway is a contained incident rather than the first domino in a full breach. That means zero trust, segmentation, identity-aware access controls, and continuous monitoring with behaviour-based detection that does not depend on VPN-side log integrity.


Frequently Asked Questions

Does patching Ivanti Connect Secure guarantee my environment is safe?

Patching stops future exploitation of CVE-2026-104935, but it does not remediate a breach that may already have occurred. CISA recommends treating any appliance that ran a vulnerable build after 1 October 2026 as potentially compromised — upgrade and rotate all credentials, API keys, and certificates stored on or transiting the device. Also note that the privilege-escalation (Stage 3) component of the chain may not yet be fully patched in all fixed builds; verify with Ivanti’s latest advisory.

Can Ivanti’s Integrity Checker Tool (ICT) detect this attack?

No, not reliably. Volexity has confirmed that UTA0576’s technique patches code in memory only and restores original state after each command execution, meaning ICT scans return clean even on actively exploited appliances. Memory forensics and out-of-band log review (upstream syslog, SIEM) are necessary complements to ICT scanning.

What CVE IDs are associated with this chain, and what were CISA’s deadlines?

The primary disclosed CVE is CVE-2026-104935 (CVSS 8.6, authentication bypass), added to CISA’s KEV on 13 October 2026 with a federal agency deadline of 16 October. CISA added additional CVEs from the same chain on 30 October 2026. The chained components cover authentication bypass, remote code execution (race condition), and privilege escalation to root — three distinct vulnerabilities weaponised as a single exploit chain.

How does this relate to the broader trend of AI-assisted hacking?

Volexity assessed with medium confidence that UTA0576 used LLM tooling to develop its exploit chain. This is significant: it suggests adversaries are now using AI to compress the timeline from vulnerability discovery to weaponised zero-day exploit. Defenders must accelerate patch cycles and assume shorter windows between disclosure and active exploitation. The UTA0576 campaign demonstrated exploitation beginning before any public CVE disclosure — targeting a patch-current appliance.


📌 Ready to assess your VPN perimeter before the next zero-day hits?

At P J Networks, we specialise in VPN security reviews, zero-trust architecture design, and 24×7 SOC monitoring for Indian enterprises. If you are running Ivanti, Cisco, Palo Alto, or Fortinet gateways and want a rapid assessment of your exposure and hardening posture, reach out to Sanjay Seth directly. A one-hour consultation could save you months of breach remediation.