Ivanti Connect Secure: 3 CVEs Chained in Attacks, CVE-2026-104935

I happened to see Ivanti's announcement on 13 Oct. 2026 that Connect Secure, an SSL VPN many organizations use to give employees access to internal networks, had a vulnerability, CVE-2026-104935, that was already being exploited. I kept reading through the announcements on 29 and 30 Oct., when two more vulnerabilities followed, and put them together in one post because all three were used in a single chain. Reading each CVE separately misses why one round of patches was not enough.

What happened

The main source is Volexity's blog about an incident it found in early Oct., which says the attackers began targeting appliances considered fully patched on 3 Oct. The attack chain has 3 steps.

1. Bypass login The welcome.cgi script is publicly accessible, but adding a header named X-DSCGI-PATH makes the system forward the request to a CGI that should be protected. Access checks use the URL, while the actual destination is set by the header.
2. Run commands The upload handler wu.cgi writes a file to disk before checking whether it is actually a ZIP, naming the file using the MD5 of the filename supplied by the user. A Perl file disguised as a .zip therefore remains on disk briefly before being deleted. The attackers send parallel requests to execute that file during this window.
3. Escalate to root Through the dsinvoked service and DSCache, which run as root.

What makes this hard to detect is that Volexity found no web shell or backdoor at all. Commands and their output traveled back and forth in the attackers' own HTTPS requests, and the later-stage code ran in memory. After gaining access, the attackers extracted passwords stored on the appliance, such as a domain LDAP account, used that account to query Active Directory for LAPS passwords and BitLocker recovery keys, ran tcpdump renamed to dsstatmond in the hidden folder .icscap, and deleted or truncated logs to cover their tracks. Volexity assessed this as preparation to move to other machines on the network. The operation was detected and stopped before that happened, so the attackers' ultimate objective could not be determined.

Severity

CISA lists the ransomware status of all three as "Unknown", while CISA's SSVC data in all three CVE records lists exploitation as active.

The point to watch is that CVE-2026-118527 has a CVSS score of only 4.3, rated Medium. If you prioritize work by score alone, it will end up at the back of the queue. But it is in KEV because it is part of an actual attack chain. The scores for the individual steps therefore underestimate the overall damage.

Who is affected, and which versions are fixed

I found conflicting version information across sources, so I have separated it below.

The practical conclusion is to upgrade to 25.1.1.3, 25.1.3.1 or 22.8R2.6 or later, depending on the branch you use. This matches the Canadian Cyber Centre advisory and covers the CVE records for the 22.8 branch, since 22.8R2.5 fixes only the first vulnerability. There is one clear discrepancy between the two sources: the CVE record for CVE-2026-104935 says it affects versions "before 25.1.3.0" and does not list 25.1.1.x as fixed, while the Canadian Cyber Centre uses 25.1.1.3 as the threshold for that branch. If you are on 25.1.1.x, I recommend moving to 25.1.3.1, where the information is clearer, then checking Ivanti's advisory page again. Volexity confirmed attacks on appliances running 22.8R2.4 that were considered fully patched at the time. Ivanti's original advisory page requires browser rendering, and I could not read its actual contents. The version numbers above therefore come from the CVE records and government agencies citing the advisory. Check the versions against Ivanti's page again before installing.

How to fix it

1. Check the version Read the version and build from the appliance's admin page and compare them with the table above.
2. Install a new build Upgrade to a version that fixes all three vulnerabilities, even if you already applied the 13 Oct. patches.
3. Preserve evidence before rebooting If you suspect an incident, because some traces are in memory.
4. Search historical network logs Look for requests matching the patterns in the next section.
5. Change passwords stored on the appliance Especially the account the VPN uses to bind to LDAP/AD.

If you have several appliances, record the version numbers you read in a spreadsheet and compare them against the target version for the same branch using sort -V to avoid mistakes from reading the numbers yourself (this example is only for the 25.1.x branch; 22.8R2.x contains letters, so compare the trailing numbers by eye).

cur=25.1.1.2; min=25.1.1.3
if [ "$(printf '%s\n' "$min" "$cur" | sort -V | head -n1)" = "$min" ]; then
  echo "OK $cur"
