Ivanti Connect Secure CVE-2026-111357 Exploited: What to Do

Yes, CVE-2026-111357 is being exploited. On 30 October 2026 CISA added it and CVE-2026-118527, both in Ivanti Connect Secure, to its Known Exploited Vulnerabilities catalog, which means CISA has evidence that attackers are using them. They are the second and third links of a chain that starts with CVE-2026-104935, the authentication bypass Ivanti patched on 13 October, so the 25.1.1.2 and 22.8R2.5 releases that fixed that one are still exposed. Upgrade to 25.1.1.3 or 22.8R2.6 now, and if the appliance was reachable while vulnerable, treat it as compromised: factory reset and restore it, reset every password and key it stored, end the sessions those credentials opened, and hunt for what the attacker did with them.

This post is for the admin who runs Connect Secure, has lived through earlier Ivanti VPN incidents, and wants to know quickly whether this one applies and what to do after the patch. It puts both new KEV entries in one place, explains how they fit together, and then spends most of its time on the part that lands on your identity systems, because the attackers in this campaign went for the domain credentials the appliance holds.

Key takeaways

• Affected: Connect Secure 25.1.1.2 and prior, 25.1.2.2 and prior, and 22.8R2.5 and prior, per CISA’s alert (last revised 30 October). Fixed: 25.1.1.3 and 22.8R2.6, released by Ivanti on 29 October (Rapid7).
• Exploitation began on 3 October 2026, ten days before the first patch, according to Volexity, which found the chain.
• The attackers took domain credentials stored on the appliance, used its Active Directory service account to query the directory, and harvested passwords from packet captures, so rotation covers more than the VPN itself.
• The chain runs in memory and the payload cleans up after itself, so Ivanti’s Integrity Checker Tool may not show anything (CISA).

What are CVE-2026-111357 and CVE-2026-118527?

CISA’s KEV catalog, as its JSON feed records them, describes the two new entries this way:

• CVE-2026-111357, “Ivanti Connect Secure Missing Authentication for Critical Function Vulnerability”: it “could allow a local authenticated attacker to escalate their privileges”. CISA maps it to CWE-306, Missing Authentication for Critical Function, the weakness where a function that changes something important can be called without proving who you are. Volexity’s write-up shows where it sits: the appliance runs “a privileged background service named dsinvoked, which runs maintenance tasks as root on demand”, and that service “looks up which program each task runs in DSCache, a shared ICS configuration store.” Ivanti rates it 8.8 High, as Rapid7 quotes its advisory.
• CVE-2026-118527, “Ivanti Connect Secure Generation of Predictable Numbers or Identifiers Vulnerability”: it “allows a remote authenticated attacker to upload files with attacker-controlled content to a known location on disk”. That is CWE-340, Generation of Predictable Numbers or Identifiers: a value that should be hard to guess, here a file’s location, can be worked out in advance. Ivanti rates it 4.3 (Rapid7).

Read on their own, both look like second-stage bugs, because each needs the attacker to be authenticated already. CISA’s entries say why that is little comfort: each “can be chained with CVE-2026-104935” and the other. CVE-2026-104935, in the catalog since 13 October, is an authentication bypass by spoofing that, in the words of CISA’s 13 October alert, “allows a remote unauthenticated attacker to execute arbitrary commands”. Put together, the three take an attacker from the internet to root on the appliance without a password, which is how CISA’s alert describes them: “remote, unauthenticated execution of arbitrary commands”.

A word on the scores. A 4.3 and a “local” privilege escalation would normally sit low in a patch queue. Here they are the steps that turn a foothold as a low-privilege web user into full control, so score them by the chain they belong to, not one at a time.

How does the exploit chain work?

Volexity’s write-up, published on 13 October and updated after Ivanti’s 29 October patch, walks through what the actor it tracks as UTA0576 did on a 22.8R2.4 appliance. The bypass sends requests to the public login page, /dana-na/auth/url_default/welcome.cgi, which the appliance allows without authentication, and uses a mismatch where “the URL is used to determine whether the request is allowed, while the header path is used to determine the destination.” The actor then uploads a Perl script through an upload handler that writes it to /home/runtime/tmp/ under the MD5 hash of the file name the client supplied, a path the attacker can compute in advance, and races to run it before the handler deletes it. That upload step fits CISA’s description of CVE-2026-118527. The code runs as the web service user, and CVE-2026-111357 lifts it to root: Volexity says the actor patches an Ivanti library in the process’s memory to modify DSCache and reconfigure “an existing maintenance task to launch the Perl interpreter instead of its legitimate script.”

