Hackers Are Exploiting an Ivanti VPN Zero-Day Right Now. Patch Immediately
Ivanti disclosed an authentication-bypass zero-day in Connect Secure on October 13, and attackers are already chaining it to root on patched appliances. CISA has added it to its KEV catalog — patch now.
If you run Ivanti, stop reading and patch
Ivanti disclosed CVE-2026-104935 on October 13: an authentication bypass in Connect Secure, its VPN and gateway product, that lets an unauthenticated attacker run commands remotely. CVSS score: 8.6. And it is not theoretical — researchers have confirmed active exploitation in the wild, and CISA has already added it to its Known Exploited Vulnerabilities catalog.
This is the part that should worry every IT admin: security firm Volexity found an unknown threat actor, tracked as UTA0576, chaining the auth bypass with remote code execution and privilege escalation to get root on fully patched Connect Secure appliances. Fully patched. The attackers are going after LAPS passwords and BitLocker recovery keys — the crown jewels of Windows credential management — which tells you this is not opportunistic scanning. It is targeted, and it is working.
How bad is it, technically
Bad in the way that makes security engineers tired. WatchTowr demonstrated that the whole attack reduces to a single crafted HTTP header — one X-DSCGI-PATH header — to bypass authentication. When your zero-day fits in a header, every exposed appliance on the internet is a sitting target.
Affected versions are 25.1.1.1 and prior, 25.1.2.2 and prior, and 22.8R2.4 and prior. The fixes are 25.1.1.2, 25.1.3.0, 25.1.3.1, and 22.8R2.5. If your appliance was internet-facing while vulnerable, assume the worst and hunt for compromise — do not just patch and move on. CISA's warning specifically calls out credential theft and data exfiltration as observed impacts.
The Ivanti pattern
Here is the uncomfortable context: this is the 15th Ivanti Connect Secure and Pulse Connect Secure flaw to land on CISA's KEV list. The pattern of zero-day targeting stretches back through 2024 and 2025, and it has not slowed down. At some point the question stops being whether there is another Ivanti bug and becomes why this product is still internet-facing in your environment.
That sounds harsh, but compare it with the BricksForge WordPress flaw we covered — attackers exploiting a plugin vulnerability before disclosure. The industry keeps relearning the same lesson: edge devices with a history of zero-days need aggressive patching, network segmentation, and monitoring, not hope.
What to do today
- Patch Connect Secure to a fixed version immediately. This is a drop-everything patch.
- If the appliance was exposed to the internet while vulnerable, investigate for compromise before trusting it — check for unexpected accounts, persistence mechanisms, and credential access.
- Rotate credentials that transited the appliance, especially LAPS and BitLocker recovery keys.
- Longer term, review whether remote-access gateways with this track record should be directly internet-facing at all.
And if you are wondering whether your own data has already been caught up in one of these waves, our guide on checking if your data was leaked walks through the first hour after you find out. Patch first, though. Patch first.
Check whether you are exposed
The Ivanti zero-day patch for CVE-2026-104935 is available now in versions 25.1.1.2, 25.1.3.0, 25.1.3.1, and 22.8R2.5 — but a patch only helps if you know you need it. Check your Connect Secure version in the admin console today, and inventory every appliance, including the forgotten ones deployed for a single department three years ago. Attackers are excellent at finding the appliances you forgot.
If you cannot patch immediately, reduce the blast radius now: restrict the management interface to internal networks, put the appliance behind additional access controls, and monitor for the indicators of compromise Volexity published with its disclosure. Internet-facing VPN concentrators with a history of zero-days should never be reachable from the whole internet with default exposure. Treat this incident as the audit trigger — find every edge device in your environment with a similar track record and get them behind proper segmentation before the next CVE drops.


