A patch that didn't stop the attacker
Ivanti disclosed on October 13 that CVE-2026-104935, a high-severity authentication bypass in Connect Secure, was being actively exploited as a zero-day. The flaw affects versions 22.8R2.4 and earlier, 25.1.2.2 and earlier, and 25.1.1.1 and earlier, and lets an unauthenticated remote attacker run arbitrary commands with no user interaction and low attack complexity. Ivanti released fixes the same day, in versions 22.8R2.5, 25.1.3.0, 25.1.3.1, and 25.1.1.2, and told customers to act immediately given limited exploitation already observed in the wild.
What made this disclosure more alarming than a standard patch-now advisory is what security firm Volexity found underneath it. The actor it tracks as UTA0576 wasn't just exploiting the one new flaw. It chained CVE-2026-104935 with two other vulnerabilities, at least one of which Ivanti had already patched, to achieve unauthenticated, root-level code execution on devices that administrators believed were fully up to date. A device being current on patches is no longer sufficient evidence that it's safe from this specific attack chain.
No malware, no persistence, no obvious forensic trail
Most intrusions leave something behind: a web shell, a dropped binary, a scheduled task. Volexity reported that UTA0576 deployed none of that. Instead, the actor re-exploited the device fresh for every single command it wanted to run, then tampered with logs to cover the activity. Because nothing persisted to disk, Ivanti's Integrity Checker Tool, the primary mechanism administrators use to verify an appliance hasn't been tampered with, consistently failed to flag the compromise.
CISA's own guidance acknowledged this gap directly, warning that forensic investigation would require network and memory analysis specifically because, in the agency's words, threat actor commands execute in memory. That is a meaningfully higher bar than most organizations' incident response playbooks assume for a VPN appliance compromise, and it means a standard integrity check passing clean is no longer grounds for confidence that a Connect Secure appliance hasn't been compromised by this particular technique.
The exploitation timeline moved faster than disclosure
Volexity says UTA0576 has been chaining this flaw since at least October 3, a full ten days before Ivanti's public disclosure on October 13. Independent monitoring firm Defused separately corroborated the timeline, reporting the first signs of exploitation starting October 1, two days earlier still. That gap between first exploitation and public disclosure is the window during which every internet-facing Connect Secure appliance was vulnerable with zero public warning available to defenders, and during which any organization running the product had no way to know it needed to act.
CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on October 13, the same day as disclosure, and gave federal civilian executive branch agencies until that Friday to secure their networks under Binding Operational Directive 26-04. That is an unusually tight remediation window even by CISA's own standards for actively exploited edge-device flaws, reflecting how seriously the agency weighed the combination of a pre-auth root-execution chain and the sophistication required to evade standard appliance integrity checks.
What attackers reached once they were inside
Getting root on the VPN appliance wasn't the endpoint of the attack, it was the entry point. Post-exploitation activity observed by Volexity targeted Active Directory credentials and secrets stored or cached in environments reachable from the compromised appliance, including Local Administrator Password Solution passwords and BitLocker recovery keys. Both of those credential types are specifically designed to let IT administrators recover access to locked-down endpoints, which makes them extremely valuable to an attacker trying to move from one compromised VPN gateway into broad control of an organization's Windows environment.
This is the pattern that has made edge devices, VPN concentrators, firewalls, and secure-access gateways the preferred entry point for sophisticated intrusions over the last several years: they sit at the perimeter with privileged visibility into the internal network, they're harder to instrument with endpoint detection tooling than a standard server, and a single successful exploit chain can yield credentials that unlock far more than the device itself ever touched directly.
A pattern Ivanti customers have seen before
CISA's advisory included a sobering piece of context: the agency has added 36 separate Ivanti vulnerabilities to its KEV catalog since November 2021, and ransomware groups have independently weaponized 12 of them for their own campaigns, separate from whatever nation-state or opportunistic actors exploited them first. Past Connect Secure zero-days include CVE-2023-46805, CVE-2024-21887, CVE-2024-21893, CVE-2025-0282, and CVE-2025-22457, a cadence that works out to roughly one actively exploited Connect Secure zero-day every few months for the past three years running.
For organizations that have stuck with Ivanti's remote-access products through that run, the calculus is no longer about any single CVE in isolation. It's about whether a product line with this frequency of pre-authentication, root-level compromises, now compounded by an exploit chain specifically engineered to defeat the vendor's own integrity verification tooling, still belongs in a security architecture that depends on perimeter devices being trustworthy by default, or whether the repeated pattern itself is the signal worth acting on.
What to do if you run Connect Secure
Patching to the fixed versions is necessary but, per Volexity's findings, not sufficient to confirm a device is clean if it was exploited before the patch was applied. Ivanti and CISA's joint recommendation for any appliance where compromise is suspected is to back up the configuration, perform a full factory reset, rebuild cloud or virtual instances entirely rather than patching in place, then restore configuration and reset every credential the appliance had access to: domain and local administrator passwords, certificates, API keys, and license server credentials.
With more than 5,600 internet-exposed Connect Secure instances tracked by Shadowserver at disclosure time, and no reliable way to distinguish patched-but-still-compromised appliances from genuinely clean ones through standard integrity checks, organizations running this product should treat any instance that was internet-facing before October 13 as a candidate for full rebuild, not just patch-and-move-on, regardless of what the Integrity Checker Tool currently reports. Budget for the rebuild now, because waiting for a tool that cannot see in-memory compromise to clear the appliance is not a real remediation path.
