Ivanti Connect Secure KEV: CISA Lists the Rest of the Chain

On October 30, 2026, CISA added CVE-2026-111357 and CVE-2026-118527 to the Ivanti Connect Secure KEV entries, completing a three-bug chain that the actor UTA0576 used to reach unauthenticated root on VPN gateways. Teams that shipped only the October 13 authentication-bypass fix may still be running code that contains the other two links, and the attacker was after identity secrets, not the appliance itself.

What did CISA add to KEV on October 30, and what was already there?

CISA added two Ivanti Connect Secure flaws to the Known Exploited Vulnerabilities catalog on Friday, October 30, 2026. Both belong to a chain whose first link was already listed. Here is the full set, with the stage each one most likely plays (our inference, explained below):

• CVE-2026-104935, CVSS 8.6: authentication bypass, the entry point. In KEV since October 13, 2026.
• CVE-2026-118527, CVSS 4.3: generation of predictable numbers or identifiers. A remote authenticated user can write a file with attacker-controlled content to a known location on disk. Likely the code-execution step (inferred). Added October 30.
• CVE-2026-111357, CVSS 8.8: missing authentication for a critical function, letting a local authenticated attacker escalate privileges. Likely the root step (inferred). Added October 30.

For U.S. Federal Civilian Executive Branch agencies, the clock is short. CVE-2026-111357 is due November 2, three days after listing. CVE-2026-118527 is due November 13. Those dates bind only FCEB agencies under Binding Operational Directive 22-01. For everyone else, KEV is a prioritization signal rather than a legal deadline. The attacker does not care which category you fall into.

A note on sourcing: the reporting comes from The Hacker News (Ravie Lakshmanan), which pulls together Volexity’s research, Ivanti’s statements and the KEV entries. It is a news synthesis, not new technical research. It names no victims, gives no campaign size and publishes no indicators. For IOCs, go to Volexity’s write-up and Ivanti’s advisory.

How does the Ivanti chain reach unauthenticated root?

Each bug supplies one capability the attacker lacks, and only the combination turns a network connection into root on the appliance. Volexity summarized it this way: “This exploit chain combined an authentication bypass, a remote code execution (RCE), and a privilege escalation vulnerability to achieve unauthenticated root-level code execution.”

First, the caveat. The reporting does not explicitly assign each CVE to a stage. Pairing CVE-2026-118527 with the upload-to-execution step and CVE-2026-111357 with escalation is our inference from the vulnerability descriptions. It fits, but treat Volexity’s and Ivanti’s documents as the authority. We will not reconstruct the mechanics beyond that.

With that stated, read it from the attacker’s chair. The authentication bypass (CVE-2026-104935) removes the need for credentials; the only precondition is that the service is reachable. The attacker is now a logged-in user with no rights worth having.

The predictable-identifier flaw (CVE-2026-118527) lets that user place content they control at a path they can predict, and a file at a known location is raw material for code execution. The privilege escalation (CVE-2026-111357) then lifts the foothold from a low-privileged process to root.

The scoring lesson is the useful part. No single flaw is rated critical; the top score is 8.8. CVSS rates vulnerabilities one at a time and was never designed to be summed into a chain score.

A 4.3 that requires authentication looks like backlog material. Paired with a bypass that hands out authentication for free, its precondition disappears and it becomes the bridge to code execution. If your triage sorts strictly by base score, this is the bug it would have deprioritized.

Ivanti has been here before. In January 2024, CVE-2023-46805 (authentication bypass) and CVE-2024-21887 (command injection) were combined for unauthenticated remote code execution on the same product line. Two bugs then, three now, same shape: a front-door bypass plus something that only looks harmless behind the login page.

Why are VPN gateways still the first door attackers try?

Because a VPN concentrator packs everything an intrusion needs into one box: internet exposure, pre-authentication code, and trust in the internal network. This chain uses all three.

