CVE-2026-111357 Ivanti Connect Secure: The 13 October Patch Leaves a Chain to Root Open, Move to 25.1.1.3 or 22.8R2.6

Direct answer: The 13 October 2026 Ivanti Connect Secure patch closes only 1 of the 3 flaws that attackers chain. Versions 22.8R2.5 and 25.1.1.2 are still vulnerable to CVE-2026-111357 and CVE-2026-118527. CISA added those 2 CVEs to the KEV catalog on 30 October 2026. Today, check the version, move to 25.1.1.3 or 22.8R2.6, then look for signs of attack.

According to the Volexity report, this chain of 3 flaws gives an attacker code execution as root with no login. The attacker used that access to take Active Directory credentials, LAPS passwords, and BitLocker keys.

Main condition: No CVE in this chain has a score of 9 or more. We still write this warning because attackers already use the chain and it ends at root. Limit: This article has no request content, no payload, and no attack sequence.

We read the Ivanti advisory 000109571, the Ivanti recovery steps 000097080, the Volexity report, CISA KEV, the CVE-2026-104935 record, the CVE-2026-111357 record, and NVD on 1 November 2026, from 06.35 to 07.30 WIB. We ran the scripts of steps 1, 4, and 5 in a podman container with the official nginx 1.29 image on the same date. We do not have an Ivanti appliance, so we wrote the admin console steps from the Ivanti documentation.

The problem: the 13 October patch closes 1 of 3 flaws

Teams that installed the 13 October patch and stopped there still have an appliance that attackers can take over to root.

According to the Volexity report, the attacker that Volexity names UTA0576 started attacks on 3 October 2026. The target was ICS 22.8R2.4 build 19097, the latest version at that time. Ivanti released the CVE-2026-104935 fix on 13 October, and CISA added that CVE to CISA KEV on the same day.

The fix for the 2 other flaws came only on 29 October 2026, in versions 25.1.1.3 and 22.8R2.6. CISA added CVE-2026-111357 and CVE-2026-118527 to KEV on 30 October. The CISA deadline for US federal agencies is 2 November for CVE-2026-111357 and 13 November for CVE-2026-118527.

Ivanti writes that its own security program found part of this flaw and fixed it in 25.1.3.0 in July 2026. The backport to the other lines was not complete when the attacks started.

How it works: 3 flaws in 1 chain

One flaw opens access with no login, and 2 other flaws raise that access to root.

This section uses the official summary. Its purpose is to help you choose the correct steps, not to explain an attack.

Summary from Ivanti and Volexity

According to the Ivanti advisory 000109571, CVE-2026-104935 is an authentication bypass by spoofing (CWE-290). A remote attacker with no login can run commands. CVE-2026-111357 is missing authentication for a critical function (CWE-306). A local attacker who is logged in can raise privileges. CVE-2026-118527 is the use of predictable file names (CWE-340). An attacker who is logged in can upload files to a known place on disk.

The Volexity report says that an ICS background service that runs as root trusts shared configuration data. The attacker changes that data in memory, then asks the service to run a command as root. After that, the attacker restores the data and removes part of the logs.

Scores from each source

The score is different for each source, so write the score with its source.

CVE	Ivanti score	CVE record and NVD	CISA KEV
CVE-2026-104935	CVSS 3.0 8.6	8.6, from Ivanti as the CNA	Added 13 October 2026
CVE-2026-111357	CVSS 3.1 8.8, scope changed	7.0 from MITRE as the CNA, NVD Analyzed	Added 30 October 2026
CVE-2026-118527	CVSS 3.0 4.3	CVE record not yet published on 1 November 2026	Added 30 October 2026

Exploitation status on 1 November 2026

Ivanti writes that attackers used this chain against a limited number of customers. CISA KEV lists these 3 CVEs as flaws already used in attacks. The CISA alert of 13 October asks organisations to apply the fix and check their appliances.

Rama Digital analysis: the score of each CVE misleads you when you read it alone. The 4.3 score of CVE-2026-118527 looks minor, but that flaw is part of a chain to root. Use the KEV status to set the priority, not a single score.

Who has the highest risk

Companies that use Ivanti Connect Secure as the VPN for remote work, and that connect it to Active Directory, have the highest risk.

This table summarises the Ivanti advisory 000109571 and the Volexity report.

Appliance condition	Risk	Reason
Patched on 13 October (22.8R2.5 or 25.1.1.2)	High	CVE-2026-111357 and CVE-2026-118527 are still open
Not patched since before 13 October	Highest	The full chain with no login is still open
Connected to Active Directory through LDAP	Extra impact	Volexity: the attacker read LAPS passwords, BitLocker keys, and password attributes
LDAP service account with wide rights	Extra impact	This account becomes the door to AD data
Relies only on the Integrity Checker Tool (ICT)	Missed signs	Volexity: the ICT did not find this chain, because the changes are only in memory
Line 22.7R2.x or 25.1.3.x	Low	Ivanti: these lines do not contain these flaws

A VPN appliance sits at the edge of the network and holds domain credentials. So one appliance that an attacker takes over can open the whole office network. The same pattern shows in the GitLab CVE-2026-97229 flaw that is also on KEV: a system open to the internet is the first target.

Vulnerable and safe versions

Use this table of lines, because the 13 October patch and the 29 October patch use version numbers that are close together.

Installed line or version	Status on 1 November 2026	Move to
22.7R2.14 and older	Not affected	Stay, then move to 25.1 before 31 January 2027
22.8R2.4 and older	Vulnerable to 3 CVEs	22.8R2.6 or 25.1.1.3
22.8R2.5 (13 October patch)	Vulnerable to CVE-2026-111357 and CVE-2026-118527	22.8R2.6 or 25.1.1.3
25.1.1.1 and older (ISA6000, ISA8000)	Vulnerable to 3 CVEs	25.1.1.3
25.1.1.2 (13 October patch)	Vulnerable to CVE-2026-111357 and CVE-2026-118527	25.1.1.3
25.1.2.2 and older (ISA4500, ISA6500, ISA8500)	Vulnerable to CVE-2026-104935	25.1.3.0 or 25.1.3.1
25.1.3.0 and newer	Does not contain these flaws	Stay on the latest version

The table data comes from the Ivanti advisory 000109571, update of 29 October 2026. Ivanti recommends 25.1.1.3 for 22.8 users. Users who cannot move to 25.1 yet can install 22.8R2.6 first. Support for the 22.7 and 22.8 lines ends on 31 January 2027.

A move to 25.1.3.0 needs the new ISA4500, ISA6500, or ISA8500 platform. VM and cloud users must build a new appliance from the 25.1.3.0 template. Read the Ivanti 25.x upgrade and migration guide before you choose a path.

Before you start

• Admin access to the Ivanti Connect Secure console of each appliance, including cluster nodes and standby appliances.
• An Ivanti License System (ILS) account to download the 25.1.1.3 or 22.8R2.6 package.
• A maintenance window. The upgrade ends active VPN sessions.
• Access to the logs of the reverse proxy, WAF, load balancer, and firewall in front of the appliance, if you have them.
• Access to a domain controller for step 5, or a contact in the Active Directory team.

Step 1: Check the version of each appliance

Open the admin console, then open System > Status > Overview. Write down the software version and the build number of each appliance.

For many appliances, save this script as check-version-ics.sh. The script compares each version with the Ivanti advisory table and prints the target version. The script does not contact the appliance.

#!/usr/bin/env bash
# Check an Ivanti Connect Secure version against CVE-2026-104935, CVE-2026-111357, and CVE-2026-118527.
# Data: Ivanti advisory 000109571, update of 29 October 2026.
# Use: bash check-version-ics.sh "22.8R2.5" "25.1.1.2"   or   bash check-version-ics.sh < versions.txt
# Copy the version from the admin console: System > Status > Overview.

check() {
  local raw="$1" v
  # Remove extra text such as "ICS" and "(build 19097)".
  v=$(printf '%s' "$raw" | sed -E 's/\(.*\)//; s/[Ii][Cc][Ss]//g; s/[[:space:]]//g')
  [ -z "$v" ] && return
  local status next=""
  if [[ $v =~ ^22\.([0-9]+)R([0-9]+)(\.([0-9]+))?$ ]]; then
    local minor=${BASH_REMATCH[1]} r=${BASH_REMATCH[2]} p=${BASH_REMATCH[4]:-0}
    if (( minor < 7 )); then
      status="NOT AFFECTED by these 3 CVEs, check the support status of line 22.$minor with Ivanti"
    elif (( minor == 7 )); then
      status="NOT AFFECTED (support for 22.7 ends on 31 Jan 2027)"
    elif (( minor > 8 )); then
      status="UNKNOWN"
    elif (( r < 2 || (r == 2 && p <= 4) )); then
      status="VULNERABLE to 3 CVEs"; next="22.8R2.6 or 25.1.1.3"
    elif (( r == 2 && p == 5 )); then
      status="VULNERABLE to CVE-2026-111357 and CVE-2026-118527"; next="22.8R2.6 or 25.1.1.3"
    else
      status="SAFE from these 3 CVEs (plan 25.1 before 31 Jan 2027)"
    fi
  elif [[ $v =~ ^25\.1\.([0-9]+)\.([0-9]+)$ ]]; then
    local b=${BASH_REMATCH[1]} p=${BASH_REMATCH[2]}
    if (( b < 1 || (b == 1 && p <= 1) )); then
      status="VULNERABLE to 3 CVEs"; next="25.1.1.3"
    elif (( b == 1 && p == 2 )); then
      status="VULNERABLE to CVE-2026-111357 and CVE-2026-118527"; next="25.1.1.3"
    elif (( b == 1 )); then
      status="SAFE from these 3 CVEs"
    elif (( b == 2 )); then
      status="VULNERABLE to CVE-2026-104935"; next="25.1.3.0 or 25.1.3.1 (ISA4500, ISA6500, ISA8500)"
    else
      status="SAFE from these 3 CVEs"
    fi
  elif [[ $v =~ ^(9\.|2[0-1]\.) ]]; then
    status="NOT AFFECTED by these 3 CVEs, check the support status of this line with Ivanti"
  else
    status="UNKNOWN"
  fi
  [ "$status" = "UNKNOWN" ] && status="UNKNOWN, compare it with the Ivanti advisory by hand"
  printf '%-22s %s\n' "$raw" "$status"
  [ -n "$next" ] && printf '%-22s -> move to %s\n' "" "$next"
  return 0
}

