Ivanti Connect Secure: three boundaries crossed to reach root
Volexity reconstructed the chain exploited against Ivanti Connect Secure: CGI routing, executable temporary file, then privileged broker. Analysis and scope.
Intrusion observed from October 3, 2026; Ivanti advisory from October 13, completed on 29. A VPN gateway is not an ordinary server: it is exposed to the Internet, completes user authentication and often has secrets to talk to the internal directory. In the case studied by Volexity, an attacker combined an authentication bypass, execution of a temporary file, and privilege escalation to execute commands as root on Ivanti Connect Secure. The CERT-FR confirms the active exploitation of CVE-2026-104935 as well as the two flaws added subsequently, CVE-2026-111357 and CVE-2026-118527.
First boundary: the checked path is not the executed path
The public request to welcome.cgi was to serve the login page. The front end decided that it was allowed because this URL was public. But a header value, X-DSCGI-PATH, could designate another CGI script, normally protected. The security check and the internal router therefore did not target the same destination. Volexity describes the access thus obtained to the wu.cgi manager; the attacker did not need a valid VPN session to reach the internal code.
The missing invariant is simple: after rewriting and routing, the component actually called must remain the one to which the authorization applies. Checking only the visible URL then accepting a destination from another field leaves two interpretations of the same request. This is a family of bugs found in proxies and gateways, even if the precise fields differ.
Second boundary: write then validate
The wu.cgi manager received a file presented as a ZIP archive. According to analysis of traces and memory dumps, it calculated a temporary name from the passed name, wrote the contents to disk, and only then checked whether the file was a valid ZIP. Content that failed this check was deleted, but it had existed between writing and deletion.
The attacker used the same routing confusion to target this temporary file during this short window. Parallel queries increased the chance that an execution request would arrive before cleanup. The documented result is the execution of a Perl script under user cgi-server. Validation after the write did not protect the intermediate state; it only reduced its duration. The race belongs to CVE-2026-104935 with the authentication bypass, according to Ivanti’s presentation taken up by Volexity.
The previous steps give a less privileged execution point, before root access. Presenting them directly as administrator access would hide the third boundary.
Third boundary: the root broker trusts a modifiable state
The privileged service dsinvoked launches maintenance tasks by consulting their definition in DSCache. Volexity reports that the attacker modified in memory a library loaded in the cgi-server process, allowing them to change the DSCache entry of an existing task. It temporarily replaced the expected program with the Perl interpreter, then asked the broker to execute the task with a chosen script. The broker, which was running as root, applied the corrupted configuration.
The weakness is a breakdown in provenance: a root service treats a configuration value as a reliable instruction even though a less privileged process could have modified it. The attacker’s test, reported by Volexity, consisted of verifying access to /etc/shadow. The team then observed the configuration and in-memory library return to their previous state. The October 13 notice still indicated that the elevation correction was in preparation; Volexity added on October 29 that Ivanti had released it under CVE-2026-111357. CERT-FR also identifies CVE-2026-118527, another exploited weakness allowing an authenticated attacker to upload an arbitrary file; it should not be mechanically attributed to each execution observed in the first investigation.
What the attacker actually did after the exploit
Volexity documented the use of the gateway’s LDAP service account to query Active Directory, look up LAPS passwords and BitLocker recovery keys, test credentials, and inspect LDAP traffic. The commands and their output traveled through HTTPS requests from the exploitation chain. The team did not identify a permanent webshell necessary for this operation: the attacker re-executed the chain for each command. Logs were filtered and rewritten; memory modifications and DSCache entries were restored to their previous state. These observations explain why a simple integrity check of files on disk is not enough to rule out the intrusion.
The data sought does not prove that all secrets of all affected environments have been stolen. They show the type of consequences possible when the edge equipment already has a trust link with the directory. CERT-FR says it is aware of lateral moves using such secrets and recommends treating them as compromised when an appliance is compromised.
How could we find and verify the chain?
An authorized audit would have compared, for each request, the URL submitted, the script actually executed and the authorization decision; a divergence gives the first signal. The second test consists of observing the life cycle of an invalid upload: does it exist on disk before validation, is it addressable, and for how long? The third tracks the unprivileged process’s calls to DSCache and the commands that dsinvoked then executes. Instrumentation of memory and dumps is essential if changes do not persist to disk. This approach is an educational reconstruction; Volexity actually used memory, disk images and core dumps to establish the chain of the incident studied.
The patch must be accompanied by an incident response if the equipment was exposed during the attack window. The CERT-FR recommends isolating the machine, keeping memory and logs, searching for indicators, then processing the certificates, service accounts and other secrets that have passed through the gateway. An updated appliance ceases to be vulnerable to the patched chain; it does not automatically become trusted again if the attacker has already reached its directory.
Main sources: Volexity investigation, CERT-FR alert, Ivanti notice.
#rootzero
A question about your exposure?
Write to us. Someone from the technical team will answer, with sources.