I’M UNDER A CYBER ATTACK

Alert

Alert 2026-133 An actively exploited chain of zero-day vulnerabilities in Ivanti Connect Secure enables remote execution as root without authentication

Affected product(s): 

ProductAffected versionsFixed version
Ivanti Connect Secure, 25.1.1.x branch and earlier25.1.1.2 and earlier (CVE-2026-104935: 25.1.1.1 and earlier)25.1.1.3
Ivanti Connect Secure, 25.1.2.x and 25.1.3.x branches25.1.2.2 and earlier (CVE-2026-104935)25.1.3.1
Ivanti Connect Secure, 22.8 branch22.8R2.5 and earlier (CVE-2026-104935: 22.8R2.4 and earlier)22.8R2.6

Versions 22.7R2.14 and earlier are not affected by CVE-2026-104935, and neither Ivanti Policy Secure nor Neurons for ZTA gateways have been reported as affected.

Description

An actively exploited chain of vulnerabilities has been reported in Ivanti Connect Secure, Ivanti’s SSL VPN solution, allowing a remote attacker without credentials to execute commands as root on the device. The chain combines three vulnerabilities, designated as CVE-2026-104935, CVE-2026-111357 and CVE-2026-118527, which are listed in the Known Exploited Vulnerabilities (KEV) catalog of the U.S. cybersecurity agency. Individually, none exceeds High severity; chained together, they provide full control of the device, so this advisory is rated CRITICAL.

CVETypeCVSS v3.1FixKEV inclusion
CVE-2026-104935Authentication bypass via spoofing that allows commands to be executed without authentication8.613/10/202613/10/2026
CVE-2026-111357Privilege escalation to root (dsinvoked service and DSCache configuration data)8.8 according to the vendor (7.0 according to NVD)29/10/202630/10/2026
CVE-2026-118527Generation of predictable identifiers that allows files with attacker-controlled content to be uploaded to a known path on disk4.329/10/202630/10/2026

Researchers indicate that an unidentified threat actor has been exploiting the chain since 03/10/2026 and attribute the activity, with low confidence, to criminal motives. The first compromised device analyzed had the latest available version installed at that time (22.8R2.4). The vendor stated that it is aware of exploitation against a limited number of customers, and a government source considers continued exploitation highly likely.

The chain works in three steps:

  • The attacker sends requests to the public login page (/dana-na/auth/url_default/welcome.cgi) with an X-DSCGI-PATH header pointing to another internal script. The device decides whether to allow the request based on the URL, but routes it according to the header, which provides access to protected scripts without authentication.
  • Through the wu.cgi upload handler, the attacker uploads a file that is written to a predictable path before validation and executes it by exploiting a race condition. This provides code execution as the web server user.
  • Finally, the attacker modifies in memory the configuration data trusted by the privileged dsinvoked service so that a maintenance task executes the attacker’s script as root, after which everything is restored to its original state.

The vendor fixed CVE-2026-104935 on 13/10, but that fix did not cover the privilege escalation, which was resolved on 29/10 together with CVE-2026-118527. A device patched only with the 13/10 fix on the 25.1.1.x (25.1.1.2) or 22.8 (22.8R2.5) branches remains exposed to escalation to root. The U.S. cybersecurity agency set a deadline of 16/10/2026 for CVE-2026-104935 and 02/11/2026 for CVE-2026-111357, both subject to mandatory forensic triage, and 13/11/2026 for CVE-2026-118527.

The attacker does not install webshells or backdoors: the entire chain is repeated for each command, and the results are received in the HTTPS response itself. According to researchers, once inside, the attacker:

  • Extracted credentials stored on the device, such as the domain credentials it uses for LDAP.
  • Used the Active Directory service account configured in the VPN to search for local administrator passwords (LAPS), BitLocker recovery keys and password attributes (userPassword, unixUserPassword).
  • Used a custom tool for Kerberoasting and credential testing, and conducted password spraying against Active Directory accounts.
  • Captured traffic from the device to obtain plaintext credentials and NTLM hashes, and reviewed authentication logs to identify valid users.
  • Collected device configuration and Active Directory metadata, and performed DNS and local reconnaissance.
  • Selectively deleted entries from the debug and audit logs, and deleted their own files.

