What Ivanti disclosed
The bug is CVE-2026-104935. BleepingComputer reports that it affects ICS 22.8R2.4 and earlier, 25.1.2.2 and earlier, and 25.1.1.1 and earlier. A remote attacker with no privileges can exploit it in a low-complexity attack, with no user interaction, to run arbitrary commands on the appliance.
The published CVE record fills in the technical details:
- Weakness class: Authentication bypass by spoofing in ICS before version 25.1.3.0 allows a remote unauthenticated attacker to execute arbitrary commands. In other words, the appliance accepts an identity the requester never proved. This is classified as CWE-290.
- Score: Ivanti, acting as the CVE numbering authority, rated it 8.6 (High), with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L
- Scope boundary: the record says the bug does not impact ICS version 22.7R2.14 or prior.
Ivanti's advisory says it is "aware of exploitation in the wild affecting a limited number of customers at the time of disclosure." The company also said it is working directly with affected organizations. It told customers to read the advisory, upgrade to a fixed version as soon as possible and run its Integrity Checker Tool (ICT) regularly.
Why does an 8.6 get this much attention? The score reflects the CVSS formula, not what's at stake in practice. The vulnerable device faces the internet, needs no credentials to attack, and handles your remote-access sessions.
Section summary: This is a pre-authentication command-execution bug in an internet-facing VPN appliance, and Ivanti confirmed exploitation on disclosure day.
Fixed builds by branch
Several independent trackers that summarized Ivanti's advisory list the same fixes. Hol.org's campaign tracker lists 25.1.1.2 (for 25.1.1.1 and prior), 25.1.3.0 or 25.1.3.1 (for 25.1.2.2 and prior), and 22.8R2.5 (for 22.8R2.4 and prior); Ivanti recommends 22.8 customers move to 25.1.1.2. SecurityOnline reports the same three pairings.
| Affected branch | Fixed release |
|---|---|
| 25.1.1.1 and earlier | 25.1.1.2 |
| 25.1.2.2 and earlier | 25.1.3.0 or 25.1.3.1 |
| 22.8R2.4 and earlier | 22.8R2.5 (Ivanti advises 22.8 users to move to 25.1.1.2) |
| 22.7R2.14 and earlier | Not affected, per Ivanti's CVE record |
One discrepancy to know about: VulDB's entry describes affected versions as Ivanti Connect Secure up to 22.7R2.13/22.8R2.4 and lists 22.7R2.14 as a fix. That conflicts with Ivanti's own statement that 22.7R2.14 and earlier are not affected. The vendor's CVE record is the more authoritative source. If you run the 22.7 line, check your exact build against Ivanti's advisory rather than either secondary summary.
Hol.org also says the advisory names only Connect Secure. Policy Secure, ZTA Gateways and Neurons for Secure Access are not mentioned.
Three bugs, one patch so far
The attack itself is the bigger story. Volexity found and reported the flaw. It says a previously unknown actor it tracks as UTA0576 has, since at least October 3, chained CVE-2026-104935 with two other flaws to get unauthenticated root-level code execution on fully patched devices. Ivanti has fixed two of the three bugs. It is still working on the privilege-escalation bug in the same chain.
SecurityOnline's write-up of Volexity's findings adds more detail. On October 5, Volexity began investigating suspicious activity at a customer site. The trail led to an Ivanti Connect Secure (ICS) appliance on version 22.8R2.4, the latest release at the time. According to that report, Ivanti fixed two of them under CVE-2026-104935 on October 13. A fix for the third, a privilege escalation bug, will follow in the coming weeks. The same summary says the actor went on to steal Active Directory credentials, and lists one confirmed victim.
Volexity also described how UTA0576 operated. The actor deployed no malware or web shell. Instead it re-exploited the device for every command it ran and tampered with logs to hide its tracks, which let it evade Ivanti's Integrity Checker Tool.
Threat intelligence firm Defused backed up Volexity's report and said it saw the first signs of exploitation on October 1, two days before Volexity's earliest date. The two dates likely come from different telemetry rather than a contradiction. Either way, start your log review no later than October 1.
What this means in practice: the patch blocks the unauthenticated entry point. That is the step an outsider needs, so patching matters a great deal. It does not mean the whole chain is fixed. If an attacker was already inside before you patched, the update does not remove them.
Why a clean ICT scan isn't the all-clear
Ivanti tells customers to run the Integrity Checker Tool, and they should. But Ivanti has already explained the tool's limits. In an earlier FAQ about Connect Secure attacks, the company said that while the ICT provides a snapshot of the current state of the appliance, it cannot reliably catch an attacker who has returned the device to a clean state. Ivanti also said the ICT does not scan for malware or other indicators of compromise. The FAQ describes the method as comparing version-specific folder listings and file hashes with what is running on the device, and advises against using it as the only signal.
UTA0576 is close to the worst case for that design. It left no files to hash, re-exploited the device for each command and edited the logs. On top of that, hol.org reports that Ivanti says there are no reliable indicators of compromise yet and points suspected victims to its 22.8x and 25x recovery steps.
Exposure and federal deadline
- CISA KEV: The CVE is in CISA's Known Exploited Vulnerabilities catalog. Federal agencies must remediate by Oct 16, 2026. That is a three-day window, which tells you how urgent CISA considers this.
- Internet exposure: Shadowserver tracks more than 5,500 ICS instances exposed online. BleepingComputer notes there's no data on how many are honeypots or already secured. That number measures exposure. It is not a count of vulnerable or compromised systems.
What admins should do now
- Inventory every ICS appliance, including internal ones, and record each build number.
- Check builds against the table above. Anything on 25.1.1.1 or earlier, 25.1.2.2 or earlier, or 22.8R2.4 or earlier is in scope.
- Upgrade to the fixed build for your branch after confirming it in Ivanti's advisory. If you're on 22.8, consider Ivanti's recommendation to move to 25.1.1.2 instead of staying on 22.8R2.5.
- Treat the time before you patched as suspect, starting no later than October 1. Volexity says the victim was running the latest release, so being up to date did not protect anyone.
- Run the ICT, but don't stop there. Look at evidence the appliance can't alter: firewall and NetFlow records, and authentication logs from systems the gateway connects to. A VPN appliance that starts opening connections into your network it never made before is a warning sign. This is general incident-response practice, not Ivanti-published guidance.
- If you suspect compromise, follow Ivanti's 22.8x/25x recovery steps and bring in incident response. Because of the reported AD credential theft, rotate directory credentials and any secrets the gateway could reach.
- Watch for the third fix. The privilege-escalation bug is still unpatched, so you will need another update in the coming weeks.
The familiar Ivanti pattern
This has happened before. Ivanti fixed an authentication bypass (CVE-2023-46805) and a command injection (CVE-2024-21887) in early January 2024, followed two weeks later by a server-side request forgery (CVE-2024-21893). In 2025 it patched CVE-2025-0282 and then CVE-2025-22457, which China-linked spies had exploited since at least mid-March that year. CISA has flagged 36 Ivanti vulnerabilities as actively exploited since November 2021, and ransomware gangs have used 12 of them.
Fairness requires two notes. Edge devices from many vendors are targeted constantly, and Ivanti's ICS line is large, popular and valuable to attackers, so the volume of attacks reflects some of that. Ivanti also credited Volexity and moved fast on this disclosure. But a fully patched appliance being taken over with no malware and with logs scrubbed is hard to dismiss. It strengthens the case for treating VPN gateways as untrusted devices that you monitor from the outside, not as a perimeter you can rely on.
Bottom line: Patch to your branch's fixed build today, assume the gap before patching was hostile, and don't treat a clean ICT result as proof you weren't compromised. The third fix is still coming.