A familiar device, a new way in
CISA added three Ivanti Connect Secure vulnerabilities to its Known Exploited Vulnerabilities catalog on October 30: CVE-2026-111357, a missing authentication check that lets an authenticated local attacker escalate privileges, rated 8.8; CVE-2026-118527, a predictable identifier that lets an authenticated remote attacker upload malicious files to a known location, rated 4.3; and CVE-2026-104935, an authentication bypass that security firm Volexity has linked to the other two as part of a single exploit chain. CISA had already added that third flaw to its catalog on October 13, meaning the agency recognized part of the chain more than two weeks before it recognized the whole thing.
Chained together, the three flaws let an attacker skip authentication entirely and reach root access on the appliance without ever presenting valid credentials. Ivanti had partially addressed the issue in its July 25.1.3.0 release, but that fix did not close the complete chain, leaving the authentication bypass component exploitable on its own for months afterward. Customers running Connect Secure 25.1.1.2 or earlier, or 22.8R2.5 or earlier, need to move to 25.1.1.3 or 22.8R2.6 respectively. The gap between the partial July fix and the complete one is exactly the kind of window attackers count on, and in this case it stayed open long enough for a named threat actor to walk through it.
What the attacker actually went after
Volexity, which identified the active exploitation in early October and published its findings in mid-October, tracks the actor as UTA0576. VPN appliance compromises are unfortunately routine at this point, so the initial access alone would not be remarkable. What stands out in Volexity's writeup is the target list once the actor was already inside: Active Directory credentials, LAPS passwords used to manage local administrator accounts across the domain, and BitLocker recovery keys that unlock encrypted drives. Each of those targets requires additional steps beyond simply owning the appliance, which points to a methodical post-exploitation playbook rather than smash-and-grab access.
That combination represents a deliberate move toward full domain compromise and data-at-rest access. An attacker holding LAPS passwords can log into any workstation in the environment as a local administrator. One holding BitLocker keys can read the contents of an encrypted laptop without ever touching the original owner's password. Together, those two capabilities effectively neutralize two of the most common endpoint protections enterprises rely on. Volexity's advisory urged customers to investigate systems for signs of lateral movement originating from the VPN device itself, a strong signal that this specific breach moved well past the appliance in multiple observed cases.
The edge device problem has not gone away
Ivanti's VPN products have been a recurring target for exactly this reason: they sit at the network perimeter by design, they are internet-facing by necessity, and a successful compromise hands the attacker a trusted vantage point deep inside the corporate network rather than a foothold at the edge of it. Security teams have treated this as a known risk for several product generations now, yet the appliances remain widely deployed because ripping out remote access infrastructure is expensive and disruptive in a way that patching rarely is. Procurement cycles for replacing edge infrastructure run in years, while exploit chains against it get refined in weeks, and that mismatch in tempo is the actual root cause here.
Ivanti, for its part, said it chose to ship the July fix for the primary exploitation path rather than hold it back to bundle a complete patch: "we made the decision to not delay getting a fix to customers that resolved the primary exploitation path." That is a defensible call under pressure, but it also means customers who patched in July and considered the matter closed were still exposed to the chain Volexity found in October. A partial fix communicated as a fix creates exactly this kind of false confidence.
Why this keeps happening to VPN appliances specifically
VPN gateways occupy an unusual architectural position: they need enough privilege to authenticate users into the broader network, which means a compromise of the appliance itself tends to inherit disproportionate trust compared to compromising an ordinary server. They also run vendor-controlled software stacks that enterprise security teams cannot inspect or harden the way they would an internally managed Linux box, which puts patch timing and vendor transparency entirely outside the customer's control. Security teams can scan their own servers for drift from baseline at will. They cannot do the same to a sealed appliance running Ivanti's firmware, which forces a dependency on the vendor's own disclosure timeline for even knowing something is wrong.
That combination, high trust plus low visibility plus vendor-dependent patching, is why Ivanti, and before it other VPN and edge device vendors, keep appearing in exploitation chains aimed at credential theft rather than simple denial of service. The fix is not a better firewall rule. It is architectural: treating the VPN appliance itself as untrusted infrastructure, segmented away from the credential stores and encryption key management systems that an attacker would want once inside.
The decision CIOs are actually facing
Zero trust network access vendors have been pitching exactly this migration for several years: replace the perimeter VPN appliance with identity-aware, per-application access that never grants a compromised edge device domain-wide reach in the first place. Most enterprises have not made that move, partly from inertia and partly because VPN replacement projects compete for budget against features that generate revenue rather than avoid incidents that may or may not happen on any given quarter.
Ivanti is not uniquely flawed among VPN vendors. The architecture class it represents keeps producing the same outcome across different brands: appliance compromise, lateral movement to AD and key management, full domain exposure. That pattern is the real argument for moving ZTNA migration up the priority list this budget cycle rather than the next one. Until that migration happens, the minimum viable fix is isolating LAPS and BitLocker key storage from anything reachable by the VPN segment, so a compromised gateway stops being a direct path to the keys that unlock everything else, and starts being merely an incident to clean up.
