Ivanti Connect Secure Chained Flaws: CVE-2026-104935

In early October 2026, a threat actor tracked as UTA0576 compromised a fully patched Ivanti Connect Secure (ICS) appliance running build 22.8R2.4. There was no web shell, no second-stage implant, and no separate command-and-control channel. The operator ran every command and read every result inside the HTTPS requests of the exploit chain itself, re-running the full three-stage sequence on demand. By the time Volexity reconstructed the activity, the attacker had reached root on an edge device that most teams believed was current on patches.

This is the kind of incident that changes how a security team thinks about internet-facing VPN gateways. Below, the Redfox Cybersecurity team breaks down the full chain, the affected builds, how to confirm your exposure, and the detection and response steps that actually move the needle.

What CVE-2026-104935, CVE-2026-111357, and CVE-2026-118527 Actually Do

These three CVEs are not three separate problems you can triage independently. They are designed to be chained, and each one hands off to the next.

• CVE-2026-104935 (CVSS 8.6, CWE-290, authentication bypass by spoofing): a remote, unauthenticated attacker bypasses access controls on the web component and reaches restricted functionality, then pivots to arbitrary command execution as the appliance web user. Ivanti tracks the bypass and the resulting remote code execution together under this single identifier.
• CVE-2026-118527 (CVSS 4.3, predictable filenames during file processing): an attacker who already has a foothold writes malicious files to known, predictable locations on local disk. On its own this looks low severity. In the chain it is the staging step that sets up privilege escalation.
• CVE-2026-111357 (CVSS 7 to 8.8, CWE-829, missing authentication for a critical function): a local privilege escalation that elevates the web user to root by abusing a privileged broker process. This is the step that turns a limited foothold into total control of the device.

Chained together, the result is unauthenticated root-level code execution on an appliance that sits at the perimeter of the corporate network. Ivanti confirmed in-the-wild exploitation affecting a limited number of customers when all three are used in sequence.

If you run ICS and want a second set of eyes on your exposure before you finish reading, the Redfox Cybersecurity team handles exactly this kind of edge-device triage at redfoxsec.com.

Why These Ivanti Connect Secure Vulnerabilities Matter

Ivanti Connect Secure is a remote access gateway that terminates VPN sessions for the workforce. That role gives it three properties attackers love: it is exposed to the public internet, it holds or brokers credentials, and it sits inside the trust boundary once a session is established. A root compromise means the attacker can read configuration, harvest cached credentials, pivot into internal subnets, and tamper with the appliance's own integrity checks.

This family has a long history on the CISA Known Exploited Vulnerabilities (KEV) catalog, joining a string of Pulse and Connect Secure entries going back years. CVE-2026-104935 was added to KEV shortly after disclosure, which puts U.S. federal agencies on a hard remediation deadline and signals to everyone else that exploitation is real, not theoretical.

The detail that should worry defenders most is the tradecraft. Because the operator tunneled commands through the exploit chain's own HTTPS requests and deployed no backdoor, standard web shell hunting and file-integrity scanning missed it. Detection had to shift to request patterns, process lineage, and memory artifacts.

Breaking Down the Ivanti Connect Secure Exploit Chain

Understanding the sequence is what lets you build detections that survive minor variations in the attacker's tooling. Here is how the three stages fit together.

Stage 1: Authentication Bypass by Spoofing (CVE-2026-104935)

The bypass abuses how the web component resolves and trusts internal CGI routing. An attacker sends crafted requests to the unauthenticated login surface and uses a routing header to reference a different CGI resource or a temporary file than the one the request appears to target. Volexity's guidance points defenders at a high volume of requests to the welcome CGI endpoint where a routing header references another resource.

A sanitized, illustrative version of the request shape that defenders match on looks like this. The command here is a benign id placeholder used only to show the structure, not a working exploit.

POST /dana-na/auth/url_default/welcome.cgi HTTP/1.1
Host: ics.target.example
X-DSCGI-PATH: /dana-na/../../tmp/stage.cgi
Content-Type: application/x-www-form-urlencoded
Connection: close

cmd=id


[cta]

The combination that matters for detection is an unauthenticated POST to welcome.cgi paired with an X-DSCGI-PATH header that points at a traversal path or a temporary file. That pairing is abnormal in legitimate traffic. If you want help turning request shapes like this into production detections tuned to your environment, the detection engineering team at Redfox Cybersecurity can build and validate those rules with you.

