Three Ivanti Connect Secure vulnerabilities, CVE-2026-104935, CVE-2026-111357 and CVE-2026-118527, are now in CISA's Known Exploited Vulnerabilities (KEV) catalog. Volexity documented the first two chained together: an unauthenticated authentication bypass that leads to remote code execution, then a privilege escalation to root, used in real attacks before Ivanti had a fix. If you run Ivanti Connect Secure, update to the latest build for your branch, hunt for the request patterns below, and treat credentials the appliance could read as exposed if you were reachable from the internet.
This is a VPN gateway story, not a coding-agent bug. It still matters to anyone running coding agents: developer laptops, CI runners and the agents on them usually reach internal repos, package mirrors and cloud accounts through exactly this kind of appliance. Volexity also assesses that the attacker used large language models to build the chain, which fits the pattern we covered in AI-led attacks in October 2026.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | Ivanti Connect Secure (ICS) before 25.1.3.0 for CVE-2026-104935; before 25.1.1.3 and 22.8R2.6 for CVE-2026-118527; 22.8R2.4 and the builds around it for CVE-2026-111357 |
| Is it exploited? | Yes. All three are in CISA KEV; Volexity saw real intrusions starting around October 3, 2026 |
| Is there a fix? | Yes. Patches for the auth bypass shipped October 13; the root escalation fix followed October 29 |
| Can I rely on the Integrity Checker? | No. Volexity says it did not flag this activity |
| Does data leave my machine? | Not from patching. A compromised gateway can expose stored credentials and the traffic that passes through it |
| Does this involve AI coding agents? | Not directly. Agents run on the machines and networks this appliance protects |
What the sources say
Ivanti's security advisory for CVE-2026-104935 is the vendor reference for the October releases. We could not load its full text in an automated fetch, so the version and scoring details below come from the CVE records mirrored in Beam's database and from Volexity's research. Check the advisory directly for your exact build.
The Beam CVE database records the three entries:
- : authentication bypass by spoofing, CVSS 8.6 (high), allowing a remote unauthenticated attacker to execute arbitrary commands. ICS before 25.1.3.0 is affected; 22.7R2.14 or prior is not. CISA added it to KEV on October 13, 2026.
- : missing authentication for a critical function, CVSS 7.0 (high). In ICS 22.8R2.4, the
dsinvokedbroker trusts DSCache configuration data, which leads to privilege escalation to root. Added to KEV on October 30. - : predictable filenames, CVSS 4.3 (medium). ICS before 25.1.1.3 and 22.8R2.6 lets an authenticated attacker upload files with attacker-controlled content to a known location on disk. Also added to KEV on October 30.
The CISA entries carry the standard instruction: apply vendor mitigations under BOD 26-04, follow the forensic triage requirements, and discontinue use if mitigations are not available. The federal due dates ranged from October 16 to November 13. You can see the vendor-level view on Beam's .
The attack chain, step by step
Volexity's write-up describes five stages. We have not reproduced the exploit; this is Volexity's account.
- Authentication bypass through
welcome.cgi. The public login script/dana-na/auth/url_default/welcome.cgiroutes requests to other CGI scripts. The URL path is what gets access-checked, but anX-DSCGI-PATHheader decides the real target. An attacker can therefore reach protected scripts without logging in. - File write and code execution via
wu.cgi. The attacker uploads a Perl script disguised with a.zipextension. The handler writes it to disk before checking whether it is a valid ZIP and deleting it. Parallel execution requests, sent through the same header, win a race against that deletion. - A staged, memory-only payload. The Perl script runs a Bash script, which runs a Python script that is Base64- and zlib-encoded and executed with
exec(). It never has to sit on disk as a recognisable file. - Privilege escalation to root. The attacker patches the in-memory copy of
libdsplibs.soinside the cgi-server process. That lets them change a DSCache maintenance task so the privilegeddsinvokedservice runs a malicious Perl script as root. The exploit tests for success by checking whether/etc/shadowis readable. This is the step tracked as CVE-2026-111357. - Cleanup. The exploit restores the DSCache entry and library memory, then edits the Ivanti debug log and the Linux audit log to remove entries from the attack window.
Volexity found no persistent backdoor or web shell. Each command was delivered by replaying the whole exploit chain and reading the output from the HTTP response. That design leaves very little on the appliance afterwards, which is why the vendor's own integrity tooling missed it.
Timeline
- About October 3, 2026: exploitation begins on a victim's ICS appliance, per Volexity.
- October 5: Volexity starts investigating suspicious activity at a network security monitoring customer.
- October 13: Volexity publishes; Ivanti releases fixes for CVE-2026-104935; CISA adds it to KEV.
- October 29: the fix for the privilege escalation, CVE-2026-111357, is published.
- October 30: CISA adds CVE-2026-111357 and CVE-2026-118527.
- November 3: CVE-2026-118527 is published in the vulnerability databases.
The gap matters. For about two weeks after the first fix, the root-escalation half of the chain had no patch, so patched-for-the-bypass was not the same as safe.
Who is behind it, and the AI angle
Volexity tracks the actor as UTA0576, previously unknown. It assesses with low confidence that the motive is criminal rather than espionage. It also assesses, with medium confidence, that the actor used large language models for exploit development and post-exploitation work, based on the complexity of the chain and the use of highly specific, hardcoded scripts.
Treat that as an assessment. Volexity does not claim to have seen the prompts. Still, it is the same direction as OpenAI's report on a pipeline of kernel privilege-escalation exploits: the cost of turning a bug class into a working multi-stage chain is falling, so the gap between disclosure and exploitation is shrinking.
What the attacker did after getting in
Volexity lists post-exploitation work aimed at identity:
- extracting stored credentials such as an LDAP service account;
- searching Active Directory for LAPS passwords, BitLocker recovery keys and attributes that hold passwords;
- running a custom Kerberoasting tool and a password-spraying helper;
- parsing an existing packet capture for LDAP, HTTP Basic and NTLM credentials;
- collecting DNS settings, configuration files and authentication logs to find valid usernames.
Results went back over the exploit channel, with no separate command-and-control. For a developer organisation, the practical reading is that the appliance is a credential vault in disguise: anything that authenticated through it, or that it used to talk to the directory, is in scope.
What this means if you run AI coding agents
Coding agents inherit the trust of the network they sit on. If a VPN gateway is compromised, the agent's reach to internal Git, package registries and cloud consoles is reachable too.
1. Patch and verify. Update ICS to the latest build for your branch and confirm the fix for CVE-2026-111357 is included, not just the October 13 release. Do not stop at CVE-2026-104935.
2. Hunt, do not rely on the Integrity Checker. Volexity says to look for high volumes of requests to welcome.cgi, especially where the URL path and the X-DSCGI-PATH header do not match, and for headers pointing at /home/webserver/htdocs/dana/fb/smb/wu.cgi or /home/runtime/tmp/. Check /tmp/ for post-exploitation files such as ml.py, rq5.py, mk.py, rr.py and sp_out.txt, and /data/.icscap/ for h.py and capture files, including a renamed tcpdump called dsstatmond. The one host indicator Volexity published is 108.165.147[.]64. Because logs were edited, absence of evidence is weak. Take memory and network forensics on suspect devices.
3. Rotate what the appliance held. LDAP and service accounts, local accounts, certificates, and anything users typed into it. If an exposed, unpatched appliance was reachable from October 3 onward, assume credentials could have been harvested.
4. Shrink what an agent can reach through the VPN. Give agents scoped, short-lived tokens, not a developer's long-lived personal credentials. Compare this to the lesson in the GitLab CVE-2026-97229 exploitation: when infrastructure falls, tokens held by agents fall with it.
5. Watch for stolen-token reuse. Stolen credentials are often used from the agent side next. Our write-up on infostealers targeting Claude Code and Codex tokens shows what that follow-on looks like on a developer machine.
What Beam can and cannot do here
Beam does not patch, scan or monitor VPN appliances, and it cannot see an attack on Ivanti. What it covers is the developer endpoint: it watches what Claude Code, Codex and similar agents do locally, flags credential exposure and risky commands, and keeps events on-device. If stolen VPN or directory credentials were used to drive an agent, or if an agent was made to read secrets, those local actions are what Beam's hooks and rules surface. Its deny is hook-based for Claude Code and Codex, not a kernel sandbox, and its scanning is heuristic. See how Beam works and what it watches.
Where this sits in November's attacks
The Ivanti chain adds to a run of exploited infrastructure: gateways, GitLab, and cloud control planes. For wider context see the November 2026 attacks timeline. Another example of attackers combining automation and orchestration against developer-adjacent systems is the CyberStrikeAI domain takeover analysis.
Frequently asked questions
Which Ivanti Connect Secure CVEs are being exploited?
CISA lists CVE-2026-104935 (authentication bypass, added October 13), CVE-2026-111357 (privilege escalation to root, added October 30) and CVE-2026-118527 (predictable filenames allowing file upload, added October 30). Volexity documented the first two chained together in real attacks.
Which versions are affected and fixed?
CVE-2026-104935 affects Connect Secure before 25.1.3.0 and does not affect 22.7R2.14 or earlier. CVE-2026-118527 affects versions before 25.1.1.3 and 22.8R2.6. Volexity reports that the fix for CVE-2026-111357 was published on October 29, 2026. Check the Ivanti advisory for the build matching your branch.
Does Ivanti's Integrity Checker Tool detect this attack?
Not according to Volexity. The exploit patches memory and restores configuration data and logs afterwards, so the Integrity Checker did not flag it. Volexity recommends network and memory forensics on suspect devices.
Did attackers use AI to build this exploit?
Volexity assesses with medium confidence that the actor, tracked as UTA0576, used large language models for exploit development and post-exploitation scripting. It is an assessment based on the chain and the scripts, not a confirmed fact from the attacker.
What should I rotate after a possible compromise?
Anything the appliance stored or could read: LDAP and service account credentials, local accounts, certificates and keys, and credentials of users who authenticated through it. Also review directory secrets the actor searched for, such as LAPS passwords and BitLocker recovery keys.
Related reading
- GitLab CVE-2026-97229 exploited: CISA KEV and what to rotate
- AI-led attacks in October 2026
- OpenAI's kernel privilege-escalation exploit pipeline
- November 2026 attacks timeline
- Sources: Volexity, Ivanti advisory, CISA KEV catalog, NVD CVE-2026-118527
Versions, dates and indicators are accurate as of November 5, 2026, and may change as Ivanti and Volexity update their guidance. Check the vendor advisory before acting.