CVSS 8.6 · CISA KEV · authentication bypass to root · exploited in the wild

Ivanti Connect Secure Exploit Chain (CVE-2026-104935): Why One Patch Is Not Enough and How to Check

5 November 2026 · 10 min read

On October 13, 2026 Ivanti disclosed CVE-2026-104935, an authentication bypass in Ivanti Connect Secure that was already being exploited, and CISA gave federal agencies three days to patch it. On the 22.8 and 25.1.1 lines, administrators who did exactly that are still exposed. On October 29 Ivanti released a second round of builds for two more flaws in the same attack chain, CVE-2026-111357 and CVE-2026-118527, and CISA added both to its Known Exploited Vulnerabilities catalog the next day. The October 13 fix breaks the chain at its first link; the October 29 builds are the ones that close it. And because the attackers ran their commands in memory, Ivanti's own Integrity Checker Tool may report a clean appliance that was not.

The Vulnerability: Three Links, One Chain

Ivanti Connect Secure, the SSL VPN gateway formerly sold as Pulse Connect Secure, has had a run of exploited zero-days; this is the latest. Ivanti covers all three CVEs in a single advisory, and states the exploitation plainly: "We are aware of exploitation in the wild affecting a limited number of customers at the time of disclosure when CVE-2026-104935, CVE-2026-111357 and CVE-2026-118527 are chained." Read in order, they take an attacker from the public login page to root on the appliance:

1. CVE-2026-104935 — the way in. Authentication bypass by spoofing (CWE-290), 8.6 High. Ivanti: it allows "a remote unauthenticated attacker to execute arbitrary commands." Per Volexity's write-up, a request to the public login page /dana-na/auth/url_default/welcome.cgi carrying an X-DSCGI-PATH header is routed to a protected file-upload handler, wu.cgi, without a session.
2. CVE-2026-118527 — the foothold. Generation of predictable numbers or identifiers (CWE-340), 4.3 Medium. The upload handler writes attacker-controlled content to a location on disk the attacker can predict. Volexity describes the handler writing the file before validating it, which leaves a window to execute a Perl script.
3. CVE-2026-111357 — root. Missing authentication for a critical function (CWE-306), 8.8 High in Ivanti's scoring. Volexity attributes the escalation to a privileged broker process trusting cached data it should not have.

One labelling detail explains why KEV calls the middle link "authenticated" when the chain is not. Volexity's original October 13 post described the bypass and the upload together under CVE-2026-104935. Ivanti later split the upload out as its own CVE, scored on its own it requires a session (PR:L), and that session is exactly what the first link forges. Chained, nothing in the sequence needs a credential.

Why the October 13 Patch Was Not Enough

Ivanti's advisory now carries two rows per branch, disclosed sixteen days apart. The first round fixed only the authentication bypass; those builds shipped in the days before the October 13 disclosure (Censys records 25.1.1.2 on October 5 and 22.8R2.5 on October 12). The second round, released October 29, fixed the upload and the privilege escalation. The result, per branch:

branch   still affected  fixed
22.8     ≤ 22.8R2.5      22.8R2.6
25.1.1   ≤ 25.1.1.2      25.1.1.3
25.1.2   ≤ 25.1.2.2      25.1.3.0+
22.7     not affected
25.1.3+  not affected

The trap is in the "still affected" column: 22.8R2.5 and 25.1.1.2 are the round-1 builds. A 22.8 or 25.1.1 appliance upgraded promptly in October is running exactly the last affected build for the round-2 CVEs. Does that matter if the front door is shut? Less than for an unpatched box, because the remaining two flaws need a session and the forged one is gone. But a session is what a VPN gateway hands out all day: any valid user, a phished credential or a stolen one puts an attacker at the start of the second half of the chain. And CISA treated it as urgent. It gave agencies until November 2 to remediate CVE-2026-111357, three days after listing it.

The 25.1.2 line resolves differently. Ivanti's fix for CVE-2026-104935 on 25.1.2.x is to move to 25.1.3.0 or 25.1.3.1, and the advisory states 25.1.3.0 and later do not contain the vulnerability. Ivanti says it had already fixed part of the issue internally in 25.1.3.0 in July and was backporting the fix when exploitation began. So a 25.1.2 appliance that took the round-1 path is covered for all three. The catch is the platform: 25.1.3.0 runs on the ISA4500, ISA6500 and ISA8500 hardware, and virtual or cloud appliances have to be rebuilt from the 25.1.3.0 template rather than upgraded in place.