Stage 2: Predictable Filename File Planting (CVE-2026-118527)

Once the attacker can execute commands as the web user, they need a way to influence a privileged process. CVE-2026-118527 provides it. File processing on the appliance writes to predictable paths, so an attacker can plant a file at a location a privileged component will later read or execute. In the observed chain, the wu.cgi upload handler accepts a payload and allows an uploaded Perl script to run during the brief window before the handler deletes it.

The predictable-path weakness is why this stage is reliable. The attacker does not have to win a race against a randomly named file; they already know where to write and what will consume it. From a defender's view, the signal is short-lived files appearing under known upload and temp directories, followed immediately by script interpreter execution.

Stage 3: Unauthenticated Privilege Escalation to Root (CVE-2026-111357)

The final stage elevates from the web user to root. CVE-2026-111357 is a missing-authentication flaw on a critical function: the appliance's privileged broker, invoked through dsinvoked, does not properly authenticate the caller for a sensitive operation. In the observed intrusion, the attacker abused this by performing an in-memory patch of the shared library libdsplibs.so, which the root-level broker relies on. Because the escalation operates in memory against a trusted library, it leaves little on disk and sidesteps the Integrity Checker Tool, which is oriented toward on-disk tampering.

The important architectural lesson is that patching only CVE-2026-104935 breaks the front door. Without the initial unauthenticated bypass and RCE, the attacker cannot reach the local escalation primitive in the first place. That is why installing the available fixes is high value even while the privilege-escalation fix rolls out in a later release.

Affected Versions and Fixed Builds for Ivanti Connect Secure

Version math is where teams get caught out, so map your estate carefully.

• CVE-2026-104935 affects ICS versions 25.1.1.1 and prior, 25.1.2.2 and prior, and 22.8R2.4 and prior.
• CVE-2026-111357 and CVE-2026-118527 affect 25.1.1.2 and prior and 22.8R2.5 and prior.
• Versions 22.7.x and earlier do not contain these specific flaws.

Fixed builds include 25.1.1.2 (released 5 October 2026), 22.8R2.5, and the 25.1.3.0 / 25.1.3.1 line. The cleanest target is the latest 25.1.3.x build, then apply Ivanti's privilege-escalation fix as soon as it ships. Do not treat 22.8R2.5 as a finish line for the escalation bug, since that branch is still listed as vulnerable to CVE-2026-111357 and CVE-2026-118527.

How to Check if Your Ivanti Connect Secure Appliance Is Exposed

Start with an inventory of every internet-reachable ICS instance, including ones behind load balancers and in forgotten business units. A quick external fingerprint using the characteristic logo path helps you find them.

# Enumerate candidate ICS hosts from a list and read the reported version banner
while read -r host; do
 ver=$(curl -ks "https://${host}/dana-na/nc/nc_gina_ver.txt" \
       | tr -d '\r' | grep -iE 'version|build' | head -n1)
 printf '%-30s %s\n' "$host" "${ver:-no-banner}"
done < ics_hosts.txt


[cta]

For a scalable, signature-based check across many targets, drive a professional scanner such as Nuclei with the community template for the bypass. Keep scanning scoped to assets you own or are authorized to test.

# Scan an authorized scope for the ICS authentication bypass signature
nuclei -silent \
 -t http/cves/2026/CVE-2026-104935.yaml \
 -l ics_hosts.txt \
 -rl 20 -timeout 10 \
 -o ics_104935_results.txt


[cta]

To confirm patch level programmatically after an upgrade, re-probe the version resource and compare it against the fixed builds. Treat anything below 22.8R2.5 or 25.1.3.x on an affected branch as still in scope for at least part of the chain.

# Flag hosts that are still on a vulnerable build
jq -rn --argjson fixed '["22.8R2.5","25.1.3.0","25.1.3.1"]' '
 inputs
 | select(.build as $b | ($fixed | index($b)) | not)
 | "VULNERABLE: \(.host) build \(.build)"
' ics_versions.jsonl


[cta]

If building this inventory feels bigger than one afternoon, Redfox Cybersecurity runs external attack surface assessments that find the edge devices you forgot you had. You can start that conversation at redfoxsec.com.

Detecting Exploitation: Logs, Network, and Host Signals

Because this intrusion used no web shell and no external C2, detection leans on request patterns, process lineage, and memory. Work all three layers.

