On October 13 Volexity published details of an attacker it tracks as UTA0576 chaining three zero-day flaws to gain root access on a fully patched Ivanti Connect Secure appliance, running commands as the root superuser without logging in at all. The appliance was on 22.8R2.4, which was the latest version at the time. Ivanti patched two of the three flaws the same day as CVE-2026-104935, CISA added it to the Known Exploited Vulnerabilities catalog with an October 16 federal deadline, and the third flaw, a privilege escalation, is still unpatched at the time of writing.
Why this one is worth your attention
We covered a patchless FortiMail flaw a fortnight ago and noted most small businesses were not directly exposed. This is different on both counts. Ivanti Connect Secure is a mainstream remote-access VPN appliance, common in mid-sized organizations and very common at the IT providers who serve smaller ones. And the lesson is the inverse of the FortiMail one. There, the problem was no patch. Here, the appliance was patched and still fell.
The detail that earns this a post: the attacker re-exploited the device for every command and tampered with logs, which evaded Ivanti's own Integrity Checker Tool. A clean scan from the vendor's utility does not rule out compromise. That is an unusually important caveat, because the normal small-business response to a security advisory is to run the vendor's checker, see green, and move on.
What the attacker actually did
The chain combined an authentication bypass, a file-write flaw, and a privilege escalation in a component that trusted cached data. The result was unauthenticated command execution as root. But the appliance was not the objective. In the confirmed case the attacker took stored credentials including LDAP domain credentials, searched Active Directory for passwords, and ran password-spraying attacks against the organization.
That is the part to internalize. A VPN appliance sits at the edge of your network and holds the keys to your directory, because that is how it authenticates people. Compromise there is not contained to a box in a cabinet. It is a credential breach of your whole identity system, which is why the response cannot stop at installing an update. Exploitation was observed from around October 3, and honeypot sensors were logging over a hundred exploitation attempts by October 14, so scanning is widespread.
What to actually do
- Patch today if you run Ivanti Connect Secure, to the fixed build in Ivanti's advisory. Confirm the version number against the vendor advisory rather than a news article, including ours.
- Do not trust a clean integrity check. The known attack evades it. Treat the scan as one weak signal, not an all-clear.
- Hunt, then rotate. Review logs for unusual volumes of requests to the appliance's authentication paths, and if the device was internet-facing during the exposure window, rotate the credentials it stored, starting with LDAP and service accounts.
- Track the unpatched flaw. One of the three still has no fix. Put a named person and a date against checking for it, because open items with no action available are exactly what gets forgotten.
- If someone else runs your IT, send one email today: do we use Ivanti Connect Secure, is it patched, and have you checked for compromise rather than just scanning. The shape of the answer tells you a lot.
- Ask the broader question. What else sits at your network edge holding directory credentials, and who owns updating it? That inventory is the thing that makes the next advisory a ten-minute check.
The takeaway
Two uncomfortable ideas in one incident. Patched is not the same as safe, because attackers find chains that work against current versions. And a vendor's own compromise-checking tool can be defeated by an attacker who anticipated it. Neither means give up on patching, which remains the highest-value thing you do. It means that after a confirmed-exploited flaw on an internet-facing device, the correct posture is to assume you need to look, and to rotate what that device knew.