One practical deadline sits behind all of this. Ivanti lists January 31, 2027 as end of life for both the 22.7 and 22.8 lines, so a 22.8R2.6 upgrade buys under three months before the same platform move is due anyway.

Why a 4.3 Medium Is on the KEV List

CVE-2026-118527 scores 4.3, a number most patch queues would leave for next quarter, and the score is accurate on its own terms. Its vector, C:N/I:L/A:N, describes an authenticated user writing a file to a predictable place: no disclosure, limited integrity impact. That is what the bug is in isolation. KEV does not list it for its severity. It lists it because it is the link that turns a bypass into code execution, and because Ivanti says the three were exploited together.

This is the case CVSS is worst at. A base score rates one flaw at a time and has no field for "the step between two others." A team that triages by score alone would have put CVE-2026-118527 at the bottom of the queue the week it was being used against VPN gateways. The KEV listing is the correction, and it is why this post leads with the chain rather than any single number.

CVE-2026-111357 has a scoring disagreement worth reading rather than picking a side on. The CVE record was assigned by MITRE, not Ivanti, and scores it 7.0 with AC:H and scope unchanged. Ivanti's advisory scores the same flaw 8.8 with AC:L and scope changed, which reads as a low-privileged process on the appliance reaching root on the operating system underneath. Ivanti knows its own architecture; MITRE scored from outside. For prioritisation it is moot: the flaw is KEV-listed and its CISA deadline has already passed.

A Clean Integrity Check Is Not an All-Clear

Ivanti's standing advice for Connect Secure incidents is to run its Integrity Checker Tool, and its advisory says so again here. For this chain, CISA warns that the tool "may not detect evidence of exploitation of CVE-2026-104935 because threat actor commands execute in memory," and says determining compromise requires network and memory forensics. Volexity found the same: the actor patched library code in memory and restored the configuration store afterwards, so the Integrity Checker "does not detect any modifications."

Volexity's account of what UTA0576 did on the appliances it observed explains why this matters. The actor did not install a web shell. It re-ran the full exploit chain for every command, which leaves nothing persistent to find. With that access it collected LDAP credentials the appliance used for authentication, queried Active Directory for LAPS passwords and BitLocker recovery keys, ran password spraying, captured LDAP traffic with a renamed tcpdump, and deleted selected log entries. The appliance Volexity investigated was a fully patched 22.8R2.4 at the time.

The consequence for a defender is that the useful question is not "is the appliance clean now?" but "what did it have access to while it was exposed?" A gateway that authenticates users against Active Directory holds a directory bind credential, and in the activity Volexity describes that credential was the target. If an affected build was reachable from the internet after October 1, assume that credential is known to someone else and rotate it, whatever the Integrity Checker says. Volexity assesses with low confidence that UTA0576 is criminal rather than espionage, and with medium confidence that it used large language models in its exploit development; neither changes the response.

A note on method: Ivanti Connect Secure is a licensed appliance, not self-hostable software, so there is no vulnerable instance we can legally stand up and no reproduction to show. Everything above comes from Ivanti's advisory, the CISA alert and KEV entries, and Volexity's incident write-up, and where those sources disagree we say so. Where this blog reproduces a bug against a real product, it says so and shows the capture.

Investigation Workflow

Remote work can establish that a Connect Secure gateway exists, where it answers, and usually which release it runs. It cannot establish whether the appliance was compromised; that question belongs to memory and network forensics, and to the logs of everything the appliance authenticates against.

1. Find the Gateways

VPN gateways tend to live on predictable hostnames: vpn., remote., sslvpn., access.. Enumerate your organisation's subdomains from certificate transparency with the subdomain finder, and include gateways belonging to acquired companies or regional offices, which are the ones most often missed in an emergency patch round. A DNS lookup in RECON confirms what each name resolves to today.

2. Port Scan and HTTP: Confirm It Is Connect Secure

The user portal is served over HTTPS on 443. Its public sign-in page is /dana-na/auth/url_default/welcome.cgi, the same path the first link of the chain abuses, and the /dana-na/ and /dana-cached/ prefixes are characteristic of the product. These identify Connect Secure; they do not tell you the release.

3. Read the Version

