What Happened
In October 2026, Volexity documented an exploit chain against Ivanti Connect Secure (ICS) used by a previously undocumented threat actor tracked as UTA0576. The chain combined an authentication bypass (CVE-2026-104935, CVSS 8.6), a remote code execution step, and a local privilege escalation (CVE-2026-111357, CVSS 8.8) to achieve unauthenticated, root-level code execution on the appliance. The file-upload flaw, CVE-2026-118527 (CVSS 4.3), allowed an authenticated attacker to place files at a known location on disk and was part of the same chain.
The operator's behavior is noteworthy. Instead of deploying web shells or malware, UTA0576 extracted credentials and limited Active Directory metadata, performed host reconnaissance, and searched for administrator passwords and BitLocker recovery keys. This quiet, intelligence-gathering approach is harder to detect than noisy malware deployment.
CISA added CVE-2026-111357 and CVE-2026-118527 to its Known Exploited Vulnerabilities (KEV) catalog after confirming exploitation in the wild.
Timeline
- July 2026: Ivanti discovers part of the vulnerability through its product security program and patches it in release 25.1.3.0. It begins backporting the fix to other supported versions.
- October 2026 (early): Volexity publishes details of the exploit chain, documenting weaponization alongside the authentication bypass. Ivanti has a fix for CVE-2026-104935 in QA but is still developing a fix for the privilege escalation flaw.
- October 13, 2026: CISA adds CVE-2026-104935 to the KEV catalog.
- October 31, 2026: CISA adds CVE-2026-111357 and CVE-2026-118527 to the KEV catalog. Patches are available in ICS 25.1.1.3 and 22.8R2.6.
- November 2, 2026: Federal Civilian Executive Branch agencies must remediate CVE-2026-111357.
- November 13, 2026: Remediation deadline for CVE-2026-118527.
Note the gap between the July fix in one release train and exploitation against supported versions that hadn't yet received the backport. That window is where the attacker operated.
Which Controls Failed or Were Missing
This section maps control gaps that the chain exposes in typical enterprise deployments, not findings against a named organization.
1. Version-train exposure. The fix existed in one release (25.1.3.0) while other supported versions waited on backports. Organizations running older trains were exposed to a flaw the vendor had already acknowledged internally. Any team that tracked only "latest version" advisories, and not its own train's status, had a blind spot.
2. Internet-facing appliance with root-reachable privilege path. A remote access gateway sits at the trust boundary. Once the authentication bypass fell, nothing downstream limited what a code-execution foothold could reach. The privilege escalation step turned an appliance compromise into full control of a device that handles credentials.
3. Credential and secret exposure on the gateway. The attacker's targets, administrator passwords and BitLocker recovery keys, indicate that sensitive material was reachable from the compromised host or its adjacent directory data. Secrets within reach of a perimeter device amplify every appliance-level flaw.
4. Detection tuned for malware, not for quiet collection. Behavior limited to credential extraction, directory metadata queries, and host reconnaissance doesn't trip controls built around web shell and payload signatures.
5. Partial disclosure sequencing. Ivanti chose to ship the fix for the primary exploitation path rather than delay for the privilege escalation fix. That's a defensible call, but it meant customers who patched the first flaw could still sit exposed to the remaining links until the second round of patches arrived.
What the Relevant Standard Requires
NIST CSF Core Functions. Four map directly:
- Identify (asset management and risk assessment): You can't prioritize a patch for an appliance you haven't inventoried with its exact version train. Vulnerability identification and threat intelligence intake belong here.
- Protect (platform security, protective technology): Limiting what a compromised perimeter device can reach, and restricting where recovery keys and admin credentials are stored, falls under protective controls.
- Detect (continuous monitoring, adverse event analysis): Monitoring needs to cover credential access and directory queries originating from infrastructure devices, not only endpoint malware.
- Respond and Recover: Having a pre-defined path for emergency patching and credential rotation when an appliance is confirmed exploited.
KEV-driven prioritization. CISA's catalog is a reliable trigger. Federal agencies work to its remediation dates, and private organizations can adopt the same logic: confirmed exploitation moves a vulnerability ahead of anything ranked solely by CVSS. This chain illustrates why. The lowest-scored flaw (CVSS 4.3) was a working link in a root-level compromise.
NIS2 and similar regimes. Entities in scope under the Network and Information Security Directive (NIS2) are expected to maintain vulnerability handling and disclosure processes and to manage supply chain security, which includes your vendors' patch cadence. An appliance vendor's backport schedule is a supply chain risk input.
Insurance considerations. Underwriting Questionnaires commonly ask about patching cadence for internet-facing systems, and an Application Fraud Warranty can attach to those answers. If you represent that critical external-facing patches land within a stated window, your actual record on KEV-listed flaws should support it.
Lessons and Action Items for Your Team
Inventory by version train, not product name. Record the exact ICS build for every gateway and map it to the vendor's fixed release in that train. Here, that means 25.1.1.3 and 22.8R2.6 for the affected trains.
Make KEV listing an escalation trigger. Define in policy that a KEV addition for a perimeter device starts an emergency change process with a fixed remediation window, independent of CVSS.
Patch the chain, not the headline CVE. When a vendor releases a fix for one link, ask directly whether other links remain open, and treat the device as exposed until all are closed.
Ask your vendors about backport status. Add a standing question to vendor management: when a fix ships in one release, what's the schedule for every supported train you run?
Hunt for quiet collection. Build detections for credential access, unusual directory queries, and recovery key lookups from gateway devices. Use published threat intelligence on actor behavior to shape those queries.
Rotate after exposure. If an appliance in your environment was running an affected version while exploitation was active, assume credentials and directory data it could reach are compromised. Rotate administrator credentials and review where BitLocker recovery keys are stored and who can read them.
Shrink what the gateway can reach. Segment appliances so a root shell on the device doesn't hand over directory-wide visibility or privileged credentials.
Align your insurance representations. Check that your Underwriting Questionnaire answers on patching match what your change records show, and confirm your First Notice of Loss process covers an appliance-originated intrusion.
The lesson from this chain is structural. Three flaws of mixed severity, patched on different schedules across different release trains, added up to root access without a password. Your defense depends less on any single patch than on how fast you can see which links are still open.
