Ivanti Connect Secure: attackers chain three flaws to take over the VPN gateway

What happened

Ivanti Connect Secure is a VPN gateway that lets staff reach the company network from outside. Attackers are now combining three flaws in it:

The security firm Volexity uncovered the attacks while monitoring a customer's network. Its investigation began on 5 October 2026 and traced the activity back to 3 October. The gateway was running 22.8R2.4 (Build 19097), the newest version available at the time. Volexity tracks the attacker as UTA0576, a previously unknown group.

Ivanti fixed the authentication bypass on 13 October, the day CISA added it to the Known Exploited Vulnerabilities (KEV) catalog. The privilege escalation was patched on 29 October, and on 30 October 2026 CISA added CVE-2026-111357 and CVE-2026-118527 to KEV as well. All three are being exploited in real attacks.

Technical details

Volexity published a detailed breakdown. In short, the chain has three stages:

1. Authentication bypass (CVE-2026-104935, CWE-290). A public sign-in page, /dana-na/auth/url_default/welcome.cgi, accepts an X-DSCGI-PATH header that names which CGI script to run. The gateway checks access against the public URL, not against the script in the header, so an unauthenticated request can reach protected functionality.
2. Code execution. Through a file upload handler, the attacker briefly gets a file of their choosing onto disk in a temporary directory and has it executed before the gateway deletes it. The payload runs in memory as a chain of Perl, Bash and Python.
3. Root (CVE-2026-111357, CWE-829). A privileged service, dsinvoked, runs maintenance tasks as root and looks up which program to start in a configuration store called DSCache. The exploit changes a library in memory so that a task points to the attacker's script, which then runs as root. Afterwards it restores both the DSCache entry and the library.

CVE-2026-118527 (CWE-340, predictable filenames) covers the "predictable location on disk" part. The full chain runs again for every command, and the output comes back in the HTTP response. Volexity found no web shell or backdoor, and that's exactly why on-disk checks see nothing.

After getting in, the attacker:

• pulled credentials stored on the gateway, including the LDAP account used to query Active Directory,
• searched Active Directory for LAPS administrator passwords, BitLocker recovery keys and attributes containing passwords,
• ran Kerberoasting and password spraying tools,
• captured LDAP traffic with a renamed copy of tcpdump to harvest more credentials,
• deleted entries from the gateway's debug and audit logs and cleaned up its own files.

Volexity says it has not fully established how far each step succeeded. It assesses with low confidence that the group is criminally motivated, and with medium confidence that it uses large language models to develop exploits and tooling.

Who is affected

Organisations running Ivanti Connect Secure. According to the Canadian Centre for Cyber Security, vulnerable versions are those:

• before 22.8R2.6,
• before 25.1.1.3,
• before 25.1.3.1.

The NVD records differ slightly from flaw to flaw – for example, the authentication bypass doesn't affect 22.7R2.14 and older. The safe choice is the newest build in your release line. People who just sign in to the company VPN aren't directly affected; this is a job for the IT team.

How to tell if you were compromised

Volexity published these indicators:

• Many requests to /dana-na/auth/url_default/welcome.cgi with an X-DSCGI-PATH header pointing to /home/webserver/htdocs/dana/fb/smb/wu.cgi or to a file in /home/runtime/tmp/. Generally, watch for requests where the URL path and the X-DSCGI-PATH header don't match.
• Files in /tmp/ such as ml.py, rq5.py, mk.py, rr.py, pu.txt, sp_out.txt and spray_hits.json, plus JSON exports of Active Directory queries.
• A hidden directory /data/.icscap/ containing cap* capture files, a h.py script, or a process called dsstatmond (a renamed tcpdump) running from it.
• Gaps in the logs – missing or truncated entries in /home/runtime/dlogs/debuglog and /var/log/audit/audit.log.
• Connections to 108.165.147[.]64, the server Volexity linked to the operator.

Exported logs can run to thousands of lines. Our IOC extractor pulls the IP addresses and domains out of them into a clean list, and it runs entirely in your browser. Don't rely on the Integrity Checker Tool here: according to Volexity it missed this compromise.

Once inside, the attacker went after Active Directory, so review the Security log on your domain controllers too. Look for the LDAP service account signing in from anywhere other than the gateway or at odd hours (events 4624 and 4768), an unusual burst of Kerberos service ticket requests from a single account (4769 – a sign of Kerberoasting), and runs of failed sign-ins across many different accounts (4625 and 4771 – a sign of password spraying). Our Windows event ID lookup explains what each event means and which fields to check. This check is our recommendation based on what the attacker went after; Volexity doesn't spell it out.

What to do

1. Find your version in the Ivanti Connect Secure admin interface.
2. Update to a fixed version from Ivanti's advisory (linked in the sources). Ivanti keeps adding to the page, so make sure you have the latest build. CISA's deadlines for US federal agencies (16 October, 2 November and 13 November 2026) show how urgent it is.
3. Check for compromise using the indicators above. If anything looks suspicious, arrange network and memory forensics – the gateway's own tools aren't enough.
4. If you find signs of compromise, treat every credential stored on the gateway as stolen (such as the LDAP service account) and rotate it. Then check what that account could read: LAPS passwords and BitLocker recovery keys may need rotating too. This step is our recommendation based on what the attacker went after; Volexity doesn't spell it out.
5. Report the incident to your national authority – in the US to CISA, in the UK to the NCSC.

Timeline