Ivanti Connect Secure Zero-Day Chain: Root Without Login, Patch to This Build

Ivanti Connect Secure is under attack via a chain of three vulnerabilities (CVE-2026-104935, CVE-2026-118527, CVE-2026-111357) that allows attackers to execute commands as root without logging in. All three have entered the CISA KEV catalog, and the patch deadline for US federal agencies fell yesterday, November 2, 2026. If your office uses Ivanti VPN, this is today's priority.

What really happened?

On October 13, 2026 Ivanti released an advisory for CVE-2026-104935, an authentication bypass by spoofing (CWE-290) vulnerability with a CVSS v3 score of 8.6. The same day, CISA listed it in its Known Exploited Vulnerabilities (KEV) catalog and Volexity published a report on attacks they had discovered since early October.

The problem is, the first gap is only the entrance. Volexity saw the attacker, which they labeled UTA0576, combine three vulnerabilities together to gain root access on a device that was thought to be patched at the time (version 22.8R2.4). The remaining two vulnerabilities only received emergency updates from Ivanti on October 29, then CISA added CVE-2026-111357 and CVE-2026-118527 to KEV on October 30 with a November 2 deadline.

Ivanti Connect Secure (formerly Pulse Secure) is widely used as a VPN gateway in government agencies, state-owned companies, banks and large companies, including in Indonesia. According to scanning data quoted by SecurityOnline, there are more than 10,000 devices visible on the public internet. ITdaily lists a more conservative figure, a minimum of 5,500 instances.

How does the attack chain work?

The order is something like this:

1. Sign in without an account. CVE-2026-104935 allows attackers to spoof data that the system uses to verify identity. As a result, commands can be executed remotely without authentication, with user rights cgi-server.
2. Put files in predictable locations. CVE-2026-118527 (CVSS 4.3) is a predictable file name issue, allowing malicious files to be placed in known locations.
3. Go up to the root. CVE-2026-111357 (CWE-829) arises because broker dsinvoked places too much trust in DSCache configuration data. Local attackers can use it to climb to the root.

After becoming root, according to the Volexity report summarized by The Hacker News, the attacker steals credentials stored on the device, including LDAP domain credentials, searches the Active Directory for passwords, then password sprays the internal network.

What makes this case slippery: the exploit simply changes the library code in memory, then reverts the changed configuration to its original state. No webshell or backdoor is left behind. Attackers even rerun the entire chain for each command.

Summary of three CVEs

Note: SecurityOnline lists CVE-2026-111357's score as 8.8 in the body of the article, but 7.0 in its table. The CVE record in OpenCVE/NVD uses 7.0 with local vectors ( AV:L/AC:H/PR:L). The unit score doesn't really matter here, because what's dangerous is the combination: from no access to root.

Who is affected and which versions are safe?

Those affected are Ivanti Connect Secure (ICS). The details are a bit convoluted as the patch came out in two waves:

• CVE-2026-104935 affects 25.1.1.1 and earlier, 25.1.2.2 and earlier, and 22.8R2.4 and earlier. The first wave of improvements are at 25.1.1.2, 25.1.3.0/25.1.3.1, and 22.8R2.5.
• CVE-2026-111357 and CVE-2026-118527 according to SecurityOnline affect 25.1.1.2 and earlier, and 22.8R2.5 and earlier. This means that the first wave of builds is not enough.
• Secure version for the entire chain, based on the Canadian Center for Cyber ​​Security advisory update (AV26-1035, update October 30): 25.1.1.3, 25.1.3.1, or 22.8R2.6.
• Series 22.7.x and below are said to be unaffected by CVE-2026-104935. But 22.7 and 22.8 will end of support on January 31, 2027, so plan a migration to 25.1.

Sources don't completely agree on a fixed build list (SecurityOnline itself displays three different lists). Before rollout, match the build number with Ivanti's official advisory on the Ivanti Hub portal.

When did it all happen?

Note the gap: about 10 days between the first attack and the advisory, then more than two weeks until the full chain was patched. During that break, devices that are "updated" can still be hacked to the point of rooting.

How do I check if my device is vulnerable?

ICS is an appliance, so there is no regular shell to run commands. The surest way:

1. Log in to the admin console, view the version in Maintenance → Platform or in the admin page header.
2. Compare with the table above. If it is below 25.1.1.3, 25.1.3.1, or 22.8R2.6, consider it vulnerable.
3. If the device has been running on a vulnerable version since early October, assume it may have been compromised and proceed to detection.

How to detect signs of attack?