• Exposed by design. The gateway exists to accept connections from anywhere. You cannot firewall it off without breaking its job.
• Pre-auth code paths. Login, session handling and portal components run before identity is established. A bypass there turns the entire authenticated surface into pre-auth surface, which is what CVE-2026-104935 did for CVE-2026-118527.
• Wired into identity. The appliance brokers remote authentication and usually binds to Active Directory, LDAP or RADIUS through service accounts. Root on it means root on a host that handles credentials in transit.
• Weakly monitored. Most appliances do not run your EDR. Defenders rely on vendor integrity tools and logs stored on the device the attacker now controls.

Practitioner’s note: in our external engagements, the VPN gateway is usually the most consequential host in scope and the least tested. Version information often leaks from the portal itself.

We regularly find organizations on a supported train that trail the latest build by one or two releases. That trailing gap is where this chain lives. An external network penetration test should treat edge appliances as primary targets, not as line items in a port scan.

What does Ivanti's patch sequencing leave open?

Ivanti shipped the authentication-bypass fix first and the privilege-escalation fix later, so a team that applied only the bypass fix closed the front door but may still run code containing the other two links. The LPE fix was still in development around the time the exploitation details went public.

The company was direct about why: “At the time of discovery of exploitation, Ivanti had a fix developed for CVE-2026-104935 which was already in QA for supported versions,” and “we made the decision to not delay getting a fix to customers that resolved the primary exploitation path when the LPE was discovered.”

That is a defensible call, because removing the unauthenticated entry point breaks the chain for an attacker starting from nothing. It changes the threat model without ending the threat. Anyone holding a valid low-privileged session, a stolen VPN credential or a different bypass still had the upload and escalation links. Given that UTA0576 harvested credentials, “requires authentication” is thin comfort.

The history complicates this. Ivanti says its own product security program found part of the vulnerability set and patched it in the July 2026 release, which the reporting gives as 25.1.3.0. Backports to other supported versions were still under way when exploitation occurred.

That July version string does not sit neatly beside the 25.1.1.x builds that received the October fix, and the reporting does not explain the relationship. Do not resolve it by guessing from the numbers. Running a supported train did not mean you had the internal fix; that depended on the exact build.

Current fixed builds:

• 25.1.1.2 and earlier: upgrade to 25.1.1.3
• 22.8R2.5 and earlier: upgrade to 22.8R2.6

Ivanti states that “the latest release addresses all vulnerabilities which were chained and exploited in the wild.” The reporting does not map 25.1.3.0 onto each of the three CVEs. If you run that build or anything outside the two ranges above, confirm coverage against Ivanti’s advisory.

What did UTA0576 take once it had root on the gateway?

UTA0576 took credentials and identity material, and the reporting describes no persistent tooling on the appliance. Volexity tracks the group as a previously undocumented actor and documented the chain earlier in October 2026. Many edge-device campaigns drop web shells or malware. According to The Hacker News, UTA0576 used its root access to:

• extract credentials;
• collect limited Active Directory metadata;
• run host reconnaissance;
• search for administrator passwords and BitLocker recovery keys.

That list reads like preparation for the next intrusion. Administrator passwords and directory metadata tell an operator which accounts matter and where they are used.

BitLocker recovery keys are a quieter prize. Organizations commonly escrow them in Active Directory as msFVE-RecoveryInformation objects. Anyone who can read those objects holds what is needed to unlock the matching encrypted volumes, including lost laptops and pulled disks.

The defensive consequence is uncomfortable. No web shell means no web shell to find. A clean integrity check tells you the appliance was not persistently modified. It does not tell you which secrets left the building. Patching closes the code path, but it invalidates nothing that was taken before the patch landed.

The reporting publishes no victim count, sector list or geography, so do not read the absence of named victims as a sign the campaign was small.

What should a security lead verify before November 2?

Confirm the build, preserve evidence, then hunt for identity abuse, in that order. The federal deadline is a useful forcing date even if it does not bind you.