The attacker skips the login with CVE-2026-104935, uploads a script to a path it can predict with CVE-2026-118527, runs it as the low-privilege web user, escalates to root with CVE-2026-111357, and then reads the domain credentials stored on the appliance. The 13 October releases fixed only the first step, so an appliance on 25.1.1.2 or 22.8R2.5 still needs the 29 October upgrade.

Two details from that account change how you respond. The actor deployed no web shell and passed commands through the exploit’s own HTTPS requests, so there is nothing persistent on disk to find. And the payload removes recent entries from the appliance’s debug and audit logs, deletes itself and restores the memory it patched. That is why CISA warns that “Ivanti’s Integrity Checker Tool may not detect evidence of exploitation of CVE-2026-104935 because threat actor commands execute in memory”, and why a clean result from that tool is not evidence that nobody was there.

Which versions are affected, and what is the fix?

CISA’s alert lists all three CVEs as “affecting Ivanti Connect Secure versions 25.1.1.2 and prior, 25.1.2.2 and prior, and 22.8R2.5 and prior”, and tells you to “immediately update to the latest version, as outlined in Ivanti’s Security Advisory”. Rapid7’s summary of Ivanti’s update gives the fixed releases as 25.1.1.3 for the 25.1.1 line and 22.8R2.6 for the 22.8 line, and recommends moving off 22.8 to 25.1.1.3 where you can. For the 25.1.2 line, Rapid7’s table lists no fixed build against CVE-2026-111357 and CVE-2026-118527: its 25.1.3.0 and 25.1.3.1 row is the fix for CVE-2026-104935 on 25.1.2.2 and prior. It also notes that “Ivanti lists 25.1.3.0 and later on ISA4500, ISA6500, or ISA8500 as unaffected”, so if you run that line, check Ivanti’s advisory for the release that covers your appliance before you schedule the work.

The trap in this incident is the earlier patch. Teams that upgraded to 25.1.1.2 or 22.8R2.5 after the 13 October advisory did the right thing at the time, but those releases fix only CVE-2026-104935 and remain on CISA’s affected list for the other two. Check the running version on every appliance, including standby members of a cluster, rather than assuming the October change ticket covered it.

Is there a deadline?

For US federal civilian agencies, yes, and it has already arrived for one of them. The KEV feed gives CVE-2026-111357 a due date of 2 November 2026 with forensic triage required, and CVE-2026-118527 a due date of 13 November 2026. The deadlines come from BOD 26-04, “Prioritizing Security Updates Based on Risk”, issued on 10 June 2026, which “supersedes and hereby revokes” BOD 22-01, the older directive many runbooks still cite. The KEV entry for CVE-2026-111357 sets its due date three days after the 30 October addition and marks it “Forensic triage required per BOD 26-04: Yes”; the directive’s remediation timelines table sets how long each kind of entry gets.

The directive binds only federal agencies, but CISA’s 30 October alert encourages every organization to prioritize KEV entries, and the forensic triage requirement is the right model for anyone whose appliance was on the internet in October: patching stops the next attempt, and triage tells you whether an earlier one succeeded.

In what order should you respond?

Order matters for the same reason it does after any appliance compromise. If you reset passwords while the appliance is still vulnerable, whoever controls it reads the new ones as you type them, and if you reset before collecting evidence, you lose the record of what was reached.

1. Upgrade. Move every appliance to 25.1.1.3 or 22.8R2.6, or the fixed build Ivanti lists for your line. Upgrade standby nodes as well.
2. Preserve evidence first if you suspect compromise. Volexity notes that the chain lives in memory and that the payload edits on-box logs, so collect memory where you can, and pull the logs you forwarded off the appliance (syslog, SIEM, reverse proxy and firewall records) for the window from 3 October to your upgrade. CISA says that organizations checking for compromise “will need to conduct network and memory forensics to identify evidence of exploitation.”
3. Reset and restore. CISA’s steps for a suspected compromise are to back up the configuration, “conduct a factory reset and upgrade the appliance to the latest version”, and restore the configuration from that backup.
4. Rotate everything the appliance stored. CISA’s fourth step is to “reset passwords for all accounts, including domain, administrator, and local accounts. Revoke and reissue stored certificates; reset stored API keys and license server credentials.” The next section covers what that means on the identity side.
5. End the sessions those credentials opened. This step is our recommendation rather than CISA’s: once passwords change, end the existing sessions of the affected accounts in your identity provider and applications, because a session started with a stolen password stays valid until it expires or you end it.
6. Hunt for what the attacker did next, using the indicators below.

