On October 13, 2026, Ivanti disclosed an actively exploited zero-day vulnerability in its Connect Secure VPN appliances and urged customers to patch immediately. The flaw, tracked as CVE-2026-104935, lets a remote attacker bypass authentication and run arbitrary commands on the appliance without logging in. Worse, researchers at Volexity found an unknown threat actor chaining it with two more flaws to gain full root access on a fully patched device. If your organization runs Ivanti Connect Secure, this is a patch-now situation, not a patch-next-week one.
What Is CVE-2026-104935?
CVE-2026-104935 is an authentication bypass vulnerability in Ivanti Connect Secure (ICS), the enterprise SSL VPN gateway formerly known as Pulse Connect Secure. It carries a CVSS score of 8.6, rated high severity. A remote, unauthenticated attacker can exploit it in a low-complexity attack that needs no user interaction, and the result is arbitrary command execution on the appliance.
According to analysis by watchTowr, the root cause is strikingly simple. A single request carrying a specially crafted X-DSCGI-PATH header is enough to bypass authentication and reach functionality that should be restricted. Ivanti confirmed it was aware of limited exploitation in the wild at the time of disclosure and said it is working directly with affected organizations.
One detail matters for anyone planning a response: the CVE identifier actually covers two of the three flaws in the observed attack chain, the authentication bypass and a remote code execution bug. A third flaw, a privilege escalation issue, remains unpatched, with a fix expected in a future release in the coming weeks.
How Attackers Chained the Flaws to Root Access
Volexity discovered the exploitation during an incident investigation in the first week of October 2026. An unknown threat actor it tracks as UTA0576 had compromised a customer appliance running version 22.8R2.4, which was fully patched at the time. Evidence of exploitation dates back to October 3, 2026, ten days before Ivanti published its advisory.
The attack chain worked in three stages:
- Authentication bypass (CVE-2026-104935): The crafted X-DSCGI-PATH header let the attacker past the login check entirely.
- Remote code execution (CVE-2026-104935): The attacker exploited a race condition in the wu.cgi component to execute an uploaded Perl script, gaining code execution as the appliance cgi-server user.
- Privilege escalation (unpatched): The attacker abused the dsinvoked component and modified in-memory library code to raise access from the service account to root.
Once the attacker had root, the focus turned to credential theft. Volexity reports that UTA0576 stole domain credentials stored on the appliance, searched Active Directory for LAPS passwords and BitLocker recovery keys using a custom tool, ran password-spraying attacks, tested credentials with a custom Kerberos tool, and tried to extract credentials from captured network traffic. The attacker also scanned the internal network, collected the appliance configuration, parsed authentication logs to identify valid usernames, and tampered with logs to cover its tracks.
Notably, Volexity found no backdoor or web shell on the device. Commands and results traveled through the exploit channel itself, and key changes were made in memory and then restored. That matters because it means Ivanti Integrity Checker Tool may miss this activity. Volexity recommends forensic investigation, including network and memory forensics, for any appliance suspected of compromise.
Which Versions Are Affected
The vulnerability affects the following Ivanti Connect Secure versions:
- 22.8R2.4 and earlier
- 25.1.2.2 and earlier
- 25.1.1.1 and earlier
Ivanti has released fixes in versions 22.8R2.5, 25.1.1.2, 25.1.3.0, and 25.1.3.1. Versions 22.7.x and below are not affected. If you are unsure which version you run, check the appliance admin console or the version banner before doing anything else.
The US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-104935 to its Known Exploited Vulnerabilities (KEV) catalog on October 13, 2026, after observing active exploitation. Federal civilian agencies face a binding patch deadline under KEV rules, and every other organization should treat the same urgency as a baseline. Internet threat watchdog Shadowserver tracks more than 5,500 Ivanti Connect Secure instances exposed online, which gives attackers a large pool of targets. This is the 15th Ivanti Connect Secure or Pulse Connect Secure vulnerability to land in the KEV catalog.
What to Do Right Now
If you run an affected version, work through these steps in order:
- Patch immediately. Upgrade to 22.8R2.5, 25.1.1.2, 25.1.3.0, or 25.1.3.1, depending on your release line. Do not wait for a maintenance window if the appliance is internet-facing.
- Run the Integrity Checker Tool. Ivanti recommends running it regularly, but treat a clean result as inconclusive for this incident, since the observed attack made in-memory changes that the tool can miss.
- Hunt for signs of compromise. Look for mismatches between request paths and the X-DSCGI-PATH header, gaps or tampering in logs, unexpected outbound connections, and password-spraying patterns in authentication logs.
- Rotate credentials. If the appliance may have been exposed since early October, reset Active Directory passwords for accounts that authenticated through it, rotate LAPS passwords, rotate BitLocker recovery keys, and revoke VPN credentials and certificates.
- Assume breach if the timeline fits. If your appliance was internet-facing and unpatched between October 3 and the day you applied the fix, bring in incident response and run network and memory forensics rather than assuming the patch alone closed the incident.
- Plan for the remaining flaw. The privilege escalation vulnerability is still unpatched. Watch for Ivanti next release, and until it lands, treat the appliance as a higher-risk asset with extra monitoring.
Why Ivanti VPN Flaws Keep Getting Exploited
Ivanti Connect Secure sits at the edge of the corporate network by design. It is internet-facing, it handles authentication, and it often stores credentials and session data that attackers can reuse to move deeper inside. That combination makes it one of the most attractive targets in enterprise security, and attackers have noticed. Rapid7 pointed out that zero-day exploitation of other Ivanti vulnerabilities already occurred in both 2024 and 2025, so this is a pattern, not a one-off.
The same logic applies to other edge appliances. Recent weeks alone have brought a critical F5 BIG-IP zero-day, a Citrix NetScaler zero-day, and a SonicWall SMA 1000 flaw with a CVSS 10.0 score. If your patching program still treats VPN and gateway appliances like ordinary servers, this incident is a good reason to move them into a faster lane with dedicated monitoring.
The broader lesson from the Volexity investigation is that patching alone is not always enough. The victim in this case was fully patched, and the attacker still got root by chaining a fresh zero-day with an unpatched privilege escalation flaw. Defense in depth, network segmentation, credential hygiene, and real forensic capability are what separate a patched appliance from a contained incident.
Frequently Asked Questions
Is CVE-2026-104935 being exploited in the wild?
Yes. Ivanti confirmed limited exploitation in the wild at disclosure on October 13, 2026. Volexity traced exploitation back to October 3, 2026, against at least one customer. CISA added the flaw to its Known Exploited Vulnerabilities catalog the same day.
Does patching fully fix the problem?
Patching closes the authentication bypass and the remote code execution flaw, which breaks the observed attack chain at its first two links. However, the third flaw, a privilege escalation vulnerability, is still unpatched. Apply the available patch now and watch for Ivanti next release.
Am I affected if I run version 22.7.x or older?
No. Ivanti confirmed that versions 22.7.x and below are not affected by CVE-2026-104935. Still, running an older release line carries its own risks, so keep it patched against other known flaws.
How do I know if my appliance was compromised?
Look for mismatches between request paths and the X-DSCGI-PATH header, missing or altered log entries, password-spraying activity, and unexpected credential use. Because the attacker modified code in memory and restored it, a clean Integrity Checker Tool result does not prove the appliance is clean. Suspected compromises need network and memory forensics.
What should I rotate after patching?
At minimum, rotate Active Directory passwords for accounts that used the VPN, LAPS passwords, BitLocker recovery keys, and any certificates or credentials stored on the appliance. If you cannot rule out compromise, treat all of it as exposed.