CVE-2026-104935: what an authentication bypass on the appliance that checks identity means for the credentials behind it

Ivanti published an advisory on 13 October for an authentication bypass in Connect Secure, tracked as CVE-2026-104935. A remote attacker with no credentials can run commands on the appliance, and Ivanti says exploitation affected a limited number of customers before disclosure ¹. CISA put the CVE on the Known Exploited Vulnerabilities catalog the same day and set a due date of 16 October ²³. The writeup I read twice is Volexity’s, because the appliance in their case ran 22.8R2.4, a build that was current and patched when their investigation started ⁴.

One request, two decisions

The chain starts in the router that hands requests to CGI scripts. The path /dana-na/auth/url_default/welcome.cgi serves the login page, so the appliance allows requests to it without authentication. The attacker sent a request to that public path and named a different script in a header, X-DSCGI-PATH, pointing at wu.cgi, which runs in a trusted context and is not public. The URL decided whether the request passed the check, and the header decided where the request went ⁴.

MITRE describes CWE-290, authentication bypass by spoofing, as authentication schemes that are subject to spoofing attacks ⁵. Ivanti scored this one 8.6 with the vector CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L: reachable over the network, no privileges and no user interaction needed ¹.

Two fields of one request feed two code paths, and the check and the destination stop agreeing. A rule that marks a path public stays true in the configuration file, the request line in the log looks like a login page, and the destination lives in the header.

Command execution, then root

The attacker got command execution through the upload handler in wu.cgi. That handler hashes the filename the client supplies, writes the uploaded content to /home/runtime/tmp/ under that hash, and validates the file as a ZIP after the write has already happened. The actor sent a Perl script with a .zip extension. The file failed validation and got deleted, but it sat on disk long enough for parallel requests, aimed at the same path through the header trick, to run it ⁴.

The actor reached root through dsinvoked, a service that runs maintenance tasks as root and looks up the program for each task in DSCache, a shared configuration store. The exploit patched the in-memory copy of /home/lib/libdsplibs.so inside the cgi-server process, repointed an existing maintenance task at the Perl interpreter, and asked dsinvoked to run it ⁴.

The script then restored the in-memory configuration and the library, and removed its entries from the appliance debug log and the Linux audit log ⁴. The actor planted nothing on the device: no web shell, no separate command channel. Each command re-ran the chain and returned in the HTTPS response ⁴. CISA’s alert says the Integrity Checker Tool may miss this exploitation because the commands execute in memory ².

A current build was the target

The activity Volexity reconstructed runs from 3 October, on an appliance at 22.8R2.4 build 19097 ⁴. Ivanti says it found part of this flaw through its own product security program and shipped that part in 25.1.3.0 in July, and that exploitation happened while its engineers were still backporting the fix to the other supported branches ¹. The advisory dates its backports by build: 25.1.1.2 shipped on 5 October and 22.8R2.5 on 12 October ¹. Volexity dates the patches to 13 October, the same day the advisory published ⁴.

Fixed builds by branch: 25.1.1.2 for 25.1.1.1 and earlier, 25.1.3.0 or 25.1.3.1 for 25.1.2.2 and earlier, 22.8R2.5 for 22.8R2.4 and earlier. Versions at 22.7R2.14 and earlier do not carry the flaw ¹²⁶. Moving to 25.1.3.0 needs new hardware or a virtual appliance rebuilt from the new template, so the interim route depends on the branch already deployed: Ivanti points the 22.8 line at 25.1.1.2 or later, with 22.8R2.5 as the bridge for anyone who cannot move yet ¹⁷.

A fix in the newest code line does nothing for the branch running on the appliance, which is why the timeline here matters: an appliance reporting the current build of an older branch passes an inventory check while the backport is in flight.

Patching and clearing are two questions

Patching the appliance and answering whether an attacker got in are two questions. Ivanti reports limited indicators of compromise, and the actor removed the log entries it could reach ¹²⁴. CISA directs network and memory forensics for anyone trying to determine whether exploitation happened. For a device that answered on the internet during the window, its recovery steps go past the appliance: back up the configuration, factory reset and upgrade, rebuild the virtual instance, restore the configuration, then reset passwords for domain, administrator, and local accounts, revoke and reissue stored certificates, and reset stored API keys and license server credentials ².

The credentials the appliance keeps for the directory belong on that list. Domain credentials used with LDAP were among the first things the actor pulled ⁴.

The evidence lands on the identity side

The post-exploitation record points away from the appliance. Volexity saw a Kerberos tool for Kerberoasting, a Python tool searching the directory for LAPS passwords and BitLocker recovery keys through a compromised service account, packet capture of LDAP traffic, password spraying, and reads of authentication logs to collect valid usernames ⁴. Those actions show up in directory and endpoint telemetry. A search of the appliance’s own logs for failed authentication returns nothing, because a bypass does not fail.

That is the operational problem with a flaw on the device that checks identity. The sessions the appliance reports for the exposure window are sessions the attacker opened, and to the directory they look like ordinary remote access from an ordinary source address.

The order I put in the relay

My contribution to a patching cycle is the order and the reasoning; automation handles the deployment. For this one the order is the branch upgrade first, the interim build where the migration needs hardware, then the forensic question for any appliance that answered on the internet, then the resets that live in the directory and the certificate store rather than on the device. I hand that list to the teams that own the appliance and the identity path, and I mark which steps they can verify from the device and which they cannot. The version string is the easy one to collect, and it does not answer the question people ask first.

The patch closes the route. Proving whether anyone came through it takes memory and directory evidence, and that work starts after the appliance reports the fixed build.