We would rotate and end sessions for every appliance that was reachable on a vulnerable release, whether or not the hunt finds anything. The payload removes its own traces, so an absence of evidence here is weaker than it usually is.

What should you look for?

Volexity’s detection guidance is specific to this chain:

• Large numbers of requests to /dana-na/auth/url_default/welcome.cgi.
• Requests carrying an X-DSCGI-PATH header that points to the upload handler (/home/webserver/htdocs/dana/fb/smb/wu.cgi) or into /home/runtime/tmp/, and in general any mismatch between the URL path and that header.
• Leftovers of post-exploitation work in /tmp/ on the appliance, such as JSON exports of directory queries.
• On the directory side, LDAP queries from the appliance’s Active Directory service account that look for LAPS passwords, BitLocker recovery information or the userPassword and unixUserPassword attributes, and password spraying against domain accounts.

Volexity also found that the actor ran a packet parsing tool against a packet capture already stored on the appliance, filtering for LDAP traffic on TCP port 389 to extract credentials, and copied the appliance’s configuration directories. Its post links to the indicators it has published for UTA0576, including the infrastructure the actor used.

What does rotation look like on the identity side?

A Connect Secure appliance is usually wired into Active Directory or LDAP to authenticate VPN users, which means it holds a directory service account and sees user passwords as they sign in. In this campaign, that is exactly what the attacker used. The rotation list for the identity side follows from it:

• The appliance’s directory service account. Reset it, and check its permissions while you are there: an account that can read LAPS passwords or BitLocker recovery keys is far more privileged than a VPN needs.
• Every user password the appliance could have seen. If users signed in to the VPN with their domain password during the window, those passwords passed through a device the attacker controlled, and some of them may sit in captured LDAP or HTTP Basic traffic. A forced reset for VPN users is the conservative choice.
• Shared bind accounts. If your Keycloak realm federates the same directory through LDAP user federation, the provider signs in to the directory with its own bind account, and Keycloak’s documentation lists the “LDAP bind credential” among the secrets set in the LDAP settings of LDAP-based user federation. If that is the same account the VPN uses, rotate it in both places at once, or Keycloak’s sync and logins against the directory will start failing.
• Certificates and API keys stored on the appliance, as CISA lists, including any SAML signing or encryption material if the VPN uses a SAML identity provider.

For sessions, you rarely need to log everyone out of everything. Revoking one Keycloak session without logging the user out everywhere shows how to list a user’s sessions, which the Admin REST API returns with their IP address and start time, and delete the ones you do not trust by ID, and when you do want a clean break for a whole realm, the same post covers logging out all sessions and the not-before policy that invalidates earlier tokens.

Does SSO in front of your apps stop this?

No, and it is worth being plain about it. CVE-2026-104935 is a pre-authentication bug in the gateway itself, so no identity provider sitting behind or beside the VPN can stop someone from exploiting it. The patch is the only fix for the appliance.

What an identity provider can do is limit what a compromised gateway hands over. In this campaign the attacker came away with network position and a set of domain passwords. If the internal applications behind the VPN accept a domain password and nothing else, those passwords are enough to open them. If the applications instead sign users in through an identity provider that asks for a second factor, a harvested password alone does not get the attacker into the application, and a session they do manage to start expires on a schedule you set.

In Keycloak terms, that means three things:

• Single sign-on for the internal applications, with OIDC or SAML, so that each one trusts the identity provider and not a password check of its own against the directory.
• Multi-factor authentication in the realm’s browser flow. Keycloak’s default browser flow can offer WebAuthn or OTP as the second factor, and passkeys can be set up for passwordless sign-in. Our passkeys guide covers the phishing-resistant option, which also does not leak a reusable secret into a packet capture. For the most sensitive applications, step-up authentication can ask for a stronger factor only when a user reaches them.
• Short sessions. Our guide to Keycloak session timeouts explains the SSO Session Idle and SSO Session Max settings and the Access Token Lifespan, all listed in the Server Administration Guide’s session and token timeouts, which together decide how long a stolen session stays useful.

