Ivanti Says It Fixed Part of a Connect Secure Flaw in July and Was Still Backporting When Attackers Struck

Ivanti disclosed on Tuesday, October 13, that attackers are exploiting an authentication bypass in Ivanti Connect Secure (ICS), its SSL VPN gateway, and says it had patched part of the bug in a July release but was still backporting that fix to its other supported versions when exploitation occurred. The flaw, CVE-2026-104935, lets a remote attacker with no credentials run commands on the appliance. CISA added it to its Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until Friday, October 16 to act.

The disclosure covers only part of what happened. Volexity, the security firm that found the attacks, says the intruders chained three zero-day flaws to get unauthenticated, root-level code execution on an appliance that was fully patched at the time, and Ivanti has not yet fixed the third. Volexity also says the chain leaves nothing for Ivanti’s Integrity Checker Tool to detect, even though Ivanti tells customers to run it regularly.

What Ivanti’s advisory says

Ivanti’s advisory lists one vulnerability and credits Volexity. Ivanti rates it 8.6, High. The weakness is CWE-290, authentication bypass by spoofing, and CISA’s catalog lists the bug as the Ivanti Connect Secure Authentication Bypass by Spoofing Vulnerability. The advisory’s description reads: “Authentication bypass by spoofing in ICS before version 25.1.3.0 allows a remote unauthenticated attacker to execute arbitrary commands.” Ivanti says it is “aware of exploitation in the wild affecting a limited number of customers at the time of disclosure.”

The advisory’s FAQ answers what Ivanti did in response: “Ivanti initially discovered a portion of this vulnerability as part of our product security program and patched it in the July release 25.1.3.0. We had been working to backport the fix to the remaining supported versions when exploitation occurred.” The advisory does not say which part of the bug was fixed in July. It also does not mention the privilege-escalation flaw in Volexity’s chain.

The fixes are spread across three release lines, and the advisory’s table lists affected and resolved versions side by side without pairing them. Its solution text pairs most of them:

Two dates in that text stand out. Ivanti dates 25.1.1.2 to October 5 and 22.8R2.5 to October 12, so fixed builds existed before the advisory and the CISA listing, and 25.1.3.0 has been available since July. Volexity says it opened its investigation on October 5. The sources do not say whether the October 5 release is connected to it.

Three flaws chained, two of them patched

Volexity says it began investigating suspected malicious activity at one of its Network Security Monitoring customers on October 5 and traced it to an ICS appliance running 22.8R2.4 (Build 19097), which was fully patched at the time. With Ivanti’s help it collected memory and disk images and core dumps and used them to reconstruct the exploit chain. The actor, a previously undocumented threat actor that Volexity tracks as UTA0576, was exploiting the appliance from October 3. Defused, a threat intelligence firm, says its decoys recorded activity it assesses as this CVE on October 1, “twelve days before Ivanti’s advisory.”

The chain has three steps, which Volexity describes this way:

1. Authentication bypass in welcome.cgi. The attacker requests the public login page, /dana-na/auth/url_default/welcome.cgi, which needs no authentication, but names a different script in an X-DSCGI-PATH header, such as the protected wu.cgi. In Volexity’s words, “The URL is used to determine whether the request is allowed, while the header path is used to determine the destination of the request.”
2. File write and race in wu.cgi. The attacker uploads a Perl script with a .zip extension. The handler writes it to disk under a name derived from the MD5 of the filename, checks whether it is a valid ZIP only afterward, and then deletes it. Parallel requests that name the file in the same header can run it before the deletion. Volexity says this flaw and the bypass are the two tracked under CVE-2026-104935.
3. Privilege escalation through dsinvoked. The code now runs as the cgi-server user. A privileged background service, dsinvoked, runs maintenance tasks as root and looks up each task’s program in DSCache, a shared configuration store. The exploit patches the in-memory copy of the libdsplibs.so library so it can edit DSCache, points an existing maintenance task at the Perl interpreter, asks the service to run it, and the script runs as root. It then restores the entry and the library patch and removes recent entries from the Ivanti debug log and the Linux audit log.