Hunting Through Ivanti Connect Secure Web Server Access Logs

The appliance's web access logs under /var/log are your first forensic source. Hunt for unauthenticated hits to the welcome CGI that return HTTP 200 and carry an abnormal routing header. Pull the logs off the appliance first so your analysis does not depend on a device you may not be able to trust.

# Surface suspicious welcome.cgi activity with an abnormal routing header
zgrep -hE 'welcome\.cgi' /var/log/access*.gz /var/log/access* 2>/dev/null \
 | grep -iE 'X-DSCGI-PATH|\.\./|/tmp/' \
 | awk '{print $1, $4, $6, $7, $9}' \
 | sort | uniq -c | sort -rn | head -n 40


[cta]

A single probe is noise. A burst of these requests from one source, each returning 200 and each followed by activity consistent with command execution, is the pattern that matches the observed tradecraft. Map source IPs against your allow lists and known scanner ranges before you escalate.

# Rank source IPs by volume of suspicious welcome.cgi requests
zgrep -hE 'welcome\.cgi' /var/log/access* 2>/dev/null \
 | grep -iE 'X-DSCGI-PATH' \
 | awk '{print $1}' | sort | uniq -c | sort -rn | head -n 20


[cta]

Network Detection with Suricata and Zeek

If the appliance terminates TLS in front of an inspection point, or you can decrypt at a proxy, a Suricata rule that keys on the endpoint and the routing header gives you near-real-time coverage. Tune the thresholds to your baseline before enabling blocking.

alert http any any -> $ICS_GATEWAYS any (
   msg:"Ivanti Connect Secure possible CVE-2026-104935 bypass attempt";
   flow:established,to_server;
   http.method; content:"POST";
   http.uri; content:"welcome.cgi"; nocase;
   http.header; content:"X-DSCGI-PATH"; nocase;
   pcre:"/X-DSCGI-PATH:[^\r\n]*(\.\.\/|\/tmp\/)/Hi";
   classtype:web-application-attack;
   sid:2026104935; rev:1;
)


[cta]

Where you cannot decrypt, Zeek still helps on connection metadata. Watch for repeated POSTs to the auth path from a single external source with unusually uniform request and response sizing, which is consistent with commands and results shuttling through the same requests.

# Zeek: isolate repeated POSTs to the ICS auth path per source
zeek-cut id.orig_h method uri status_code request_body_len response_body_len < http.log \
 | awk '$2=="POST" && $3 ~ /welcome\.cgi/ {print $1, $4, $5, $6}' \
 | sort | uniq -c | sort -rn | head -n 30


[cta]

Host and Memory Forensics

Because the privilege escalation lived in memory and tampered with libdsplibs.so, disk-only checks are not enough. Capture a memory image and core dumps before you reboot or re-image, since a reboot destroys the most valuable evidence. Look for the broker process lineage spawning interpreters and for a hidden working directory. One published indicator is the process dsstatmond executing from a hidden directory.

# Triage running processes for the escalation indicators before rebooting
ps -ef | grep -iE 'dsstatmond|dsinvoked|/tmp/\.' | grep -v grep
ls -la /tmp/.*/ 2>/dev/null
lsof -p "$(pgrep -f dsstatmond 2>/dev/null)" 2>/dev/null


[cta]

For deeper analysis on a captured image, a memory forensics framework such as Volatility 3 lets you inspect loaded libraries and detect a patched libdsplibs.so that does not match the on-disk copy.

# Compare in-memory library mappings against the on-disk hash
vol -f ics_memory.lime linux.library_list.LibraryList \
 | grep -i 'libdsplibs.so'

sha256sum /home/perl/*/libdsplibs.so /usr/lib*/libdsplibs.so 2>/dev/null


[cta]

A YARA rule focused on the escalation artifacts gives you a repeatable way to sweep captured images and file collections across a fleet. Treat the strings below as starting hooks and refine them against your own confirmed samples.

rule Ivanti_ICS_2026_PrivEsc_Artifacts
{
   meta:
       author = "Redfox Cybersecurity"
       description = "Heuristic artifacts for the 2026 ICS escalation chain"
       reference = "CVE-2026-111357 / CVE-2026-118527"
   strings:
       $s1 = "libdsplibs.so" ascii
       $s2 = "dsinvoked" ascii
       $s3 = "dsstatmond" ascii
       $s4 = "wu.cgi" ascii
   condition:
       3 of ($s*)
}