ProjectDiscovery's pulse-secure-version nuclei template, a passive check, requests /dana-na/nc/nc_gina_ver.txt and then /dana-cached/hc/HostCheckerInstaller.osx, and extracts the version from whichever answers; the template notes the first file is absent on newer releases. Censys documents the installer as an unauthenticated download with the version embedded in its property list, in a build-style form such as 22.2.16.21349 rather than the "22.8R2.6" form the advisory uses, so treat it as a strong pointer and confirm the release from the admin console. ProjectDiscovery also publishes a template for CVE-2026-104935 itself. That one exercises the bypass by requesting the protected upload handler. It is the most direct test available, and for that reason it belongs only on appliances you own, with change approval.

4. TLS Inspect: Separate the Fleet

The certificate's subject and SAN list can name other gateways in the same deployment, and a self-signed certificate on an internet-facing address marks a box worth a closer look. Note the issuance date too: Ivanti's recovery steps include revoking and reissuing the appliance certificate, so a certificate still dated before October on an appliance you believe was rebuilt means a recovery step was skipped.

5. Cross-Reference External Data

Shadowserver counted more than 5,000 Connect Secure instances exposed to the internet, as reported by BleepingComputer on November 2; that is exposure, not a count of affected builds or compromises. Previdian's honeypots logged 105 exploitation attempts from 50 IP addresses by October 14, most of them probing whether code execution worked. Defused reported decoy hits from October 1, two days before the first activity Volexity observed. Taken together: this was being scanned for at scale within a day of disclosure, and the in-the-wild window starts before Ivanti's advisory existed. Check the CVE history for your release with RECON's CVE lookup, and if you run other SSL VPN appliances, the FortiOS SSL-VPN symlink bypass is the same class of internet-facing gateway with the same lesson about patches that leave something behind.

Remediation

1. Upgrade to the round-2 build. 22.8R2.6 or 25.1.1.3. If you patched on October 13, you need this again. On 25.1.2.x, move to 25.1.3.x; virtual and cloud appliances are rebuilt from the 25.1.3.0 template.
2. Decide whether the appliance was exposed. If it ran an affected build and was reachable from the internet at any point since October 1, treat it as potentially compromised. A clean Integrity Checker result does not change that.
3. Follow Ivanti's recovery steps. Back up the configuration, factory reset (rebuild if virtual), upgrade, restore the configuration. Ivanti's recovery KB still names 22.7R2.5 as the reset target, left over from earlier incidents; upgrade to the fixed releases in the current advisory instead.
4. Reset every credential the appliance held. Domain, administrator and local accounts; the LDAP or Active Directory bind account first, since collecting it was the actor's observed goal. Revoke and reissue certificates, and reset API keys and license server credentials.
5. Hunt in the directory, not only on the box. From the appliance's addresses since October 1, look for reads of LAPS password attributes and BitLocker recovery objects and for password-spraying patterns. The tooling Volexity recovered could also Kerberoast, though the script it saw did not use that function, so bulk Kerberos service-ticket requests are worth a look too. Volexity observed selective log deletion on the appliance, so the directory side is the more reliable record.
6. Plan the platform move. 22.7 and 22.8 reach end of life on January 31, 2027, and Ivanti states 25.1.3.0 and later do not contain these flaws.

Follow @hellorecon for new CVE investigations.

Sources

• → Ivanti: Security Advisory Ivanti Connect Secure (CVE-2026-104935), covering CVE-2026-111357 and CVE-2026-118527
• → CISA: CISA Urges Patching Newly Exploited Vulnerabilities in Ivanti Connect Secure (revised October 30, 2026)
• → CISA: Known Exploited Vulnerabilities Catalog
• → Volexity: A Series of Unauthenticated Events, Chained Exploitation of Ivanti Connect Secure Zero-Days
• → Ivanti: Recovery Steps (KB 000097080)
• → SecurityWeek: Ivanti Patches Two More Zero-Days Exploited in Connect Secure Attack Chain
• → ProjectDiscovery: pulse-secure-version nuclei template
• → Censys: CVE-2026-104935 advisory (build release dates) · Pulse Connect Secure, a view from the internet (HostChecker version)
• → BleepingComputer: Ivanti patches two more Connect Secure zero-days chained in attacks
• → NVD: CVE-2026-104935 · CVE-2026-111357 · CVE-2026-118527