CVE-2026-104935: Ivanti Zero-Day Needs a Hunt
Ivanti’s Connect Secure VPN has another exploited zero-day. Attackers chained it to root access, harvested Active Directory credentials, and then cleaned up after themselves so thoroughly that Ivanti’s own Integrity Checker did not notice. A patch is out. One link in the chain is still unpatched, and CISA wants federal agencies done by Friday.
What: CVE-2026-104935, an authentication bypass by spoofing (CWE-290) in Ivanti Connect Secure that lets an unauthenticated remote attacker run commands. CVSS v3 8.6 (High).
Status: Exploited as a zero-day against “a limited number of customers,” per Ivanti. Added to CISA’s Known Exploited Vulnerabilities catalog on October 13, 2026. A separate privilege-escalation flaw used in the same chain has no fix yet.
Deadline: Friday, October 16, 2026 for federal civilian agencies, according to KEV data reported by two trackers. CISA’s required action also references forensic triage, not just patching.
Fix: Upgrade to 25.1.1.2, 25.1.3.0/25.1.3.1 or 22.8R2.5 depending on your code line. Ivanti describes no workaround. Then investigate: patching does not tell you whether you were already breached.
Key takeaways
- Ivanti Connect Secure CVE-2026-104935 is fixed in 25.1.1.2, 25.1.3.0, 25.1.3.1 and 22.8R2.5. Versions 22.7.x and earlier are not affected, according to Ivanti.
- The federal deadline is October 16, 2026, three days after CISA added the flaw to KEV on October 13.
- Attackers reached root, not just a login. Volexity says actor UTA0576 combined the bypass with a code-execution path and a second, still-unpatched privilege-escalation bug.
- Ivanti’s Integrity Checker Tool did not catch this chain, because the exploit patched code only in memory and restored what it changed. Plan for memory and network forensics.
- The target was your directory. The actor sniffed LDAP traffic, pulled the appliance’s stored domain credentials, hunted LAPS passwords and BitLocker keys, and password-sprayed Active Directory.
Executive Summary
This is a VPN zero-day whose real payload is your Active Directory.
On October 13, Ivanti disclosed CVE-2026-104935 in Connect Secure and confirmed exploitation before disclosure. CISA added it to KEV the same day. Volexity, which found the activity while monitoring a customer network in early October, published a full reconstruction of the attack. According to Volexity, exploitation on the appliance it investigated began on October 3.
The chain works in three steps. A request to a public login page carries a header that redirects it to a protected script. That script accepts an uploaded file and briefly stores it before validation, which the attacker races to execute. Finally, a separate local flaw lets the attacker run commands as root. Ivanti’s patch covers the first two steps under CVE-2026-104935. Ivanti says it is still working on the third.
The bottom line: patch every Connect Secure appliance before Friday, treat any appliance that was internet-facing since October 1 as possibly compromised, and rotate the directory credentials it held.
Why This Matters to CISOs and Security Leaders
The cleanup was the sophisticated part. Volexity says the attacker removed log lines, deleted its own scripts, put the modified configuration entry back, and restored the patched byte in memory. No web shell or backdoor was found. The on-disk library was never modified. That is why the Integrity Checker came back clean, and why “we ran ICT and it passed” is not evidence of safety.
A VPN appliance is a credential vault. Connect Secure stores the service credentials it uses to query LDAP, and it sees authentication traffic for your whole remote workforce. Volexity observed the actor capturing packets to harvest plaintext LDAP and HTTP Basic credentials and NTLM hashes. A compromised gateway can hand over far more than one device.
AI-assisted operators are moving faster. Volexity assesses with medium confidence that UTA0576 used large language models for exploit development and post-exploitation tooling. That echoes what CrowdStrike described in the ARTEX AI-driven bank intrusions: fewer people, more custom tooling, shorter timelines.
Edge-device fatigue is the attacker’s ally. Teams that just worked through the NetScaler SAML zero-day CVE-2026-88779 and the FortiMail CVE-2026-104286 compromise checks now have a third edge emergency in two weeks.
Ask your team two questions today: “Which service account does our Ivanti VPN use for LDAP, and when was its password last changed?” If nobody knows, assume an attacker who reached root could know it too.
The Timeline
| Date (2026) | What happened |
|---|---|
| July | Ivanti fixes part of the flaw, found internally, in Connect Secure 25.1.3.0. Backports to other code lines are still in progress when exploitation starts. |
| Sept 30 – Oct 7 | Attacker-linked VPS 108.165.147[.]64 runs an OpenVPN server, per Volexity |
| Oct 1 | Earliest exploitation signs, according to one report citing Defused (single-source) |
| Saturday, Oct 3 | Exploitation of the appliance Volexity investigated begins |
| Monday, Oct 5 | Volexity starts its investigation at a monitored customer |
| Tuesday, Oct 13 | Ivanti publishes its advisory and fixed builds; Volexity publishes its analysis; CISA adds CVE-2026-104935 to KEV |
| Friday, Oct 16 | CISA remediation deadline for federal civilian agencies |
| Unknown | Fix for the privilege-escalation flaw used in the chain |
The exploit put everything back the way it found it. Your integrity check is looking for damage the attacker already repaired.
Vulnerability & Exploit Analysis
How the chain works
Step 1, authentication bypass: Volexity says the attacker sends a request to the public path /dana-na/auth/url_default/welcome.cgi with an X-DSCGI-PATH header that points at a protected script, such as /home/webserver/htdocs/dana/fb/smb/wu.cgi. The appliance routes the request there without authentication.
Step 2, code execution: The attacker uploads a Perl script disguised as a .zip. It lands in /home/runtime/tmp/ under an MD5-based name before validation, and the attacker executes it before it is deleted. Ivanti tracks steps 1 and 2 as CVE-2026-104935.
Step 3, root: A separate flaw lets the attacker patch libdsplibs.so in memory, alter a DSCache maintenance task, and have the dsinvoked broker run Perl as root. This bug has no CVE ID in public reporting and no fix yet.
Volexity notes the attacker re-ran the chain for every command and read the output straight from the HTTP response, rather than leaving a persistent implant.
Affected and fixed versions
| Code line | Vulnerable | Fixed in |
|---|---|---|
| 25.1.1.x | 25.1.1.1 and earlier | 25.1.1.2 |
| 25.1.2.x / 25.1.3.x | 25.1.2.2 and earlier | 25.1.3.0 or 25.1.3.1 |
| 22.8.x | 22.8R2.4 and earlier | 22.8R2.5 (one report says Ivanti recommends moving to 25.1.1.2 or later instead) |
| 22.7.x and earlier | Not affected, per Ivanti | No action for this CVE |
Whether Ivanti Policy Secure, ZTA gateways or Neurons for Secure Access are affected is unknown: public reporting says the advisory names only Connect Secure. Ivanti describes no workaround, so upgrading is the only fix.
The chain’s root step is not covered by the patch. Today the bypass is the front door to it, so patching CVE-2026-104935 closes the path Volexity saw. But any other bug that gets code running on the appliance, past or future, can reuse that unpatched root step. Track Ivanti’s follow-up release as closely as this one, and don’t close the ticket when the upgrade finishes.
Threat Intelligence Breakdown
Attribution: Volexity tracks the actor as UTA0576 and does not link it to a known group. It assesses with low confidence that the motive is criminal rather than espionage, based on the targets. One KEV tracker shows the CISA entry as not linked to ransomware (single-source). Victim count is unknown beyond Ivanti’s “limited number of customers.”
Tradecraft: After reaching root, the actor ran a renamed tcpdump called dsstatmond from a hidden /data/.icscap/ directory, parsed captures for credentials, queried LDAP for LAPS passwords, BitLocker recovery keys and password attributes, tested Kerberos credentials, attempted Kerberoasting and password-sprayed AD accounts. It then trimmed recent entries from debuglog and audit.log.
Indicators of compromise (Volexity, defanged; Ivanti says no reliable IoCs are available yet):
| Type | Indicator | Context |
|---|---|---|
| IP address | 108.165.147[.]64 | Attacker VPS (Evoxt); ran OpenVPN Sept 30 – Oct 7 |
| HTTP request | /dana-na/auth/url_default/welcome.cgi with an X-DSCGI-PATH header pointing to wu.cgi or /home/runtime/tmp/ |
Authentication bypass; alert on any path/header mismatch |
| Hidden directory | /data/.icscap/ (capture files cap*, h.py, process dsstatmond) |
Packet capture and credential parsing |
| Files in /tmp | ml.py, rq5.py, mk.py, rr.py, pu.txt, sp_out.txt, spray_hits.json |
LDAP, Kerberos and password-spraying tools and output |
| Temp payloads | /home/runtime/tmp/ics-root-run-inband-*.pl, ics-root-result-inband-* |
Self-deleting root-execution scripts |
| Config tampering | DSCache task normally pointing to /home/bin/updateOpswatSDK.pl |
Hijacked to run Perl as root, then restored |
How to read these: the IP will age quickly. The header mismatch and the hidden capture directory are the durable signals. Volexity says further indicators are on its GitHub repository.
Enterprise Impact: What’s Actually at Risk
Directory credentials: The LDAP bind account stored on the appliance, plus any credentials that crossed it in plaintext, should be treated as exposed on any compromised device.
Endpoint secrets: LAPS local-admin passwords and BitLocker recovery keys are exactly what the actor searched for. If the LDAP account could read them, rotate them.
Remote access for everyone: Connect Secure fronts the whole remote workforce. An emergency upgrade or rebuild will interrupt access, so communicate early.
Audit and compliance: CISA’s required action points to forensic triage, not just patching. Document when you upgraded, what you checked and what you found. A clean ICT result alone will not satisfy that.
What Security Leaders Should Do Next
Today
- Inventory every Connect Secure appliance and record its code line and build.
- Preserve evidence first: export logs, back up configuration and, where possible, capture memory before upgrading.
- Upgrade to 25.1.1.2, 25.1.3.0/25.1.3.1 or 22.8R2.5 as applicable, as an emergency change.
- Add a detection for requests to
welcome.cgicarrying anX-DSCGI-PATHheader, and block 108.165.147[.]64.
Within 48 hours
- Hunt for
/data/.icscap/, the/tmpartifacts and processes running from hidden directories. Don’t rely on the Integrity Checker alone. - Rotate the LDAP service account and any credentials configured on the appliance.
- Check Active Directory for password-spray patterns, Kerberos service-ticket requests and LDAP queries for LAPS or BitLocker attributes from the VPN’s address.
- If anything matches, run an incident: follow Ivanti’s recovery steps, rebuild the appliance and rotate LAPS and BitLocker secrets in scope.
When the privilege-escalation fix ships
- Apply it immediately and confirm on every appliance.
- Reduce what the VPN can read: make sure its LDAP account cannot read LAPS or BitLocker attributes, and use LDAPS rather than plaintext LDAP.
- Put Connect Secure on a short leash in your edge-device program, with a named owner and a tested replacement or rebuild plan given its history of zero-days.
Get zero-day alerts before they hit the headlines
DataWater’s executive threat briefing: the exploited CVEs, the deadlines and the first three actions to take.
Winners and Losers
| Better positioned | More exposed |
|---|---|
| Organizations still on 22.7.x or already on 25.1.3.0 from July | 22.8.x and older 25.1 builds waiting on backports |
| Teams with network monitoring in front of the VPN | Teams relying only on the Integrity Checker |
| VPN service accounts with least-privilege LDAP rights over LDAPS | Broad LDAP bind accounts that can read LAPS and BitLocker data |
| Teams that captured memory and logs before upgrading | Teams that upgraded first and lost the evidence |
Final Executive Takeaway
Patching the Ivanti zero-day is necessary and not sufficient.
The attacker went for directory credentials and covered its tracks well enough to pass Ivanti’s own checker, and one step of the chain still has no fix.
Upgrade by Friday. Rotate the VPN’s directory credentials. Investigate as if the checker can’t see what happened, because it couldn’t.
Frequently Asked Questions
What is Ivanti Connect Secure CVE-2026-104935?
CVE-2026-104935 is an authentication bypass by spoofing (CWE-290) in Ivanti Connect Secure that lets a remote, unauthenticated attacker execute commands on the VPN appliance. It is rated CVSS v3 8.6 and was exploited as a zero-day before Ivanti disclosed it on October 13, 2026.
Which Ivanti Connect Secure versions fix CVE-2026-104935?
Ivanti fixed CVE-2026-104935 in Connect Secure 25.1.1.2, 25.1.3.0, 25.1.3.1 and 22.8R2.5. Versions 22.7.x and earlier are not affected, according to Ivanti. There is no workaround, so upgrading is the only fix.
What is the CISA deadline for Ivanti Connect Secure CVE-2026-104935?
CISA added Ivanti Connect Secure CVE-2026-104935 to its Known Exploited Vulnerabilities catalog on October 13, 2026, with a remediation due date of October 16, 2026 for federal civilian agencies, according to KEV tracking data. The required action also references forensic triage.
Does Ivanti’s Integrity Checker Tool detect the CVE-2026-104935 attacks?
Not reliably. Volexity reports that Ivanti’s Integrity Checker Tool did not detect the CVE-2026-104935 exploit chain, because the attacker modified code only in memory and restored configuration and logs afterward. Memory and network forensics are needed to rule out compromise.
Who is exploiting the Ivanti Connect Secure zero-day?
Volexity tracks the actor exploiting Ivanti Connect Secure CVE-2026-104935 as UTA0576 and does not tie it to a known group. Volexity assesses with low confidence that the motive is criminal, and with medium confidence that the actor uses large language models to build its tools.
Is the full Ivanti Connect Secure attack chain patched?
No. The Ivanti Connect Secure patch for CVE-2026-104935 covers the authentication bypass and code-execution steps, but a separate privilege-escalation flaw used to gain root was still unpatched as of October 14, 2026. Ivanti says a fix will come in a future release.
What should I check after patching Ivanti Connect Secure for CVE-2026-104935?
After upgrading Ivanti Connect Secure, look for requests to welcome.cgi with an X-DSCGI-PATH header, the hidden /data/.icscap/ directory, Python tools in /tmp and traffic to 108.165.147[.]64. Rotate the appliance’s LDAP credentials and review Active Directory for password spraying and LAPS or BitLocker queries.
Sources
Primary sources: Volexity, “A Series of Unauthenticated Events” (October 13, 2026); Ivanti October 2026 Security Update (October 13, 2026); CISA Known Exploited Vulnerabilities catalog entry for CVE-2026-104935 (date added and due date as reported by Senserva’s KEV tracker). Additional reporting reviewed: Rapid7, watchTowr, Forkast and WindowsForum (Shadowserver exposure figure and Defused timing, single-source). Reflects public reporting as of October 14, 2026.
