Summary

Ivanti has fixed a zero-day in Ivanti Connect Secure (ICS), its widely used SSL VPN gateway, tracked as CVE-2026-104935. The flaw lets a remote attacker run commands on the appliance without an account and without any help from a user. The researchers who found and reported it saw it used as the middle step in a three-part chain that adds a file-write race condition and a privilege escalation bug, handing an unauthenticated attacker root access on a fully updated device.

Ivanti covers both the bypass and the code execution under this one CVE and released patches on October 13, 2026, though the privilege escalation flaw is still unfixed and is expected in a later release. The attacks on Ivanti Connect Secure are linked to UTA0576, a previously unknown threat actor that deployed no malware.

Threat Actor

Affected Products

CVE

Vulnerability Details

1. #01

   CVE-2026-104935 is an authentication bypass by spoofing flaw in Ivanti Connect Secure, the remote access gateway organisations use to let staff reach internal systems over a VPN. A remote attacker needs nothing more than network access to the appliance: no account, no credentials, and no action from a user. Ivanti has placed two distinct weaknesses under this one identifier, an authentication bypass and a remote code execution flaw, because in practice they are used together. The researchers who reported the issue described a chain of three flaws in total, the third being a privilege escalation bug that Ivanti has not yet fixed.

2. #02

   The bypass comes down to the appliance checking one thing and acting on another. When a request arrives, ICS uses the URL path to decide whether the request is allowed, but uses a header value, X-DSCGI-PATH, to decide which script actually handles it. An attacker therefore sends a request to the public login page at /dana-na/auth/url_default/welcome.cgi, which passes the permission check, while naming a protected script in the header so the request is delivered somewhere it should never reach. The script the attacker points at, wu.cgi, carries the second flaw. Its upload handler writes a submitted file to /home/runtime/tmp/, named after the MD5 hash of the supplied filename, and only checks afterwards whether the file is a valid ZIP archive. A Perl script disguised with a .zip extension fails that check and gets deleted, but it sits on disk for a moment first. By firing parallel requests at that path during the brief window, the attacker wins the race, and the script executes. The uploaded Perl script then launches a Bash script, which in turn decodes and runs a Base64-encoded, zlib-compressed Python payload entirely in memory.

3. #03

   Ivanti lists the 22.8.X bridge release up to 22.8R2.4, version 25.1.1.1 on ISA6000 and ISA8000 hardware, and builds 25.1.2.2 and earlier as affected; versions 22.7.X and earlier do not contain the flaw. Fixed releases are 22.8R2.5, 25.1.1.2, and 25.1.3.0 or 25.1.3.1, all available as of October 13, 2026. Ivanti notes that part of the fix already shipped in the July 25.1.3.0 release and the remainder was backported. No CVSS score had been assigned at the time of writing. Organisations still on the 22.8.X bridge line or any build before 25.1.3.0 should be treated as the highest priority.

4. #04

   Exploitation preceded the patch by roughly two weeks. UTA0576 has been exploiting the flaw since the first week of October. The actor never installed a backdoor or web shell, re-exploiting the device for each command and returning results in the HTTP response, which leaves very little behind. What it did leave, it removed: the payload selectively trims entries from /home/runtime/dlogs/debuglog and /var/log/audit/audit.log, deletes its own scripts and temporary output, restores the configuration entry it tampered with, and reverses an in-memory patch to the libdsplibs.so library through /proc/self/mem. Because nothing on disk changes, Ivanti's Integrity Checker Tool does not flag the compromise, and Ivanti has stated that no reliable indicators of compromise are available for the vulnerability itself. Confirming a breach requires memory and network forensics rather than a signature scan.

Vulnerability

Recommendations

1. 01
   Patch the Appliance Today

   Update Ivanti Connect Secure to the fixed release for your branch straight away: 22.8R2.5, 25.1.1.2, or 25.1.3.0 / 25.1.3.1. Exploitation started before the patch existed, and the vulnerability is already in CISA's Known Exploited Vulnerabilities catalog, so there is no safe waiting period. Note that moving to 25.1.3.0 requires ISA4500, ISA6500, or ISA8500 hardware, or a rebuilt virtual or cloud appliance on the new template.

2. 02
   Assume Compromise and Investigate Properly

   Do not rely on the Ivanti Integrity Checker Tool to tell you whether the device is clean. The exploit chain patches library code in memory and restores it afterwards, so nothing on disk changes and the tool reports no modifications. Preserve logs and take memory and disk images from affected appliances before you change anything, then run a proper forensic review. Check the /tmp/ and /data/.icscap/ directories for leftover scripts, packet captures, and output files, and look for gaps or truncation in /home/runtime/dlogs/debuglog and /var/log/audit/audit.log.

3. 03
   Rotate Every Credential the Appliance Could Reach

   If there is any sign of compromise, treat the appliance's stored secrets as stolen. Reset the Active Directory service account used for LDAP, rotate local administrator passwords managed through LAPS, regenerate BitLocker recovery keys, and force password resets for accounts seen in authentication logs. The actor specifically hunted for LAPS credentials, BitLocker recovery information, and userPassword and unixUserPassword attributes, so a patch alone does not close the exposure those secrets create.

4. 04
   Hunt for the Exploit Pattern in Your Logs

   Watch for large volumes of requests to /dana-na/auth/url_default/welcome.cgi, especially where the X-DSCGI-PATH header points somewhere other than the requested URL. Mismatches between the URL path and that header are the clearest signal of this technique, and attackers are likely to find other script paths that work the same way, so monitor for the mismatch itself rather than the two specific paths seen so far. Also look for unexpected packet capture activity on the appliance and for processes running from hidden directories.

5. 05
   Shrink the Exposure of Your VPN Gateway

   Restrict network access to Ivanti Connect Secure management and gateway interfaces wherever the business allows, and keep management planes off the public internet entirely. Edge devices like this sit in the path of authentication traffic and sensitive internal connections, which makes them a repeat target, so limiting who can reach them meaningfully reduces the number of people who can attempt exploitation.

6. 06
   Plan the Move Off End-of-Life Branches

   The 22.7 and 22.8 lines reach end of life on January 31, 2027, and 22.8.X was only ever intended as a temporary bridge toward 25.1. Build the migration into your roadmap now rather than discovering the deadline during the next emergency patch cycle, and keep an inventory of appliance versions so you know exactly which devices are affected the moment the next advisory lands.

Indicators of Compromise (IoCs)

MITRE ATT&CK TTPs

References & Patch Links

Patch Link

• Ivanti Advisoryhttps://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935?language=en_US

References

• https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935?language=en_US
• https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/