We may earn a commission when you buy through links on this page. It doesn't change what we recommend.
An Ivanti Connect Secure vulnerability is under attack right now, and hackers got root control of a VPN appliance that was fully patched. Security firm Volexity published its findings on October 13. The U.S. cyber agency CISA added the flaw to its list of known exploited vulnerabilities the same day. If your company, school or city runs this VPN, the Ivanti Connect Secure vulnerability should already be on your IT team’s to-do list.
Here’s what happened, how the attack worked in plain terms, which versions are affected, and what administrators and everyday employees should do. The facts come from Volexity’s technical report, news coverage of the disclosure, and CISA’s alert.
What we know about the Ivanti Connect Secure vulnerability
The flaw is tracked as CVE-2026-104935 and scores 8.6 on the CVSS severity scale. According to The Hacker News, a remote attacker with no login can run commands on the appliance. Volexity found the activity while investigating an incident at one of its customers. It ties the attacks to a previously unknown group it calls UTA0576. Its timeline shows repeated exploitation starting October 3. Defused Cyber, which runs decoy systems, saw hits as early as October 1, before the disclosure.
Ivanti released patches on October 13 and published its advisory the next day. The company says a “limited number of customers” were affected, according to The Register, though no device count was given. CISA gave federal civilian agencies until October 16 to apply the fixes. By October 14, honeypots run by the firm Previdian had logged 105 exploitation attempts from 50 unique addresses. More attackers are clearly testing the flaw.
How the attack worked
Volexity describes a chain of three flaws, and the Ivanti Connect Secure vulnerability tracked as CVE-2026-104935 covers two of them. The first lets a specially crafted request skip the login step and reach parts of the appliance that should require authentication. The second abuses an upload handler that saves a file to disk before checking it, so an attacker can run it in a brief window. The third raises that access to root, the highest level of control, by tricking a trusted background service.
Ivanti hasn’t patched that third flaw yet. Volexity says the company knows about it and plans a fix in the coming weeks, according to The Register. The attackers used it anyway. The compromised appliance was fully patched, at version 22.8R2.4, when it was hit.
What the attackers did after getting in
The activity looks like prep work. Volexity says the group pulled stored credentials. It copied some directory data from the company’s Active Directory. It hunted for local administrator passwords and disk-encryption recovery keys, tried guessing passwords on accounts, and captured network traffic to find more logins. It also erased log entries. Volexity found no malware or web shell. The attackers just used the appliance’s own tools, and that makes them harder to spot.
Volexity says it caught and disrupted the activity, so the attackers’ final goal is unknown. It’s highly confident they were preparing to move deeper into the network. It has low confidence that the group is criminal rather than a government spy operation, and medium confidence that it uses large language models to build exploits and run operations. That last point echoes a theme from our report on XBOW’s AI-assisted Chrome exploit, though Volexity is less certain here.
Which versions are affected, and what to do
The affected versions are 25.1.1.1 and earlier, 25.1.2.2 and earlier, and 22.8R2.4 and earlier, The Hacker News reports. SecurityWeek lists the fixed builds as 22.8R2.5, 25.1.1.2, 25.1.3.0 and 25.1.3.1. Version 22.8 reaches end of life on January 31, 2027, so those users should plan a move.
Administrators should patch first, then look for signs of compromise. Volexity suggests watching for lots of requests to the login page where the URL and a header named X-DSCGI-PATH don’t match, and checking the /tmp folder for leftover files. Ivanti’s built-in Integrity Checker didn’t catch this activity, Volexity warns, so network and memory forensics are the safer test. If an appliance may be compromised, The Hacker News lists the steps: back up the configuration, factory reset, upgrade, restore. Then reset domain, administrator and local passwords, reissue certificates, and rotate API keys.
What employees and small businesses should do
Not an administrator? You can still help. Ask your IT team whether your remote-access VPN is an Ivanti product and whether it’s been updated. Be suspicious of unexpected password-reset requests or sign-in prompts for the next few weeks, since stolen credentials fuel convincing follow-up attacks. Our report on a fake event invitation that beat two-factor login shows how one approval prompt can undo an otherwise strong setup. Use unique passwords and keep multi-factor sign-in turned on.
A pattern worth noting
This isn’t Ivanti’s first time. The Register notes it’s the third year in a row the company has faced exploited zero-days in Connect Secure, after incidents disclosed in January 2024 and January 2025. VPN appliances sit at the edge of a network, so attackers love them. They’re reachable from the internet by design. They hold the keys to internal systems. And plenty of organizations treat them as set-and-forget boxes, updated whenever someone finds time. Attackers know that, which is why the same product keeps showing up in federal alerts.
What to watch next
Watch for Ivanti’s fix for the third flaw in the Ivanti Connect Secure vulnerability chain, any further CISA guidance, and whether other groups copy the technique now that details are public. Keep an eye on the attack counts too. Previdian’s early tally of 105 attempts could climb fast, and defenders will want to know whether the attacks spread beyond the first group. Ivanti has also said little about how many customers were hit, so a fuller count would help.
Editor’s take
The lesson is bigger than one product. The Ivanti Connect Secure vulnerability shows how a fully patched device can still be compromised when a vendor’s fix for one bug doesn’t cover a chain of three. Treat remote-access appliances as high-risk systems. Patch within days, assume logs can be edited, and limit what a stolen credential can reach. If your organization can’t do that, it may be time to ask whether a different remote-access design makes sense.