1. Inventory and version every appliance. Read the exact train and build from each admin console, not from the CMDB. Anything on 25.1.1.2 or earlier, or 22.8R2.5 or earlier, is on Ivanti’s vulnerable list even if the October 13 work was applied. Any build outside those ranges, including 25.1.3.0, needs a check against the advisory rather than an assumption.
2. Do not stage the two KEV dates. The federal calendar gives three days for the 8.8 flaw and fourteen for the 4.3. The fixed builds carry both, so November 13 is not slack. An attacker only needs every link once, and leaving the 4.3 in place keeps a working link available.
3. Preserve evidence before you upgrade. Export system, administrator, authentication and remote syslog records, following Ivanti’s published guidance. Upgrades, reboots and resets can destroy local and volatile evidence. Record when the appliance was internet-reachable and when each fix landed; that defines your exposure window.
4. Hunt identity, not implants. Review activity for appliance administrators, the gateway’s LDAP or RADIUS service accounts, and privileged accounts used over the VPN during the window. Look for reads of BitLocker recovery objects and unusual directory queries tied to those accounts.
5. Rotate after containment. Change secrets only once the appliance is patched and verified. Otherwise the new passwords are exposed on the same compromised host.

There is precedent for going further. After the January 2024 Ivanti exploitation, supplemental direction under CISA’s Emergency Directive 24-01 ordered agencies to disconnect affected Connect Secure and Policy Secure appliances instead of relying on mitigations alone. Responders did not trust patch-and-resume for compromised VPN concentrators then. Nothing in this chain argues for more trust now.

If a gateway faced the internet in October on a vulnerable build, scope it as an assumed breach assessment: start from the appliance as a compromised host and measure what its credentials reach.

When we run that scenario from a VPN foothold, an over-privileged bind account with a years-old password is a recurring finding, and our Active Directory penetration testing traces where it leads.

What is still unknown about UTA0576 and the chain?

Most of the operational picture is still missing from the public record. Open questions include:

• How many organizations were hit, in which sectors and countries.
• How long UTA0576 held the chain before Volexity documented it.
• The authoritative mapping of each CVE to each stage, which we have inferred.
• How the July 25.1.3.0 release relates to the 25.1.1.3 fix, and whether it covers all three CVEs.
• Any attribution beyond Volexity’s UTA designation.

Until those gaps close, the safe assumption for any exposed, unpatched gateway is that credentials passed through it and may have been copied.

FAQ

Which Ivanti Connect Secure flaws did CISA add to KEV on October 30, 2026?

CVE-2026-111357, a CVSS 8.8 local privilege escalation from missing authentication for a critical function, and CVE-2026-118527, a CVSS 4.3 predictable-identifier flaw that lets an authenticated user write attacker-controlled files to a known disk location.

If we deployed the CVE-2026-104935 fix, do we still need 25.1.1.3 or 22.8R2.6?

Yes. The authentication-bypass fix removes the unauthenticated entry point, but the upload and privilege-escalation links remain until you run 25.1.1.3 (for 25.1.1.2 and earlier) or 22.8R2.6 (for 22.8R2.5 and earlier).

What is the CISA deadline for CVE-2026-111357?

Federal civilian agencies must remediate it by November 2, 2026, and CVE-2026-118527 by November 13, 2026. Those deadlines bind only FCEB agencies under BOD 22-01, but other organizations should treat KEV listing as a priority signal.

Who is UTA0576 and what did it steal?

UTA0576 is Volexity's designation for a previously undocumented actor. After reaching root, it extracted credentials, limited Active Directory metadata and host details, and searched for administrator passwords and BitLocker recovery keys rather than installing malware.

Does a CVSS 4.3 bug matter if the other Ivanti scores are higher?

Yes. CVSS rates flaws individually. Combined with an authentication bypass, the 4.3 predictable-identifier flaw supplies a step the chain needs to reach code execution.

If your VPN gateway is the front door, test it the way UTA0576 did: a red team operation from agent::offense starts at the edge appliance and follows the credentials to domain admin, or wherever they lead.