None of that replaces patching, network restrictions on the appliance’s management interface or the hunt above. It is defense in depth: the gateway decides who reaches your network, and the identity provider decides who reaches each application, so a flaw in one does not open the other. The Keycloak security audit and hardening checklist covers the rest of the realm settings worth checking while you are in there.

Have we seen this pattern before?

Many times this year. The Aruba AOS authentication bypass and BeyondTrust’s CVE-2026-102764 were both flaws in devices at the edge of the network, and the response we described for each took the same shape: patch or isolate, keep the forwarded logs, rotate on both ends of every relationship, and then review sign-ins at the identity provider. The identity provider has had its own share, too, such as CVE-2026-97176, where, per its CVE record, Keycloak “may incorrectly issue a token at the lower security level instead of enforcing the required higher level”, and CVE-2026-97177, a flaw in delegated administration with Fine-Grained Admin Permissions (CVE record), which is why keeping that layer patched matters as much as the gateway.

Frequently asked questions

Is CVE-2026-111357 being exploited?

Yes. CISA added it to the Known Exploited Vulnerabilities catalog on 30 October 2026, the NVD record describes it as “exploited in the wild in October 2026”, and Volexity observed it in a chain that began on 3 October.

I patched CVE-2026-104935 in October. Am I safe?

Not if you stopped at 25.1.1.2 or 22.8R2.5. Those releases fixed the authentication bypass but are still listed as affected by CVE-2026-111357 and CVE-2026-118527 in CISA’s alert. Upgrade to 25.1.1.3 or 22.8R2.6. And because exploitation started before any patch existed, an appliance that was reachable in early October may have been compromised before you patched at all.

Does the Integrity Checker Tool show whether I was compromised?

It may not. CISA says it “may not detect evidence of exploitation” because the commands run in memory, and Volexity found that the chain restores the memory and configuration it changed. Use network logs and memory forensics instead.

Does CVE-2026-118527 let attackers guess session IDs?

Nothing published says so. CISA’s KEV entry describes it as letting an authenticated attacker “upload files with attacker-controlled content to a known location on disk”, so the predictable value is a file’s location, not a session token. Treat sessions as at risk anyway, because the chain gives the attacker root on the device users sign in through.

Which deadline applies under BOD 26-04?

For federal civilian agencies, 2 November 2026 for CVE-2026-111357 (with forensic triage) and 13 November 2026 for CVE-2026-118527, per the KEV feed. BOD 26-04 replaced BOD 22-01 in June 2026.

What to do next

Check the running version on every Connect Secure appliance today and move it to 25.1.1.3 or 22.8R2.6. If it was reachable on an earlier release since 3 October, collect memory and the forwarded logs, factory reset and restore it, and then reset the appliance’s directory service account, the passwords of users who signed in through it, and the certificates and keys it stored, before ending the sessions those credentials opened. Once the gateway is clean, put the applications behind it on single sign-on with multi-factor authentication and short sessions, so that the next gateway flaw yields a password that opens nothing on its own. If you would rather have someone else run and patch the identity provider while you handle the VPN, that is what our managed Keycloak hosting is for.

Sources

• CISA, “CISA Adds Two Known Exploited Vulnerabilities to Catalog”, 30 October 2026, retrieved 2026-11-02
• CISA, “CISA Urges Patching Newly Exploited Vulnerabilities in Ivanti Connect Secure”, 13 October 2026, last revised 30 October 2026, retrieved 2026-11-02
• CISA, Known Exploited Vulnerabilities Catalog and its JSON feed, catalog version 2026.10.30, retrieved 2026-11-02
• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, 10 June 2026, and BOD 22-01, which it superseded
• NVD, CVE-2026-111357 and CVE-2026-104935, retrieved 2026-11-02
• Ivanti, Security Advisory: Ivanti Connect Secure (CVE-2026-104935), updated 29 October 2026
• Volexity, “A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days”, 13 October 2026, updated after 29 October 2026
• Rapid7, “Additional Ivanti Connect Secure zero-days exploited in the wild (CVE-2026-111357, CVE-2026-118527)”, 2 November 2026
• MITRE, CWE-306: Missing Authentication for Critical Function and CWE-340: Generation of Predictable Numbers or Identifiers
• Keycloak, Server Administration Guide: LDAP and Active Directory