else
  echo "ต้องอัปเดต $cur ต่ำกว่า $min"
fi

Item 5 in the list is my own recommendation, not something Volexity explicitly advised. But since the attackers did extract passwords stored on the appliance, changing those passwords is something you should do. First check what the service account the VPN uses to bind can read in AD.

# ต้องมีโมดูล ActiveDirectory (RSAT) บนเครื่องที่รัน
# บัญชีสมมติชื่อ svc-vpn-ldap ดูว่าอยู่กลุ่มอะไร ควรมีสิทธิ์อ่านเท่าที่จำเป็นเท่านั้น
Get-ADPrincipalGroupMembership -Identity svc-vpn-ldap | Select-Object Name

# เปลี่ยนรหัสผ่านบัญชี service (จะถามรหัสใหม่ตอนรัน) แล้วอย่าลืมแก้ค่าบนตัว VPN ให้ตรงกัน
Set-ADAccountPassword -Identity svc-vpn-ldap -Reset -NewPassword (Read-Host -AsSecureString 'new password')

Check whether you have been compromised

Volexity provides 3 things to look for and maintains an IOC list on its GitHub.

• Large numbers of requests to /dana-na/auth/url_default/welcome.cgi with the X-DSCGI-PATH header pointing to wu.cgi or a path under /home/runtime/tmp/. If you have a tool that can compare the URL with the header value, alert when the two do not match.
• Unusual files in /tmp/, such as LDAP/Kerberos scripts, JSON output and packet capture files.
• A process or file named dsstatmond and the hidden folder .icscap.

# log ที่ export จาก WAF / reverse proxy / SIEM (ต้องเป็น log ที่บันทึก request header ไว้)
zgrep -i 'x-dscgi-path' /srv/logs/edge/*.log* | grep -i 'welcome.cgi' | head -n 50

# snapshot หรือ diagnostic bundle ที่แตกไว้ในเครื่องวิเคราะห์ (ไม่ใช่บน appliance)
grep -rIl -e 'dsstatmond' -e '.icscap' /srv/forensics/ics-snapshot/ 2>/dev/null
find /srv/forensics/ics-snapshot \( -name '.icscap' -o -name 'dsstatmond' \) -print

Having no logs that retain headers does not mean you are safe; it means there is no evidence to examine. Volexity says to use memory and network forensics on suspected appliances and to treat them as compromised if internal network activity is found to have originated from the VPN. For servers behind the VPN, you can continue investigating using the Debian server security scan guide.

As for a factory reset, I could not find readable guidance from Ivanti, so I will not say whether one is required. Check Ivanti's advisory page yourself.

Personally, if your Connect Secure appliance is internet-facing, I would not wait for the maintenance window. I would install the new build outside the regular schedule and then look for traces, because the first vulnerability requires no login and has been confirmed in KEV since 13 Oct. Whether to treat the appliance as compromised depends on the evidence at each site. But if it was left on an older version during early through late Oct. and there is no evidence to examine, I would change the passwords stored on it first, as staffing allows at each site.

P.S. In CISA's KEV file, the forensic triage field is Yes for CVE-2026-104935 and CVE-2026-111357 but No for CVE-2026-118527, while BOD 26-04 requirements appear in all three entries. Anyone outside US federal agencies can still use them as guidance.

Sources: CVE record for CVE-2026-104935 (https://www.cve.org/CVERecord?id=CVE-2026-104935), CVE-2026-111357 (https://www.cve.org/CVERecord?id=CVE-2026-111357), CVE-2026-118527 (https://www.cve.org/CVERecord?id=CVE-2026-118527), CISA KEV (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), Volexity "A Series of Unauthenticated Events" (https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/), Canadian Centre for Cyber Security AV26-1035 (https://cyber.gc.ca/en/alerts-advisories/ivanti-security-advisory-av26-1035), Cyber Security Agency of Singapore AL-2026-147 (https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-147/) I could not read the contents of the Ivanti advisory page cited by the CVE records (https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935). Information current as of 5 Nov. 2026. If more details emerge or Ivanti corrects the version information, I will come back and update this post.