Because the changes occur only in memory and the configuration is restored, the vendor’s integrity verification tool (Integrity Checker Tool, ICT) may fail to detect the compromise. No public exploit or use of this chain in ransomware campaigns has been reported.

Mitigation

As general recommendations, while the update is being applied and on devices that were exposed:

  • Block 108.165.147[.]64 and search for historical connections to that IP address.
  • Monitor the volume of requests to welcome.cgi with the X-DSCGI-PATH header and inspect the device’s /tmp/ directory.
  • Do not consider a clean ICT result sufficient: confirming or ruling out the compromise requires forensic analysis of memory and network traffic.
  • Minimize the privileges of the Active Directory service account used by the VPN and review its LDAP queries involving the ms-Mcs-AdmPwd, msLAPS-Password and msFVE-RecoveryInformation attributes.
  • In Active Directory, review bulk requests for service tickets using RC4 (Kerberoasting), large numbers of failed authentication attempts originating from the VPN device’s internal IP address, and attempts at lateral movement from that device.
  • Preserve the evidence (memory and disk images, memory dumps and logs) before rebooting or updating a suspicious device.

Indicators of compromise

The vendor stated that the available indicators of compromise are limited. Researchers published the following:

Network

  • IP address used for exploitation: 108.165.147[.]64.
  • A high volume of requests to /dana-na/auth/url_default/welcome.cgi with headers such as X-DSCGI-PATH: /home/webserver/htdocs/dana/fb/smb/wu.cgi or X-DSCGI-PATH: /home/runtime/tmp/<MD5(filename)>.
  • Any discrepancy between the URL path and the value of X-DSCGI-PATH, as other paths could be used.
  • Connections originating from the VPN device to domain controllers or other internal systems, and password spraying from its internal IP address.

Files and paths on the device

  • /tmp/ml.py, /tmp/rq5.py, /tmp/mk.py, /tmp/rr.py, /tmp/pu.txt, /tmp/sp_out.txt, /tmp/spray_hits.json, sp_run.py and JSON files compressed with zlib and encoded in Base64 in /tmp/.
  • Hidden directory /data/.icscap/ (/home/root/data/.icscap/) containing the dsstatmond executable (a renamed tcpdump), rotating captures cap0 through cap7 and the h.py script, executed using /home/venv3/bin/python3.6.
  • /home/runtime/tmp/ics-root-run-inband-*.pl and /home/runtime/tmp/ics-root-result-inband-*.
  • Memory dumps (core dumps) generated during exploitation.

Processes and configuration

  • dsstatmond process capturing LDAP, HTTP, FTP and telnet traffic from a hidden directory.
  • DSCache entry ScriptUtil/updateOpswatSDK pointing to a program other than /home/bin/updateOpswatSDK.pl.
  • Gaps or recent truncations in /home/runtime/dlogs/debuglog and /var/log/audit/audit.log.

Hash (SHA-256)

  • Python implementation of the privilege escalation exploit: 25b95f47359c327e3a5ae5ac5cd147f8d9afd98092faf136822ee287e25e3dc8

Researchers also published YARA rules to detect the request headers in files or memory (exploit_log_ivanti_rce) and the Python exploit (exploit_py_ivanti_oct26).

Solution

The solution is to update each device to the fixed version for its branch:

  • 25.1.1.x branch: 25.1.1.3.
  • 25.1.2.x and 25.1.3.x branches: 25.1.3.1 (25.1.3.0 fixes CVE-2026-104935, but 25.1.3.1 is recommended).
  • 22.8 branch: 22.8R2.6.

Devices that only received the 13/10 fix must be updated again. The 22.8 branch reaches end of life on 31/01/2027, and the vendor recommends migrating to the 25.x branch.

If a compromise is suspected, follow the recovery procedure outlined by the U.S. cybersecurity agency:

  1. Back up the device configuration.
  2. Reset the device to factory settings and update it to the fixed version. On virtual devices or in the cloud, rebuild the instance.
  3. Restore the configuration from the backup.
  4. Reset the passwords for all accounts (domain, administrator and local), revoke and reissue the stored certificates, and reset the API keys and license server credentials.

Additionally, if the compromise is confirmed, rotate the Active Directory and LDAP service account configured in the VPN, the LAPS passwords and BitLocker recovery keys that may have been queried, and review the rest of the network for lateral movement.

For information on how to update, visit the following link:

https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935

Additional information: