Ivanti Connect Secure CVE-2026-111357 and CVE-2026-118527 finish a root exploit chain; here's how to check and patch your clients' Ivanti VPNs.
If your clients' Ivanti VPNs got the October 13 patch, the job looked done. It wasn't: on October 30, CISA added two more Ivanti Connect Secure flaws to its list of exploited bugs, and with the first one they take an attacker from an anonymous web request to root on the appliance.
Think of a burglar with three keys. Changing the front-door lock helped, but the back door and the safe still opened on the old key ring.
Attackers chained three Ivanti Connect Secure bugs to go from an unauthenticated web request to root on the VPN appliance, and since October 30, 2026 all three are in CISA's Known Exploited Vulnerabilities (KEV) catalog.
According to The Hacker News, Volexity found the attack on one customer's appliance running 22.8R2.4, fully patched at the time, with exploitation starting on October 3, 2026. On October 13, Ivanti said it was aware of "limited exploitation in the wild" and told customers to "act immediately". That update closed the front door but left the root link open. Cyber Press reports that Ivanti updated its advisory on October 29 to name all three CVEs.
The three links, in the order an attacker uses them:
welcome.cgi, but ran whichever script the X-DSCGI-PATH header named.CISA gave federal agencies until November 2 to act on CVE-2026-111357, and Ivanti has given no victim count.
Ivanti's Integrity Checker Tool (ICT) may not detect this exploitation because the attacker's commands run in memory, CISA warns.
According to Cyber Press, Volexity found no web shell. The attacker reran the whole chain with each command it sent, restored the memory and configuration data it changed, and cleaned out debug and audit logs. A clean ICT scan only means the burglar wiped the fingerprints.
The evidence that survives sits where the attacker couldn't reach: the client's syslog server and domain controllers.
A client is exposed if its Ivanti Connect Secure runs 25.1.1.2 or earlier, 25.1.2.2 or earlier, or 22.8R2.5 or earlier, per CISA.
/var/log/ics with the directory that server writes the appliance's logs to. Pass: the .sha256 file lists every copied file.D=/srv/evidence/ics-$(date +%F); sudo mkdir -p "$D"
sudo cp -a /var/log/ics "$D"/
sudo find "$D" -type f -exec sha256sum {} + | sudo tee "$D.sha256"
sudo grep -rn '108\.165\.147\.64' /var/log
sudo grep -rc 'url_default/welcome.cgi' /var/log/ics
The real giveaway, an X-DSCGI-PATH header that doesn't match the URL, only shows up in a WAF, reverse proxy or decrypted packet capture in front of the appliance. An empty result does not prove the appliance is clean, and the attacker may use other IPs.
$ics set to the appliance's internal IP. It asks all domain controllers for failed logons (events 4625 and 4771) that mention that IP. Pass: no rows. It only sees what each Security log still holds.$ics = '10.0.0.5' # the appliance's internal IP
Get-ADDomainController -Filter * | ForEach-Object { Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{LogName='Security';Id=4625,4771} -ErrorAction SilentlyContinue | Where-Object { $_.Message -match [regex]::Escape($ics) } } | Group-Object Id | Select-Object Count,Name
Upgrade to a fixed build, and treat any appliance with a hit from the checks above as compromised, not just outdated.
svc-ics with the account named in the appliance's authentication server settings, then enter the new password there. The commands follow Microsoft's Set-ADAccountPassword reference. Pass: PasswordLastSet shows today's date and a test VPN login succeeds.Set-ADAccountPassword -Identity svc-ics -Reset -NewPassword (Read-Host -AsSecureString -Prompt 'New password')
Get-ADUser svc-ics -Properties PasswordLastSet | Select-Object PasswordLastSet
PasswordReset in the Status column. Legacy LAPS is not covered by this command.Get-ADComputer -Filter * | ForEach-Object { Set-LapsADPasswordExpirationTime -Identity $_.DistinguishedName }
This chain shows how fast a clean bill of health goes stale: a VPN patched on October 13 had two more exploited links named by October 30.
KinoSec runs an autonomous pentest of your clients' external networks on demand. It maps the internet-facing surface, finds appliances like Ivanti Connect Secure, flags builds inside a known-exploited range, and writes up each finding with remediation in a report you hand your client. Its Active Directory pentest follows the path this attacker was on, from one stolen service account toward domain-wide secrets.
It doesn't replace forensics. If an appliance was already hit, the checks above and an incident responder come first.
Yes. CISA added CVE-2026-104935 to its KEV catalog on October 13, 2026, and CVE-2026-111357 and CVE-2026-118527 on October 30, 2026. According to The Hacker News, Volexity saw exploitation start on October 3, 2026 against an appliance running 22.8R2.4.
Cyber Press reports the fixed builds as 25.1.1.3, or 22.8R2.6 where migration isn't possible yet. CISA lists 25.1.1.2 and prior, 25.1.2.2 and prior, and 22.8R2.5 and prior as affected, and notes that 22.8 reaches end of life on January 31, 2027.
First, open System > Status in the admin console and compare the version with CISA's affected ranges. Next, on the syslog server, run sudo grep -rn '108\.165\.147\.64' /var/log to find the IP The Hacker News lists from Volexity. Then run sudo grep -rc 'url_default/welcome.cgi' /var/log/ics and look for a sudden spike in login-page requests.
No. CISA warns that Ivanti's Integrity Checker Tool may not detect this exploitation because the attacker's commands run in memory. According to Cyber Press, Volexity found no web shell, and the attacker cleaned out debug and audit logs.
Yes. KinoSec's autonomous external network pentest finds internet-facing appliances like Ivanti Connect Secure and flags builds inside a known-exploited range, with remediation in the report. It doesn't replace forensics on an appliance that was already compromised.