For the third step, Volexity says Ivanti “is working on a fix for the privilege escalation vulnerability, and it will be included in a future release in the coming weeks.” Neither Volexity nor Ivanti’s advisory gives that flaw a CVE ID. Our reading is that the builds released through October 13 close the first two steps and that the root step stays open until that later release. Volexity adds that the cleanup actions are confirmed in the recovered code, but the extent to which each one completed on the victim appliance has not been fully established.

Why the Integrity Checker will not settle it

Ivanti’s blog post tells customers to “run the Integrity Checker Tool regularly,” and the advisory’s FAQ says there are “limited indicators of compromise available.” Volexity says the tool will not help here: “because this exploit chain patches library code in memory only and restores configuration store data, the tool does not detect any modifications. As such, forensic investigation is required to identify evidence of exploitation.” Its conclusion repeats the warning: “The Ivanti Integrity Checker may not be able to identify device compromise.”

That matters for the federal deadline. The KEV entry carries CISA’s forensic triage flag, and CISA’s BOD 26-04 implementation guidance tells agencies to prioritize “immediate acquisition of volatile data” and to “not alter or remediate systems prior to evidence/artifact collection when possible,” adding that patching “may jeopardize the availability of artifacts.” The guidance’s timelines, which put evidence collection and patching within 2 to 24 hours of a KEV addition, are recommended practice; what BOD 26-04 requires is that “an adequate forensic triage analysis is performed.” Volexity needed memory and disk images and core dumps to reconstruct this chain, because the library patch the exploit applies lives only in memory and the actor removed log entries.

What the attacker did with the access

Volexity says UTA0576 “primarily focused on credential theft, data exfiltration, log tampering, and network reconnaissance.” The actor took domain credentials stored on the appliance, exported limited Active Directory metadata and used the appliance’s Active Directory service account, through a custom Python LDAP tool, to search for Local Administrator Password Solution (LAPS) passwords, BitLocker recovery information and password-bearing attributes. It ran a renamed tcpdump, dsstatmond, from a hidden /data/.icscap directory to record plaintext protocol traffic, and used a script to pull LDAP credentials, HTTP Basic credentials and NTLM challenge-response hashes out of the captures. It also ran password-spraying attacks, tested credentials with a custom Kerberos tool, collected the appliance’s configuration and read authentication logs for valid usernames.

Volexity found no persistent implant. Its post on X says the actor “re-exploited the device for every command it ran,” and the report says commands and results traveled through the exploit chain’s HTTPS requests with no backdoor or web shell on the device. Defused describes what its decoys saw differently: an exploit that ran an unauthenticated bypass “to plant an implant that runs entirely in memory and writes no files to disk,” which it suggests is “potentially why the advisory ships with no reliable IOCs.” Volexity’s report says the actor did write tools and output files to the appliance, some of which it deleted afterward.

The operation was detected and disrupted before the actor’s goals were clear. Volexity “assesses with high confidence that UTA0576’s actions signaled preparation for lateral movement and a broader compromise of the victim network,” and with low confidence that the motive is criminal rather than espionage, “based on the target of this activity.”

Volexity sees language models on both sides

Volexity’s report also contains a notable assessment: “As with many other threat actor operations Volexity has investigated in 2026, Volexity assesses with medium confidence that UTA0576 makes use of large language models (LLMs) for exploit development and post-exploitation activity.” It bases that on “the continuous use of the exploit channel to pass commands to the compromised host (rather than a simpler method such as a web shell), the repeated deployment of highly specific scripts using hardcoded credentials (rather than generic pre-built utilities), and the complexity of the exploit chain.” Those are circumstantial signs; the report does not say which model, if any, was used.

