Ivanti Connect Secure Zero-Day CVE-2026-104935: What to Do

Last updated: 26 October 2026. Sources are listed at the end.

Ivanti disclosed a new Ivanti Connect Secure vulnerability, CVE-2026-104935, on 13 October 2026. Attackers had already been using it for about ten days. The flaw is an authentication bypass rated CVSS 8.6. However, the real danger is the chain around it. It gave an unknown group root access to fully patched VPN appliances, with no password needed.

Volexity found the attacks and tracks the group as UTA0576. CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalogue the same day. US federal agencies had until 16 October to fix it. Meanwhile, Ivanti shipped fixes for only two of the three bugs in the chain. The third, a root privilege escalation, was still waiting for a patch at the time of writing.

If your company runs Connect Secure (formerly Pulse Connect Secure) for remote staff, this post is for you. It explains what to patch, what to hunt for and what to do if you find something.

The short answer

• Upgrade now: 22.8R2.4 and older go to 22.8R2.5, 25.1.1.1 and older go to 25.1.1.2, and 25.1.2.x goes to 25.1.3.1.
• Do not treat a clean Integrity Checker Tool (ICT) result as proof of safety. Volexity says this chain can hide from it.
• Hunt for the published indicators in your reverse proxy, WAF and firewall logs, starting from 1 October.
• If you find signs of compromise, factory reset or rebuild the appliance, then rotate every credential it stored.
• Watch Ivanti’s advisory for the privilege escalation fix and install it the day it lands.

What is the Ivanti Connect Secure vulnerability?

Volexity describes three separate bugs that work together. First, an authentication bypass in welcome.cgi lets a request to a public login page reach protected CGI scripts. The attacker does this with a crafted X-DSCGI-PATH header. Then, an upload handler called wu.cgi writes a file before checking that it is a real ZIP. That race window lets the attacker run an uploaded Perl script as a low-privileged web user.

Finally, a root broker process called dsinvoked trusts configuration data that the attacker can tamper with. As a result, commands run as root. Ivanti tracks the first two bugs together as CVE-2026-104935. The third has since received its own ID, CVE-2026-111357, published on 15 October with a CVSS score of 7.0. The Canadian Cyber Centre also noted open-source reports that it is exploited.

According to The Register, Ivanti had already fixed “a portion” of the problem in July’s 25.1.3.0 release. It was still backporting that fix to older branches when the attacks started. So customers on other branches were exposed.

Ivanti Connect Secure vulnerability timeline

What the attackers did

UTA0576 deployed no malware and no web shell. Instead, it re-ran the full exploit for every command. It then rewrote parts of the debug and audit logs to remove traces. According to Volexity, the group stole credentials stored on the appliance, including LDAP domain credentials. It also searched Active Directory for LAPS passwords and BitLocker recovery keys. In addition, it ran Kerberoasting tools, captured LDAP traffic and tried password spraying.

Volexity assesses with low confidence that the motive is criminal rather than espionage. It also believes, with medium confidence, that the actor used AI models to build its tools. Because Volexity disrupted the operation, the final goal is unknown.

How widespread is it?

Ivanti says a limited number of customers were affected at disclosure. Shadowserver counts more than 5,500 internet-facing Connect Secure instances, according to BleepingComputer. The Hacker News cited a figure above 5,600 a day later. Previdian logged 105 exploitation attempts from 50 IP addresses by 14 October. Therefore, scanning for this Ivanti Connect Secure vulnerability is broad, even if confirmed victims are few.

Am I affected?

The table below combines Ivanti’s advisory as quoted by Rapid7, CERT-FR and SOCRadar. We could not load Ivanti’s own advisory page directly, so confirm against it before you upgrade.

There is one conflict to note. CERT-FR lists 25.1.3.x below 25.1.3.1 as affected, while Rapid7 lists 25.1.3.0 as resolved. Therefore, if you are on the 25.1.3 line, go to 25.1.3.1. Also, the 22.x line reaches end of life on 31 January 2027. So plan a move to 25.1 now.

To check your version, log in to the admin console and note the build number it shows. Do this for every appliance, including standby and test units.

What about Ivanti Policy Secure and Neurons for ZTA gateways? Every source we opened, including CISA, CERT-FR and Singapore’s CSA, names only Connect Secure. Earlier flaws such as CVE-2025-22457 hit all three products. So check Ivanti’s advisory for your exact product before assuming you are safe.

How to fix the Ivanti Connect Secure vulnerability

1. Back up the appliance configuration first. Ivanti documents this in KB44759.
2. Upgrade to the fixed build for your branch, using Ivanti’s 25.x Upgrade and Migration Compatibility Guide. Hard2bit reports, citing Ivanti, that 25.1.3 needs newer ISA hardware or new virtual templates, so check before you plan downtime.
3. After upgrading, run the external Integrity Checker Tool. CERT-FR says Ivanti recommends the external version over the internal one. The external tool needs physical or console access and may interrupt service, so schedule it.
4. Restrict the admin interface to an internal management network. Never expose it to the internet.
5. Subscribe to Ivanti’s advisory. When the dsinvoked fix arrives, install it at once.

Until that last fix ships, the chain behind this Ivanti Connect Secure vulnerability is partly broken but not closed. Patching the first two bugs blocks the unauthenticated entry point Volexity documented. However, anyone who already has a foothold could still use the privilege escalation. That is why hunting matters.

