A previously unknown threat actor tracked as UTA0576 chained three Ivanti Connect Secure zero-day vulnerabilities to run code as root on VPN appliances without logging in. The attacks began in early October 2026 and hit at least one appliance that was fully patched at the time. Ivanti says exploitation has affected a limited number of customers.
The fix arrived in two stages. Ivanti patched the authentication bypass, CVE-2026-104935, on October 13, then shipped fixes for the remaining two flaws, CVE-2026-111357 and CVE-2026-118527, on October 29.
CISA has added all three vulnerabilities to its Known Exploited Vulnerabilities catalog, and the federal deadline for the privilege escalation bug falls today, November 2.
How the Three Flaws Combine Into Unauthenticated Root
Researchers uncovered the chain while investigating suspicious activity at a customer network on October 5 and traced it to an Ivanti Connect Secure (ICS) appliance running 22.8R2.4. Attack analysis describes three stages:
- Authentication bypass in welcome.cgi: The appliance checks the requested URL path against its public login script, while a separate request header decides which CGI handler actually runs. The mismatch lets an unauthenticated request reach protected handlers
- File write in wu.cgi: An upload handler stores incoming content at a predictable path on disk before validating it. The attacker abuses the short window before the file is rejected and deleted to execute it, with later stages running only in memory
- Privilege escalation through dsinvoked: A root-level service that runs maintenance tasks trusts program paths stored in the DSCache configuration store. By altering one cached entry, the attacker gets that service to run a script as root
Ivanti’s advisory details the vulnerabilities involved in the exploit chain, ranging from initial access to full root privilege escalation:
- CVE-2026-104935 (CVSS 8.6): Authentication bypass by spoofing; a remote, unauthenticated attacker can run arbitrary commands.
- CVE-2026-118527 (CVSS 4.3): Generation of predictable numbers or identifiers; a remote authenticated attacker can upload attacker-controlled content to a known location.
- CVE-2026-111357 (CVSS 8.8): Missing authentication for a critical function; a local authenticated attacker can escalate privileges.
Why Did Ivanti’s First Patch Leave Appliances Exposed?
Ivanti had a fix for CVE-2026-104935 in quality assurance when exploitation came to light. The company chose to release it on October 13 rather than wait for the privilege escalation fix, since closing the authentication bypass shut down the primary exploitation path.
Ivanti also says it had found part of the escalation issue through its own product security program and fixed it in the July release 25.1.3.0. It was still backporting that fix to other supported branches when UTA0576 began exploiting it.
As a result, the 25.1.1.2 and 22.8R2.5 releases fixed CVE-2026-104935 but remained affected by the other two flaws until October 29. Teams that patched on October 13 and stopped there need to upgrade again.
Which Ivanti Connect Secure Versions Are Affected?
The advisory names only Ivanti Connect Secure. Based on the updated advisory as of October 29, 2026:
| Vulnerability | Affected Versions | Fixed Versions |
|---|---|---|
| CVE-2026-104935 | 25.1.1.1 and prior; 25.1.2.2 and prior; 22.8R2.4 and prior | 25.1.1.2; 25.1.3.0 and 25.1.3.1; 22.8R2.5 |
| CVE-2026-111357 and CVE-2026-118527 | 25.1.1.2 and prior; 22.8R2.5 and prior | 25.1.1.3; 22.8R2.6 |
Ivanti says its newest releases address every vulnerability used in the chain.
What UTA0576 Did After Gaining Root
UTA0576 used root access to gather credentials and prepare for deeper access to the victim’s Active Directory (AD) environment. Volexity observed the actor:
- Harvesting credentials: Extracted the domain credentials the appliance uses for LDAP and parsed appliance logs for usernames
- Querying Active Directory: Used a custom Python LDAP tool and the appliance’s AD service account to search for LAPS passwords, BitLocker recovery information, password attributes and account metadata
- Capturing LDAP traffic: Ran a renamed packet capture utility, disguised as dsstatmond, and a parser that pulls plaintext LDAP and HTTP Basic credentials and NTLM challenge-response material
- Testing credentials: Used a custom Kerberos tool to validate credentials, along with a password spraying script
- Collecting configuration: Exfiltrated appliance configuration data and DNS settings, then resolved internal domains
Threat analysts note that the LDAP searches targeted BitLocker keys and LAPS passwords but do not state that the actor obtained or used them. With high confidence, it is assessed that the activity was preparation for lateral movement.
The actor left no web shell, backdoor or first-stage malware. Each command re-ran the full exploit chain and returned its output in the HTTP response, so the exploit itself served as the command channel. The packet capture process was still running when security teams examined the device.
Why a Clean Integrity Check Proves Nothing Here
UTA0576 worked to leave few traces. The exploit patched library code only in memory, never on disk, and restored the modified DSCache entry once the root command finished. The actor also removed entries from Ivanti debug logs and the Linux audit log, deleted its payloads and temporary tools, and sent command output to /dev/null.
Because of this, Ivanti’s Integrity Checker Tool (ICT) reported no modifications on the compromised appliance. CISA has also warned that the tool may miss this activity. A clean ICT result is not evidence that an appliance is safe; memory and network forensics are needed to rule out compromise.
Who Is UTA0576?
UTA0576 is an actor with no known links to a named group. It is assessed with low confidence that the actor is criminally motivated rather than espionage-driven, citing the target and the hosting provider behind its infrastructure.
Researchers also assess with medium confidence that the actor used large language models to develop the exploit and post-exploitation tooling, pointing to the command channel design, scripts with hardcoded credentials and the chain’s complexity.
A similar LDAP capture technique previously appeared in UTA0533 activity against SonicWall SMA devices.
Timeline of Exploitation, Fixes and KEV Deadlines
| Date (2026) | Event |
|---|---|
| October 1 | Another research team first observes related activity on honeypots and customer instances |
| October 3 | Earliest exploitation of the investigated appliance |
| October 5 | Incident responders begin investigating with Ivanti |
| October 13 | Initial research findings are published; Ivanti releases the CVE-2026-104935 fix; CISA adds CVE-2026-104935 to KEV |
| October 16 | Federal deadline to fix CVE-2026-104935 and perform forensic triage |
| October 29 | Ivanti updates its advisory with fixes for CVE-2026-111357 and CVE-2026-118527 |
| October 30 | CISA adds CVE-2026-111357 and CVE-2026-118527 to KEV |
| November 2 | Federal deadline for CVE-2026-111357 |
| November 13 | Federal deadline for CVE-2026-118527 |
The KEV deadlines formally bind U.S. Federal Civilian Executive Branch agencies. For everyone else, three KEV entries on one internet-facing gateway are a strong signal to treat the upgrade as an emergency change.
Where to Look for Signs of UTA0576
Volexity published indicators of compromise alongside its report. Its guidance and observed artifacts point defenders to these checks:
- Web request patterns: Large volumes of requests to /dana-na/auth/url_default/welcome.cgi, especially where the URL path does not match the CGI path set in the X-DSCGI-PATH header; the attackers are expected to vary the header values
- Network indicator: Connections with 108.165.147[.]64, the VPS that hosted the attacker’s OpenVPN server between September 30 and October 7
- File artifacts: Unexpected Python scripts and compressed output files in /tmp, a hidden /data/.icscap directory, and files matching /home/runtime/tmp/ics-root-*
- Process artifacts: A process named dsstatmond capturing network traffic
- Log gaps: Missing time ranges in /home/runtime/dlogs/debuglog or /var/log/audit/audit.log, which may reflect the actor’s cleanup
- Active Directory telemetry: Unusual LDAP queries for LAPS, BitLocker or password attributes from the appliance’s service account, plus Kerberos authentication tests and password spraying sourced from the appliance
No hits in logs is not proof of a clean device, given the log tampering documented in the investigation. Hunting should extend back to at least October 1, 2026.
What ICS Owners Should Do Now
- Upgrade to 25.1.1.3, 22.8R2.6 or a later release; 25.1.1.2 and 22.8R2.5 are not enough
- Run the ICT, but treat a clean result as inconclusive and pair it with memory and network forensics on any appliance exposed since October 1
- If there is any sign of compromise, follow Ivanti’s recovery steps: back up the configuration, factory reset and upgrade the appliance (rebuild virtual and cloud instances), then restore the configuration
- After a confirmed or suspected compromise, reset domain, administrator and local account passwords, including the appliance’s AD service account; revoke and reissue stored certificates; and reset API keys and license server credentials
- Review AD for use of the exposed credentials, and rotate any LAPS passwords and BitLocker recovery keys that the appliance’s service account could read
Keep Exposed Ivanti Gateways in View With SOCRadar
A staged patch like this one leaves a gap: appliances patched on October 13 look fixed but remain exploitable. Closing it starts with knowing every ICS instance the organization exposes.
- SOCRadar’s Attack Surface Management discovers internet-facing assets, such as Ivanti gateways, including forgotten or third-party-managed ones, so teams can confirm each runs 25.1.1.3, 22.8R2.6 or later.
- Cyber Threat Intelligence tracks CVE-2026-104935, CVE-2026-111357 and CVE-2026-118527 as advisories, KEV entries and exploit reporting change.
- Dark Web Monitoring can flag stolen VPN access or corporate credentials offered in underground markets.
Confirming whether a specific appliance was compromised still requires forensic review of its own memory and logs.
Source: SOCRadar · 2026-11-02