The defenders’ side gets a credit line too. Volexity’s acknowledgements thank OpenAI “for their partnership via the Trusted Access for Cyber (TAC) program” and say “OpenAI’s cyber models have allowed Volexity to drastically reduce its analysis time when it comes to investigating exploits and other incidents of this nature.” We covered another case of suspected AI-assisted intrusion when CrowdStrike tied exposed Claude Code logs to attacks on Korean financial firms.

What to check now

1. Inventory every ICS appliance and its build. Compare each against the table above. A version string says whether the exploit chain could work, not whether it did.
2. Collect memory and disk evidence before upgrading if you suspect compromise. That is CISA’s sequence for federal agencies, and Volexity’s findings explain why it fits this chain. Ivanti’s FAQ points suspected victims to a recovery-steps article, which asks for a customer login.
3. Upgrade to a fixed build, then expect a second update. The privilege-escalation fix is promised in the coming weeks.
4. Hunt for the request pattern. Volexity advises watching for large numbers of requests to /dana-na/auth/url_default/welcome.cgi, which carry an X-DSCGI-PATH header such as /home/webserver/htdocs/dana/fb/smb/wu.cgi, and says “If possible, monitoring for mismatches between the URL path and X-DSCGI-PATH is advisable.” It also warns that “It is likely that threat actors will identify additional paths that can either be used as the URL or header target for this exploit.”
5. Look for the artifacts, and do not treat a clean directory as proof. Volexity lists ml.py, rq5.py, mk.py, rr.py, sp_out.txt, spray_hits.json and pu.txt in /tmp, a password-spraying helper named sp_run.py, and the hidden /data/.icscap directory with a binary named dsstatmond. It also says the actor deleted rq5.py and rr.py after running them. Its published indicators are short: one IP address, 108.165.147[.]64, an Evoxt VPS it saw running an OpenVPN server from September 30 to October 7, and two YARA rules, one matching the exploit’s request header in files or memory and one matching the Python privilege-escalation code in memory.
6. If you find evidence, treat what the appliance could reach as exposed. Volexity’s list of what the actor went after is a reasonable guide: the Active Directory service account used for LDAP, LAPS passwords, BitLocker recovery keys, and credentials that crossed the appliance in plaintext.

How this fits the run of edge-device flaws

CISA’s catalog now lists 36 Ivanti vulnerabilities, 12 of them with known ransomware use, by our count of its JSON feed, which matches BleepingComputer’s tally. Fourteen entries name Connect Secure or its Pulse Connect Secure predecessor, and this is the first since CVE-2025-22457 on April 4, 2025. The new entry’s ransomware field reads “Unknown.” BleepingComputer, citing Shadowserver, counts more than 5,500 ICS instances exposed to the internet but says it is not known how many are honeypots or already secured.

It joins a run of edge-device bugs we have covered in recent weeks: the F5 BIG-IP APM zero-day, two Citrix NetScaler zero-days exploited before a patch existed, a hex-encoding bypass in Cisco SD-WAN Manager, an unpatched FortiMail flaw and a SonicWall SMA1000 flaw probed two days after its patch.

Sources and method

We read Ivanti’s advisory, which is a JavaScript page that we rendered in a headless browser to read its version table, and its blog post; Volexity’s report, its post on X and its indicator files; Defused’s post on X; CISA’s KEV feed and BOD 26-04 guidance; the NVD record; and reporting from BleepingComputer and SecurityWeek. The KEV counts are our own tally of the feed on October 13 (catalog version 2026.10.13), and weekdays were computed from the dates. The NVD entry was marked Undergoing Analysis when we checked, and the 8.6 score on it was supplied by the source that published the record, matching Ivanti’s advisory. The recovery-steps article is behind a customer login and Defused’s full indicators are behind a sign-up, so we could not read either. Ivanti has not said how many customers were affected, and we did not check the Shadowserver figure against its dashboard. We did not test anything on an appliance.