Ivanti has patched 2 more zero-day vulnerabilities in Ivanti Connect Secure (ICS) that attackers chained with a previously disclosed authentication bypass to take full root control of VPN appliances that were fully patched at the time. The new flaws, CVE-2026-111357 and CVE-2026-118527, were added to Ivanti’s October 13 advisory on October 29, and CISA added both to its Known Exploited Vulnerabilities (KEV) catalog on October 30.
Organizations that patched in October for the first bug, CVE-2026-104935, are not done. The releases that fixed that flaw, 25.1.1.2 and 22.8R2.5, do not fix the 2 new ones. Ivanti says the attacks hit a limited number of customers before disclosure, and that its latest release “addresses all vulnerabilities which were chained and exploited in the wild.”
The 3 vulnerabilities in the chain
Volexity discovered the exploitation while responding to an incident at a customer and published a detailed technical write-up on October 13. It tracks the attacker as UTA0576, a previously unknown threat actor. The chain combines 3 bugs:
- CVE-2026-104935 (CVSS 8.6, CWE-290): an authentication bypass that gives an unauthenticated attacker a path to remote code execution. CISA added it to KEV on October 13.
- CVE-2026-118527 (CVSS 4.3, CWE-340): generation of predictable identifiers. An authenticated attacker can upload files with content of their choosing to a disk location that is known in advance.
- CVE-2026-111357 (CVSS 8.8, CWE-306): missing authentication for a critical function, which lets an attacker with local access elevate privileges. This was the privilege escalation bug that had no fix when the attacks came to light in mid-October.
Chained together, the 3 flaws give an attacker with no credentials the ability to run commands as root on the appliance.
How the attack worked
According to Volexity’s analysis, the first signs of exploitation appeared on October 3 against an ICS appliance running 22.8R2.4, which was the latest release at the time. Volexity began investigating on October 5.
The attacker first bypassed authentication with requests to /dana-na/auth/url_default/welcome.cgi, a public script that serves the VPN login page. Those requests carried an X-DSCGI-PATH header naming a different, protected script. The appliance used the URL to decide whether the request was allowed, but used the header to decide which script to run. That mismatch let an unauthenticated request reach CGI scripts that normally require a login.
The attacker then abused the upload handler wu.cgi. It submitted a Perl script with a .zip extension. The handler writes the upload to /home/runtime/tmp/ under the MD5 hash of the supplied filename, and only then checks whether the file is a valid ZIP and deletes it. Because the attacker knows the filename, it knows exactly where the file lands. It sent parallel requests through the same header trick to execute the script before wu.cgi deleted it. That race condition gave code execution as the low-privileged web process. The predictable, known disk location matches Ivanti’s description of CVE-2026-118527.
The final step, CVE-2026-111357, abused how the dsinvoked broker, which runs maintenance tasks as root on demand, trusts configuration data in DSCache, a shared ICS configuration store. The attacker patched the in-memory copy of the Ivanti library libdsplibs.so inside the CGI server process so it could modify DSCache, reconfigured an existing maintenance task to launch the Perl interpreter, and then asked dsinvoked to run that task with a malicious script. The result was command execution as root. The exploit code then restored the library to its original state.
No web shell, and logs were tampered with
One detail makes this campaign harder to catch than past Ivanti incidents. Volexity found no web shell or persistent backdoor on the appliance. The attacker ran commands directly through the exploit chain each time it needed access. For every command, the full exploit chain ran again and the output came back in the HTTP response. The exploit code also deleted log entries tied to the exploitation from the Ivanti debug log (/home/runtime/dlogs/debuglog) and the Linux audit.log.
CISA warns that Ivanti’s Integrity Checker Tool may not detect exploitation because the attacker’s commands execute in memory. Organizations that want to know if they were hit need network and memory forensics, not just a clean integrity scan.
What the attacker did after getting root
Once on the appliance, UTA0576 focused on credentials and Active Directory secrets. Volexity documented the following activity:
- Extracting credentials stored on the VPN appliance, such as domain credentials used with LDAP.
- Dumping and exfiltrating limited Active Directory metadata.
- Deploying a custom Kerberos tool capable of Kerberoasting and credential testing.
- Deploying a custom Python LDAP tool that used a compromised Active Directory service account to search for LAPS local administrator passwords, BitLocker recovery keys and password-bearing attributes.
- Collecting the appliance configuration, including its authentication methods.
- Password spraying and inspecting authentication logs to find valid usernames.
- Capturing LDAP traffic with a copy of
tcpdumprenamed to/data/.icscap/dsstatmond, using rotating capture files that overwrote older data.
CISA’s alert describes the same pattern: credential theft and data exfiltration following remote, unauthenticated command execution.
Who is UTA0576?
Volexity has not tied UTA0576 to any known group. It assesses with low confidence that the actor is criminally motivated rather than an espionage group, a notable call given that most past Ivanti zero-day campaigns were attributed to China-linked espionage actors. Volexity also assesses with medium confidence that UTA0576 uses large language models (LLMs) for exploit development and post-exploitation activity.
Volexity first saw exploitation on October 3, but threat intelligence firm Defused reported decoy hits it believes targeted CVE-2026-104935 starting October 1, before the bug was public.
Why October patches were not enough
Ivanti says part of the vulnerability was found through its own product security program and fixed in version 25.1.3.0, released in July. The attacks happened while that fix was still being brought to other supported releases. When Ivanti learned of the attacks, its fix for CVE-2026-104935 was already in quality assurance. Ivanti chose to ship it without waiting for a privilege escalation fix because it closed the main entry point.
That decision left 2 links of the chain open until October 29. Because the authentication bypass was the only unauthenticated step, patching it in October did block the full chain from the internet. But appliances compromised before patching, or reachable by an attacker with valid credentials, remained exposed to the upload and privilege escalation bugs.
Affected and fixed versions
CISA lists the following affected versions:
- Ivanti Connect Secure 25.1.1.2 and prior
- Ivanti Connect Secure 25.1.2.2 and prior
- Ivanti Connect Secure 22.8R2.5 and prior
The fixes for all 3 vulnerabilities are in 25.1.1.3 and 22.8R2.6. Rapid7 notes that 25.1.3.0 and later on ISA4500, ISA6500 and ISA8500 appliances are not affected. Ivanti Connect Secure 22.8 reaches end of life on January 31, 2027, so organizations still on that branch should plan their move to 25.x now. Ivanti’s 25.x Upgrade and Migration Compatibility Guide covers hardware and virtual deployments.
CISA deadlines
CISA’s KEV catalog gives federal civilian agencies until November 2, 2026 to remediate CVE-2026-111357 and until November 13, 2026 for CVE-2026-118527. CVE-2026-104935 has been in the catalog since October 13 with a remediation date of October 16. CISA announced the 2 additions on October 30.
How to hunt for exploitation
Volexity’s write-up includes indicators and detection guidance. Key points for defenders:
- Look for requests to
welcome.cgiwhere theX-DSCGI-PATHheader does not match the requested URL. Legitimate traffic should not produce that mismatch. - Review requests that reach
wu.cgiwithout a normal authenticated session, and bursts of parallel requests pointing at/home/runtime/tmp/. - Look for unexpected files or directories such as
/data/.icscap/. - Check for gaps or edits in the appliance debug log and
audit.log, especially around early October. - On the internal network, look for LDAP queries from the VPN appliance’s service account that pull LAPS passwords or BitLocker recovery keys, plus Kerberos ticket requests and password spraying from the appliance’s IP.
- Capture memory from the appliance if compromise is suspected. Disk-based checks may come back clean.
What to do if you run Ivanti Connect Secure
Upgrade to 25.1.1.3 or 22.8R2.6 or later right away, even if you already applied the October fix. If you suspect a compromise, CISA recommends the Ivanti Connect Secure recovery procedure:
- Back up the appliance configuration.
- Factory reset the appliance and upgrade it to the latest version. For cloud and virtual systems, rebuild the instance and upgrade.
- Restore the configuration from the backup.
- Reset passwords for all accounts, including domain, administrator and local accounts. Revoke and reissue stored certificates, and reset stored API keys and license server credentials.
Because the attacker targeted LDAP credentials, Kerberos tickets, LAPS passwords and BitLocker keys, a compromised appliance should be treated as a compromise of the connected Active Directory. Rotate the LDAP bind account, LAPS passwords and BitLocker recovery keys, not only the VPN’s own accounts.
A familiar target
Edge VPN and firewall appliances remain a favorite entry point because they sit on the internet, hold credentials for internal systems and often lack endpoint monitoring. BreachNews has tracked a run of similar attacks this year, including the Cisco ASA and FTD zero-day, the Check Point VPN zero-day added to KEV and Qilin attacks exploiting a PAN-OS VPN bypass.
The Ivanti chain shows why patching only the bug in the headline is not always enough. When a vendor ships a partial fix for an exploited chain, defenders should assume the remaining links are still live and watch for the follow-up advisory.