How to check if you were already compromised

Ivanti says reliable indicators of compromise are not available. So start with the indicators Volexity published, and look back to at least 1 October. The full list is on Volexity’s GitHub.

Network indicators to look for:

• Many requests to /dana-na/auth/url_default/welcome.cgi.
• An X-DSCGI-PATH request header, especially one whose path differs from the URL. Volexity saw values such as /home/webserver/htdocs/dana/fb/smb/wu.cgi.
• Traffic to or from 108.165.147.64, a VPS used by the attacker.

On-appliance artefacts (collected by Ivanti support or a forensics team):

• Files in /tmp/ such as ml.py, rq5.py, mk.py, rr.py, sp_run.py, pu.txt, sp_out.txt and spray_hits.json.
• A hidden /data/.icscap/ directory holding h.py and rotating cap* files.
• A process named dsstatmond, which was a renamed tcpdump.
• Files named /home/runtime/tmp/ics-root-run-inband-*.pl.
• Gaps in the debug log or audit log during the attack window.

Most SMBs cannot get a shell on the appliance. Instead, search the logs from a reverse proxy, WAF or load balancer in front of it. We tested these commands on a sample log file. They are read-only. Note that the header search only works if your proxy logs request headers.

# Requests carrying the exploit header
grep -n 'X-DSCGI-PATH' /var/log/proxy/access.log*

# Any contact with the published attacker IP
grep -n '108\.165\.147\.64' /var/log/proxy/access.log* /var/log/firewall/*.log

# Source IPs hitting welcome.cgi most often
grep -h 'welcome\.cgi' /var/log/proxy/access.log* | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Adjust the paths for your setup. For compressed rotated logs, use zgrep instead of grep.

A clean result does not prove much, because the attackers edited logs and worked in memory. CISA says confirming compromise needs network and memory forensics. For virtual appliances, CERT-FR advises taking a snapshot of the disk and RAM before you power anything off.

If you find signs of compromise

CISA’s and CERT-FR’s guidance lines up closely. Follow it in this order:

1. Back up the configuration.
2. Factory reset the appliance and upgrade it. For cloud or virtual systems, rebuild a fresh instance instead.
3. Restore the configuration from the backup.
4. Reset passwords for all domain, admin and local accounts, including service accounts used for LDAP or RADIUS.
5. Revoke and reissue certificates stored on the appliance, including the TLS certificate for the public interface.
6. Reset stored API keys and license server credentials.
7. Rotate BitLocker recovery keys and LAPS passwords if Active Directory queries could have exposed them. Also reset Kerberos service account passwords, since Kerberoasting was observed.

CERT-FR also warns that some threats can survive a factory reset. So in sensitive environments, consider replacing the device image entirely.

The India angle

We could not find a CERT-In advisory for this Ivanti Connect Secure vulnerability at the time of writing. Even so, Connect Secure is common in Indian enterprises and IT service companies. If you confirm a compromise, remember the CERT-In Directions of April 2022. Covered entities must report certain cyber incidents to CERT-In within six hours of noticing them.

If the attacker reached systems holding personal data, also start preparing for the DPDP Rules. Rule 7 will require breach notices and a detailed report to the Data Protection Board within 72 hours. However, that rule applies only from May 2027 and is not in force yet. Our free DPDP readiness check can help you plan.

Quick checklist

• ☐ Find every Connect Secure appliance you run, including test and DR boxes
• ☐ Note each build number from the admin console
• ☐ Back up the configuration
• ☐ Upgrade to 22.8R2.5, 25.1.1.2 or 25.1.3.1
• ☐ Run the external Integrity Checker Tool after the upgrade
• ☐ Search proxy, WAF and firewall logs from 1 October for the indicators above
• ☐ If anything matches, snapshot memory, then factory reset or rebuild
• ☐ Rotate domain, admin, local and service account passwords, certificates and API keys
• ☐ Rotate BitLocker keys and LAPS passwords if exposure is possible
• ☐ Track Ivanti’s advisory for the privilege escalation fix
• ☐ Plan migration off 22.x before 31 January 2027

VPN gateways keep turning up in these incidents. For example, our post on the k0t firewall and VPN credential campaign covers a similar pattern on FortiGate and GlobalProtect. Need a second pair of eyes on your perimeter? Our VAPT services include external testing of VPN and remote access gateways.

Sources

• Volexity: A Series of Unauthenticated Events, chained exploitation of Ivanti Connect Secure zero-days
• Rapid7: Ivanti Connect Secure zero-day exploited in the wild (CVE-2026-104935)
• CERT-FR: CERTFR-2026-ALE-013, Vulnérabilité dans Ivanti Connect Secure
• Canadian Centre for Cyber Security: Ivanti security advisory AV26-1035
• Singapore CSA: Active Exploitation of Vulnerability in Ivanti Connect Secure (AL-2026-147)
• BleepingComputer: Ivanti warns of Connect Secure zero-day exploited in attacks
• BleepingComputer: CISA warns admins to immediately fix Ivanti flaw exploited as zero-day
• The Hacker News: Attacker chains three Ivanti Connect Secure zero-days for root access

Need help with network security? We test routers, firewalls, ACLs and segmentation as part of our VAPT services and hardening audits. Contact us for a quote.