if (( $# > 0 )); then
  for x in "$@"; do check "$x"; done
else
  while IFS= read -r line; do check "$line"; done
fi

# One version per line, copied from the admin console of each appliance
nano versions.txt
bash check-version-ics.sh < versions.txt
# Or pass them as arguments
bash check-version-ics.sh "22.8R2.5" "25.1.1.2"

Check the result: "VULNERABLE to 3 CVEs" means the appliance does not have the 13 October patch. Do steps 2, 3, and 5 today. "VULNERABLE to CVE-2026-111357 and CVE-2026-118527" means the 13 October patch is in, but the 29 October upgrade is not. "SAFE" still means do step 5, because the attacks started on 3 October.

Step 2: Back up the configuration before the upgrade

A configuration backup lets you roll back the upgrade, and you need the same copy if step 5 finds a sign.

1. Export the system configuration and the user configuration from Maintenance > Import/Export.
2. Keep the export files off the appliance, with a name that holds the date and the version.
3. If you use an Archiving Server, also make a binary backup as Ivanti KB44759 describes.
4. Write down the certificates, APIAPIThe official door 2 systems use to exchange data, without anybody copying it by hand.Open the glossary keys, and local accounts that the appliance holds. Step 5 needs this list.

Check the result: the export files are off the appliance, and their size is not 0 bytes.

Step 3: Upgrade to 25.1.1.3, 22.8R2.6, or 25.1.3.x

Only an Ivanti upgrade closes CVE-2026-111357 and CVE-2026-118527.

1. Download the package from ILS. Choose 25.1.1.3 for 25.1.1 and 22.8, or 22.8R2.6 if you cannot move to 25.1 yet.
2. Open Maintenance > System > Upgrade/Downgrade, upload the package, then run the upgrade.
3. For a cluster, upgrade one node at a time as the Ivanti 25.x upgrade and migration guide describes.
4. For 25.1.2.x, move to 25.1.3.0 or 25.1.3.1 on the ISA4500, ISA6500, or ISA8500 platform.
5. After the reboot, open System > Status > Overview again and run check-version-ics.sh with the new version.
6. Run the internal and external Integrity Checker Tool as Ivanti describes. Remember the limit: a clean result does not prove a clean appliance.

Check the result: the script prints "SAFE from these 3 CVEs" for each appliance, including standby nodes.

Step 4: Apply a temporary mitigation until the upgrade is done

This step reduces the chance and the impact of an attack, but it does not close the flaw.

Rama Digital analysis: Ivanti published no workaround for the 2 new flaws. We built 3 steps from the Volexity report and common practice. Condition: the upgrade cannot run today. Limit: attackers can find other paths, so these steps do not replace the upgrade.

4a. Refuse the X-DSCGI-PATH header at the reverse proxy or WAF

Volexity recommends that you monitor the X-DSCGI-PATH header on requests to the login page. The appliance uses this header inside itself, so normal VPN clients do not send it. This rule works only if your proxy opens TLS before it forwards the traffic.

# 1. In the http block: a log format that records the X-DSCGI-PATH header.
log_format ics_cek '$remote_addr - [$time_local] "$request" $status dscgi="$http_x_dscgi_path"';

# 2. In the server block that forwards traffic to Ivanti Connect Secure.
access_log /var/log/nginx/ics-access.log ics_cek;

# Refuse requests from the internet that carry this internal header.
if ($http_x_dscgi_path) {
    return 403;
}

sudo nginx -t && sudo systemctl reload nginx
U=https://vpn.your-company.com/dana-na/auth/url_default/welcome.cgi
curl -s -o /dev/null -w '%{http_code}\n' "$U"                          # must be 200
curl -s -o /dev/null -w '%{http_code}\n' -H 'X-DSCGI-PATH: tes' "$U"   # must be 403

On another WAF, make the same rule: refuse a request from the internet when the X-DSCGI-PATH header is present. Test the VPN login with 1 test account after the rule is active.

4b. Reduce the rights of the LDAP service account

The service account that the appliance uses for LDAP needs only read access to users and groups. Remove the right to read LAPS attributes and BitLocker recovery objects from this account, then change its password after the upgrade.

4c. Close the admin console to the internet

Open the admin console only from the management network or from admin IP addresses. This step does not close the chain, but it removes other ways in.

Check the result: a request with the test header gets 403, a normal VPN login still works, and the LDAP service account cannot read LAPS attributes.

Step 5: Look for signs that the appliance was touched

An upgrade does not cancel credentials that attackers already took, so check the logs in front of the appliance and in Active Directory.

Save this script as check-log-ics.sh. The script counts requests to the login page per IP, looks for the X-DSCGI-PATH header, and looks for the IOC address from Volexity.

#!/usr/bin/env bash
# Look for signs of the CVE-2026-104935 chain in reverse proxy, WAF, or firewall logs in front of Ivanti Connect Secure.
# Source of the signs: Volexity, 13 October 2026. Use: bash check-log-ics.sh /var/log/nginx/ics-access.log [firewall-log]
[ $# -eq 0 ] && { echo "Use: bash check-log-ics.sh LOG [LOG ...]"; exit 1; }
sign=0

echo "== 1. Requests to welcome.cgi per IP (top 5)"
grep -h 'welcome.cgi' "$@" | awk '{print $1}' | sort | uniq -c | sort -rn | head -5
n=$(grep -h 'welcome.cgi' "$@" | wc -l)
echo "Total: $n requests"

echo "== 2. Requests with the X-DSCGI-PATH header"
hdr=$(grep -h -i -E 'dscgi="[^"-]|x-dscgi-path' "$@" | grep -v 'dscgi=""' || true)
if [ -n "$hdr" ]; then
  printf '%s\n' "$hdr" | head -5
  echo "Count: $(printf '%s\n' "$hdr" | wc -l) lines"
  sign=1
else
  echo "None"
fi

echo "== 3. IOC address from Volexity (108.165.147.64)"
ioc=$(grep -h -F '108.165.147.64' "$@" || true)
if [ -n "$ioc" ]; then printf '%s\n' "$ioc" | head -5; sign=1; else echo "None"; fi

if (( sign )); then
  echo "Result: SIGNS FOUND. Keep this log and follow the Ivanti recovery steps."
else
  echo "Result: no signs in this log. A clean log does not prove a clean appliance."
fi

sudo bash check-log-ics.sh /var/log/nginx/ics-access.log /var/log/firewall-outbound.log
# Logs from another WAF or load balancer: export them to a text file first, then run the same script.

Then check a domain controller. This PowerShell command counts failed logons and Kerberos tickets from the internal IP of the VPN appliance. We did not run this command, because it needs a real Active Directory.

# Run on a domain controller, in PowerShell as an admin.
$vpnIp = 'REPLACE-WITH-THE-VPN-INTERNAL-IP'
$since = (Get-Date).AddDays(-30)
# Failed logons (4625) and failed Kerberos pre-authentication (4771) from the VPN IP
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4625, 4771; StartTime = $since } |
  Where-Object { $_.Message -like "*$vpnIp*" } | Measure-Object
# Kerberos service ticket requests (4769) from the VPN IP
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4769; StartTime = $since } |
  Where-Object { $_.Message -like "*$vpnIp*" } | Measure-Object

If Active Directory object access auditing is on, also look for event 4662 from the VPN service account on LAPS and BitLocker attributes. Volexity also recorded connections to 108.165.147[.]64 and missing parts of the debug log.

Check the result: 0 header lines, 0 connections to the IOC, and no spike of events 4625, 4771, or 4769 from the VPN IP. If you find even 1 sign, follow the Ivanti recovery steps 000097080: back up the configuration, do a factory reset or rebuild the VM, upgrade, then restore. Revoke and reissue the certificates, then reset the admin password, API keys, local users, and service accounts. Also change the LAPS passwords and plan new BitLocker recovery passwords.

If credentials or personal data leaked and you operate in Indonesia, Indonesian Law 27/2022 on Personal Data Protection requires a written notice within 3 times 24 hours. Also read the Linux kernel TCP flaw CVE-2026-98432 and the Magento PolyShell flaw CVE-2026-48356.

Example: 1 morning of response for 2 appliances

This simulation uses dummy data. The appliance names, times, and results are not customer data.

Time (WIB)	Dummy appliance	Checked	Result	Action
07.00	vpn-hq (22.8R2.5, 2-node cluster)	Step 1	VULNERABLE to 2 CVEs	Step 4a this morning, upgrade to 22.8R2.6 tonight
07.30	vpn-branch (25.1.1.2)	Steps 1 and 2	VULNERABLE to 2 CVEs, backup stored	Upgrade to 25.1.1.3 at 12.00
09.00	vpn-hq	Step 5	38 requests with the header from 1 IP on 9 October	Incident response, factory reset, reset the LDAP service account
11.00	Active Directory	Step 5	Spike of event 4769 from the vpn-hq IP	Change the LAPS and service account passwords

Lesson from the simulation: the 13 October patch does not prove a clean appliance. Vpn-hq was patched, but step 5 still found signs from before the patch.

Who applies the patch

The patch owner depends on how you run the appliance, so this table helps you know who acts today.

How you run it	Patch owner	What you do
ISA appliance in your own office	Your IT team	Steps 1 to 5
VM on VMware, Hyper-V, or cloud	Your IT team	Steps 1 to 5, and a snapshot before the upgrade
Managed by a partner or MSP	The partner, as the contract says	Ask for written version proof and the step 5 results
Ivanti Neurons for Secure Access	Ivanti for the cloud console, your team for the gateway	Check the gateway version, then step 5

Rama Digital recommendation: treat the VPN appliance as an asset with the highest patch priority, equal to a domain server.

Checklist for today

1. List every Ivanti Connect Secure appliance, including standby nodes. Owner: IT team. Proof: a list of names and versions.
2. Check the version with step 1. Owner: network admin. Proof: script output.
3. Back up the configuration with step 2. Owner: network admin. Proof: the export files.
4. Apply step 4 on each appliance that cannot upgrade today. Owner: network admin. Proof: the 403 test.
5. Upgrade to 25.1.1.3, 22.8R2.6, or 25.1.3.x. Owner: network admin. Proof: script output after the upgrade.
6. Look for signs with step 5. Owner: network admin and the Active Directory team. Proof: script output and events.
7. Change the LDAP service account password after the upgrade, even with no signs.

Frequently asked questions

I installed the 13 October patch. Is my appliance safe?

Not yet. Versions 22.8R2.5 and 25.1.1.2 close only CVE-2026-104935. Move to 22.8R2.6 or 25.1.1.3 to close CVE-2026-111357 and CVE-2026-118527.

Why does this article use the KEV status, not the CVSS score?

The highest score in this chain is 8.8. But attackers already use these 3 flaws together to reach root. The KEV status shows real attacks, so it is a better basis for the priority.

My Integrity Checker Tool result is clean. Is my appliance clean?

Not always. Volexity writes that the ICT did not find this chain, because the attacker changed memory and then restored it. Do step 5 and check Active Directory.

Is Ivanti Connect Secure 22.7 affected?

No. Ivanti writes that 22.7.X and lower versions do not contain these flaws. Support for 22.7 ends on 31 January 2027, so plan a move to 25.1.

My appliance has no reverse proxy in front of it. What do I do?

Step 4a does not apply to you. Upgrade sooner, apply steps 4b and 4c, then do the Active Directory checks in step 5.

Does the upgrade remove the attacker's access?

The upgrade closes the flaws. It does not cancel credentials that the attacker already took. Change the service account, admin, and LAPS passwords and the certificates if you find signs.

Who is behind these attacks?

Volexity names the actor UTA0576 and assesses, with low confidence, a criminal motive. The fix steps are the same for any actor.

Next step

The limits that still apply: the step 4 mitigation does not close the flaw, and an upgrade does not cancel credentials that attackers already took. When your appliance shows a sign in step 5, or you need help with an audit and recovery, use Vibe Code Rescue. For 1 urgent issue today, book a 30-minute session.

Sources

• Ivanti advisory 000109571: summary of the 3 flaws, Ivanti scores, CWE, affected versions, safe versions, and FAQ.
• Ivanti recovery steps 000097080: recovery steps for an appliance under attack.
• Ivanti 25.x upgrade and migration guide: upgrade and migration paths to 25.x.
• Volexity report: attack timeline, post-exploitation, ICT limits, and monitoring advice.
• CISA KEV: CVE-2026-104935 added on 13 October, CVE-2026-111357 and CVE-2026-118527 added on 30 October 2026.
• CISA alert of 13 October: patch warning for CVE-2026-104935.
• CVE-2026-104935 record, CVE-2026-111357 record, and NVD: CNA scores and analysis status.
• Indonesian Law 27/2022 on Personal Data Protection: the duty to report a personal data leak.