[cta]

Memory-resident intrusions like this are where many in-house teams run out of runway. Redfox Cybersecurity offers incident response and digital forensics support that specializes in edge appliances, and you can reach the team directly at redfoxsec.com.

Indicators of Compromise for the Ivanti Connect Secure Chain

Build these into your SIEM and EDR watchlists, and remember that behavioral indicators outlast any single infrastructure IOC.

• High volume of unauthenticated POSTs to /dana-na/auth/url_default/welcome.cgi returning HTTP 200.
• Requests carrying an X-DSCGI-PATH header that references another CGI resource, a traversal path, or a temporary file.
• Short-lived Perl or script files appearing under upload and temp directories, consumed by wu.cgi almost immediately.
• The process dsstatmond running from a hidden directory.
• Evidence of an in-memory patch to libdsplibs.so where the mapped library diverges from the on-disk file.
• Integrity Checker Tool passing while host and memory artifacts indicate tampering, which itself is a red flag given the in-memory tradecraft.

Remediation and Hardening Steps for Ivanti Connect Secure

Patch first, then verify, then assume nothing until you have hunted.

1. Upgrade affected appliances to a fixed build: 22.8R2.5 or the 25.1.3.x line, and apply Ivanti's privilege-escalation fix as soon as it is released. Do not stop at a build that still carries CVE-2026-111357.
2. Run Ivanti's latest external Integrity Checker Tool, but do not treat a clean result as proof of safety given how the escalation evades on-disk checks.
3. After patching, validate remediation by attempting unauthenticated access to the admin interface and API endpoints and confirming those requests are now refused.
4. Rotate every secret the appliance could reach: local admin credentials, service accounts, API keys, and any certificates or VPN session secrets stored on or brokered by the device.
5. Reduce exposure. Restrict management interfaces to a bastion or VPN, place the gateway behind strict allow lists where feasible, and remove direct internet reachability for administrative paths.

A simple post-patch validation probe confirms the admin surface no longer answers to unauthenticated callers.

# Confirm the admin interface rejects unauthenticated access after patching
curl -ks -o /dev/null -w "%{http_code}\n" \
 "https://ics.target.example/dana-admin/auth/url_admin/welcome.cgi"
# Expect 401, 403, or a redirect to authentication, not 200


[cta]

Incident Response if You Suspect an Ivanti Connect Secure Compromise

If your hunting turns up any of the indicators above, move into response rather than cleanup. The order of operations protects evidence and prevents the attacker from re-entering through infrastructure you have not yet reset.

• Preserve first. Capture memory, core dumps, and disk images before rebooting or re-imaging, because the escalation evidence lives in memory.
• Isolate the appliance from the network, but keep the captured evidence intact for analysis.
• Rebuild from a known-good image rather than attempting in-place remediation on a device that reached root compromise. A clean factory rebuild on a fixed build is the only state you can trust.
• Assume credential exposure for anything the gateway could reach, and reset accordingly across the blast radius, not just on the appliance.
• Hunt laterally. A root foothold on the VPN gateway is an initial access point. Review authentication logs, internal east-west traffic, and any systems the appliance brokered access to for follow-on activity.

Treat the compromised device as a pivot into the wider environment, not an isolated event. If you need surge capacity to run that investigation, the Redfox Cybersecurity response team can plug into your process quickly through redfoxsec.com.

Key Takeaways

The 2026 Ivanti Connect Secure chain is a clear reminder that a fully patched edge appliance is still an assumption worth testing. CVE-2026-104935, CVE-2026-118527, and CVE-2026-111357 combine an authentication bypass, predictable-path file planting, and a memory-resident privilege escalation into unauthenticated root, delivered entirely through the exploit chain's own HTTPS requests with no web shell to find.

Your priorities are straightforward. Inventory every ICS instance, confirm the exact build, and move to 22.8R2.5 or 25.1.3.x now while staging the privilege-escalation fix. Shift detection toward request patterns, process lineage, and memory rather than relying on file-integrity scans. And where indicators appear, preserve evidence, rebuild from clean, rotate secrets across the blast radius, and hunt for lateral movement.

Edge devices like this sit at the intersection of highest exposure and highest trust, which is exactly why they deserve continuous validation rather than annual review. If you want an expert team to pressure-test your VPN and perimeter before an attacker does, Redfox Cybersecurity is ready to help at redfoxsec.com.