- October 13, 2026
High-Severity Authentication Bypass Vulnerability in Ivanti Connect Secure Under Active Exploitation (CVE-2026-104935)
An actively exploited zero-day in Ivanti Connect Secure lets unauthenticated attackers run commands on the VPN gateway. Attackers have chained it with a still unpatched flaw to gain root access and steal Active Directory secrets.
Executive Summary
On October 13th, 2026, Ivanti disclosed a vulnerability in Ivanti Connect Secure (ICS) and confirmed limited exploitation in the wild. Tracked as CVE-2026-104935, the flaw lets an unauthenticated, remote attacker bypass authentication and execute arbitrary commands on the appliance.
Connect Secure is an SSL VPN gateway that gives remote users access to corporate networks. A compromised gateway gives attackers a direct path into the environment it protects. The attackers left no malware on the appliance and evaded Ivanti's Integrity Checker Tool. Given confirmed zero-day exploitation, the edge position of these gateways, and the long history of Connect Secure targeting, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.
Affected Systems or Products
Product | Affected Versions | Fixed Versions |
|---|---|---|
Ivanti Connect Secure 25.1.1 | 25.1.1.1 and earlier | 25.1.1.2 |
Ivanti Connect Secure 25.1.2 | 25.1.2.2 and earlier | 25.1.3.0 or 25.1.3.1 |
Ivanti Connect Secure 22.8 | 22.8R2.4 and earlier | 22.8R2.5 (or migrate to 25.1.1.2 or later) |
Mitigations / Workarounds
Ivanti directs customers to upgrade to a fixed release, act immediately if they run an affected version, and run the Integrity Checker Tool regularly. Ivanti advises 22.8 customers to move to 25.1.1.2 or later, or to install 22.8R2.5 if migration cannot happen right away. Customers on 25.1.1.1 with ISA6000 or ISA8000 appliances should install 25.1.1.2. Migrating to 25.1.3.0 requires the ISA4500, ISA6500, or ISA8500 platform: physical deployments need the new hardware, and virtual and cloud deployments need newly built devices from the appropriate template. Ivanti states that ICS 22.7R2.14 and earlier are not affected, and both the 22.7 and 22.8 branches reach end of life on January 31st, 2027.
The fixed releases do not address the privilege escalation flaw used in the observed chain, which remains unpatched at the time of writing. The attackers ran that local privilege escalation from the code execution CVE-2026-104935 gave them, so patching CVE-2026-104935 closes the unauthenticated entry point used in the observed attacks. Apply Ivanti's follow-up release when it ships.
If patching cannot be immediately applied, the following may help to temporarily reduce risk:
Limit which networks can reach the ICS web portal where your remote access requirements allow it.
Where a reverse proxy or web application firewall sits in front of the appliance, block inbound requests that carry an
X-DSCGI-PATHheader, after testing that legitimate client traffic does not use it.Review the permissions of the Active Directory service account the appliance uses, and remove read access to LAPS passwords, BitLocker recovery information, and password-bearing attributes it does not need.
Hunt for the behavior and artifacts listed under Indicators of Compromise, and do not treat a clean Integrity Checker Tool result as proof the appliance is uncompromised.
Patches
Ivanti released fixes for the remaining supported branches on October 13th, 2026. Fixed builds, upgrade guidance, and recovery instructions are available in the Ivanti security advisory. According to Volexity, Ivanti is working on a fix for the chained privilege escalation flaw, expected in a future release in the coming weeks.
Indicators of Compromise
On October 13th, 2026, CISA added CVE-2026-104935 to its Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild. Ivanti reports exploitation affecting a limited number of customers and has stated that it has no reliable indicators of compromise at this time. Volexity investigated a confirmed intrusion. It reports that the threat actor it tracks as UTA0576 exploited a fully patched 22.8R2.4 appliance repeatedly starting October 3rd, 2026.
Detection on the appliance itself is difficult. UTA0576 deployed no web shell or backdoor, re-ran the full exploit chain for every command, and returned results in the HTTPS response. Its payloads patched library code in memory only and restored the modified configuration afterward. They also selectively deleted recent entries from
/home/runtime/dlogs/debuglog
and /var/log/audit/audit.log. Volexity reconstructed the chain only through memory images and core dumps, and recommends network and memory forensics for any appliance suspected of compromise.
Defenders should review:
Web or proxy logs in front of the appliance for bursts of requests to
/dana-na/auth/url_default/welcome.cgicarrying anX-DSCGI-PATHheader, such asX-DSCGI-PATH: /home/webserver/htdocs/dana/fb/smb/wu.cgiorX-DSCGI-PATH: /home/runtime/tmp/<MD5(filename)>
Volexity expects attackers to find other URL and header targets, so mismatches between the URL path and the header are the stronger signal.
The appliance
/tmp/directory, which is where Volexity recovered attacker-written files, and the hidden/data/.icscap/directory.Core dumps on the appliance generated around the time of suspected activity, which Volexity used to reconstruct the exploit.
Domain controller and network logs for LDAP queries, Kerberos activity, and password spraying originating from the ICS appliance or its Active Directory service account.
Treat any appliance with a matching indicator as compromised and follow Ivanti's recovery instructions. UTA0576 used the appliance's Active Directory service account and searched for LAPS passwords and BitLocker recovery keys. Treat that service account, those secrets, and credentials stored on the appliance as exposed and rotate them. Volexity has published related indicators on its GitHub page.
Indicator | Type | Description | Source |
|---|---|---|---|
108.165.147[.]64 | IPv4 | Evoxt VPS used by UTA0576 for the operation; ran an OpenVPN server from September 30th to October 7th, 2026 | Volexity |
/dana-na/auth/url_default/welcome.cgi | URL | Public login script targeted for the authentication bypass; watch for high request volumes carrying an X-DSCGI-PATH header | Volexity |
X-DSCGI-PATH: /home/webserver/htdocs/dana/fb/smb/wu.cgi | Other | Request header used to route unauthenticated requests to the protected wu.cgi upload handler | Volexity |
X-DSCGI-PATH: /home/runtime/tmp/<MD5(filename)> | Other | Request header used to execute the uploaded script during the race window | Volexity |
/data/.icscap/dsstatmond | File path | Renamed tcpdump binary run from a hidden directory to capture LDAP, HTTP, FTP, and telnet traffic | Volexity |
/data/.icscap/cap* | File path | Rotating packet capture files (eight observed) written by dsstatmond | Volexity |
/data/.icscap/h.py | File path | Python script that parses captures for plaintext LDAP and HTTP Basic credentials and NTLM challenge-response hashes | Volexity |
/tmp/ml.py | File path | Custom LDAPv3 tool used to query Active Directory | Volexity |
/tmp/rq5.py | File path | Script searching Active Directory for LAPS passwords, BitLocker recovery keys, and password-bearing attributes | Volexity |
/tmp/mk.py | File path | Python Kerberos implementation with Kerberoast capability | Volexity |
/tmp/rr.py | File path | Script using mk.py to test credentials | Volexity |
/tmp/pu.txt | File path | Usernames extracted from the log.events.vc0 authentication log | Volexity |
/tmp/sp_out.txt | File path | Password spraying output written by sp_run.py and exfiltrated | Volexity |
/tmp/spray_hits.json | File path | Password spraying results written by sp_run.py and exfiltrated | Volexity |
/home/runtime/tmp/ics-root-run-inband-*.pl | File path | Root-stage Perl payload that deletes itself after execution | Volexity |
/home/runtime/tmp/ics-root-result-inband-* | File path | Temporary command output from root-level execution, removed by the payload | Volexity |
How Beazley Security is responding
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.