Ivanti itself stated that reliable indicators of compromise were not yet available. Volexity publishes several indicators, and here's what you can hunt for in the logs passed to syslog/SIEM:

• /dana-na/auth/url_default/welcome.cgi large quantity request.
• HTTP X-DSCGI-PATH header whose value does not match the URL path.
• Directory /data/.icscap/ (visible via forensics).
• IP Address 108.165.147[.]64.

Example of searching in a log that has been exported to a Linux server:

# Hitung permintaan ke welcome.cgi per alamat IP (ganti path log sesuai SIEM/syslog Anda)
grep -h "/dana-na/auth/url_default/welcome.cgi" /var/log/ivanti/*.log \
  | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -rn | head -20

# Cari IP penyerang yang dilaporkan Volexity
grep -rn "108.165.147.64" /var/log/ivanti/ /var/log/nginx/ 2>/dev/null

# Bila ada reverse proxy/WAF yang mencatat header, cari header mencurigakan
grep -rni "x-dscgi-path" /var/log/ 2>/dev/null | head

For IDS, this simple Suricata rule flags unusual headers coming from outside. Adjust $HOME_NET and sid to your environment:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Kemungkinan eksploitasi Ivanti ICS - header X-DSCGI-PATH"; flow:to_server,established; http.header_names; content:"X-DSCGI-PATH"; nocase; classtype:attempted-admin; sid:9100001; rev:1;)

Since attackers steal LDAP credentials and then perform password spraying, also check the domain controller. Many failed logins (Event ID 4625 or 4771) from the VPN appliance IP address is a red signal:

# Jalankan di domain controller: login gagal 7 hari terakhir, dikelompokkan per IP sumber
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625,4771; StartTime=(Get-Date).AddDays(-7)} |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'IpAddress' } |
  Group-Object '#text' | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

One important caveat from Volexity: net results from the Integrity Checker Tool (ICT) are not proof of a secure device, because modifications occur in memory. Confirmation of compromise requires network and memory forensics.

What are the mitigation steps?

1. Patch now to 25.1.1.3, 25.1.3.1, or 22.8R2.6, outside of the regular patch schedule.
2. Hurry up for the above indicators to be withdrawn until at least early October 2026.
3. Rotate credentials stored on the appliance: LDAP/AD bind accounts, local admin accounts, and certificates when there are indications of compromise.
4. Restrict the admin interface to only be accessible from the management network, not the internet.
5. If there are any signs of compromise, isolate the device and follow Ivanti's recovery steps (factory reset then install a clean build), rather than simply upgrading on top of a compromised system.
6. Monitor AD for password spraying and unusual logins from service accounts.

This “crack edge device then steal credentials” pattern also appeared in other cases this month, such as RCE GitLab CVE-2026-97229 and PHP2Shell. If your team manages Linux servers, also check for the Linux kernel TCP vulnerability CVE-2026-98432.

FAQs

Is 22.8R2.5 safe?

Not yet for the entire chain. 22.8R2.5 covers CVE-2026-104935, but CVE-2026-111357 and CVE-2026-118527 still affect 22.8R2.5 and below. Rises to 22.8R2.6.

I've run the Integrity Checker Tool and the results are clean. Enough?

No. Volexity reports ICT does not catch this chain because the exploit works in memory and restores the configuration. Combine with log analysis, network forensics, and memory.

CISA deadlines are for US institutions only. What is its relevance for Indonesia?

The deadline is binding on US federal agencies, but KEV status means exploitation has been confirmed. The attacker does not select a country; Ivanti devices exposed to the internet in Indonesia are just as vulnerable.

Is there a temporary solution if you can't upgrade yet?

The sources we read did not mention an official workaround. The best temporary measure is to limit access to the VPN portal (e.g. only from certain IP ranges), tighten monitoring, and schedule upgrades as soon as possible.

Who did it?

Volexity tracked it as UTA0576 and assessed, with low confidence, the motive was criminal rather than espionage. Ivanti said the exploitation was limited to a small number of customers.

Source

• SecurityOnline: Ivanti Connect Secure vulnerability exploited (Oct 30, 2026)
• The Hacker News: Attacker chains three Ivanti Connect Secure zero-days
• Rapid7: Ivanti Connect Secure zero-day exploited in the wild (CVE-2026-104935)
• Canadian Center for Cyber ​​Security: Ivanti security advisory AV26-1035
• OpenCVE: CVE-2026-111357
• CSA Singapore: Alert AL-2026-147
• ITdaily: Ivanti patches flaw in Connect Secure