What happened

On October 30, 2026, CISA added two Ivanti Connect Secure (ICS) vulnerabilities to its Known Exploited Vulnerabilities catalog: CVE-2026-111357, a missing authentication for a critical function flaw that lets a local authenticated attacker escalate privileges (CVSS 8.8), and CVE-2026-118527, a use of predictable filenames flaw that lets a remote authenticated attacker upload files with attacker-controlled content to a known location on disk (CVSS 4.3).

According to Ivanti's advisory, exploitation in the wild affected a limited number of customers when these two were chained with CVE-2026-104935, an authentication bypass by spoofing (CVSS 8.6) that allows a remote unauthenticated attacker to execute arbitrary commands. CVE-2026-104935 was added to KEV on October 13. Volexity, which found the activity, described the combined chain as unauthenticated root-level code execution. Ivanti updated its advisory on October 29 when fixes for the two additional flaws shipped.

Volexity reported that the actor it tracks as UTA0576 did not mainly deploy web shells or malware. Instead it extracted credentials and limited Active Directory metadata, performed host reconnaissance, and searched for administrator passwords and BitLocker recovery keys.

Federal agencies must remediate CVE-2026-111357 by November 2, 2026 and CVE-2026-118527 by November 13, 2026, according to reporting based on CISA's catalog entry.

Why it matters

A VPN gateway is a trusted, internet-facing device that sits next to your identity infrastructure. Root on that device means access to whatever it can see: session data, service account credentials, LDAP bind accounts and internal network paths. Because the activity described by Volexity leaned on credential theft instead of persistent malware, a clean-looking filesystem is not proof of a clean device.

The chain also shows why the severity of a single CVE can mislead. A 4.3 rated file upload bug and a local privilege escalation are easy to deprioritize alone. Combined with an unauthenticated entry point, they become the path to root.

What defenders should check

  • Version. According to Ivanti, CVE-2026-104935 affects ICS 25.1.1.1 and prior, 25.1.2.2 and prior, and 22.8R2.4 and prior, and does not affect 22.7R2.14 or prior. CVE-2026-111357 and CVE-2026-118527 affect 25.1.1.2 and prior and 22.8R2.5 and prior.
  • Fixed builds. Ivanti lists 25.1.1.3 and 22.8R2.6 as resolving all three. Builds 25.1.3.0 and later (ISA4500, ISA6500, ISA8500) do not contain CVE-2026-104935. Moving to 25.1.3.0 requires the new platform.
  • Lifecycle. Ivanti states that 22.7 and 22.8 reach end of life on January 31, 2027, so plan the move to the 25.1 line.
  • Exposure. Inventory every ICS appliance, including forgotten test or regional units, and note how long each was internet facing while unpatched.
  • Logs. Pull appliance logs and upstream firewall and proxy logs for the exposure window before any rebuild or upgrade overwrites evidence.

Detection ideas

The following are starting points to adapt and test in your environment. They are not production-ready detections.

Find exposure from the outside, scoped to your own organization:

Shodan: http.title:"Ivanti Connect Secure" org:"<your org>"
Censys: services.http.response.html_title: "Ivanti Connect Secure" and autonomous_system.name: "<your org>"

Because the reported objective included BitLocker recovery keys and AD data, review directory activity from accounts the appliance uses (Microsoft Defender for Identity or Sentinel example):

IdentityDirectoryEvents
| where Timestamp > ago(30d)
| where AdditionalFields has "msFVE-RecoveryInformation"
| summarize count(), min(Timestamp), max(Timestamp) by AccountName, DeviceName
| order by count_ desc

For bind and service accounts used by the VPN, look for logons that do not match the appliance address or normal hours:

SecurityEvent
| where EventID == 4624
| where Account in~ ("<vpn_bind_account>", "<vpn_service_account>")
| where IpAddress !in ("<appliance_ip_1>", "<appliance_ip_2>")
| project TimeGenerated, Account, IpAddress, LogonType, Computer

Also review the Volexity indicators referenced in Ivanti's advisory and match them against your proxy and firewall telemetry.

Investigation

If an appliance was exposed and unpatched during the exploitation window, assume compromise until you can show otherwise.

  1. Preserve first. Take a snapshot or forensic image of virtual appliances and export logs before patching or rebuilding.
  2. Run Ivanti's Integrity Checker Tool and compare results with a known good state. Ivanti notes that public indicators are limited, so a pass is not a guarantee.
  3. Follow Ivanti's published recovery steps if you suspect exploitation.
  4. Review identity systems: which accounts did the appliance use, and what did they authenticate to or read after the exposure window opened? Include LDAP queries, BitLocker recovery key reads and administrator logons.
  5. Look for lateral movement from the appliance's internal address, including SMB, RDP and WinRM connections to servers and domain controllers.
  6. Scope credential exposure broadly: VPN users who logged in during the window, service accounts, certificates and any secrets stored on the device.

Mitigation

  • Upgrade to 25.1.1.3 or 22.8R2.6, which Ivanti lists as resolving all three. 25.1.3.0 and later do not contain CVE-2026-104935, but check Ivanti's advisory for the exact fixed build for the other two CVEs before relying on it.
  • After patching, rotate credentials that the appliance held or that passed through it, and reset exposed administrator passwords.
  • Restrict who and what can read BitLocker recovery information in AD.
  • Restrict the management interface to a dedicated network and monitor the appliance's outbound connections.
  • Schedule regular integrity checks, not only after advisories.

If you want a second pair of eyes on an edge device, our compromise assessment and incident response services can help scope exposure and review evidence.