Ivanti zero day in a VPN gave root access to a patched appliance

The Ivanti zero day in the VPN with root access case centers on a flaw acknowledged in its Connect Secure VPN. According to SecurityWeek, that flaw was part of a chain that gave an attacker root access on an appliance with all patches installed [3]. The case leaves an uncomfortable conclusion: being up to date did not mean being safe.

For an industrial SME that opens its plant network to suppliers and maintenance technicians through a VPN, the lesson goes beyond updating. It is worth reviewing the segmentation of the industrial network and monitoring what happens outside the VPN appliance itself.

CVE-2026-104935 is an authentication bypass exploited before it was public

According to Rapid7, Ivanti published its security advisory on 13 October 2026 for CVE-2026-104935. The flaw is classified as CWE-290: authentication can be bypassed through spoofing [2]. In practice, this lets a remote attacker with no valid credentials execute arbitrary commands on the appliance [2].

The Cybersecurity and Infrastructure Security Agency (CISA) states that this Ivanti Connect Secure vulnerability affects versions 25.1.1.1 and earlier, 25.1.2.2 and earlier, and 22.8R2.4 and earlier [1]. Its CVSS score is 8.6 [2][4]. Rapid7 adds that, according to the vendor's advisory, versions 22.7.x and earlier are not affected. It also notes that the fixed versions are 25.1.1.2, 25.1.3.0, 25.1.3.1 and 22.8R2.5 [2].

What makes this a zero day is the timeline. Ivanti reports that exploitation had already taken place before disclosure and affected a limited number of customers [2]. In other words, attackers were using it when there was still no public advisory and no patch for all supported versions. It is a VPN zero day exploited in the wild.

Rapid7 also explains that Ivanti had detected part of the problem through its own security programme. It had fixed it in version 25.1.3.0 in July 2026, but exploitation happened while the company was carrying the fix over to the remaining versions [2]. CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalogue on the same day, 13 October [1][5].

So far, the story looks like many other advisories: a serious flaw, a patch available and a recommendation to apply it as soon as possible. The nuance comes from the incident investigation that exposed the exploitation.

A chain of three zero days gave root access on a fully patched appliance

According to SecurityWeek, which reports on work by the forensics firm Volexity, the exploitation came to light while Volexity was investigating an incident at one of its customers [3]. There it found a previously undocumented threat actor, which it calls UTA0576, that had chained three zero days. With them it achieved code execution as root, without authenticating, on a fully patched Ivanti Connect Secure appliance [3]. Volexity places the first evidence of exploitation on 3 October 2026 [3].

According to Volexity, CVE-2026-104935 covers two of those flaws: the authentication bypass and a remote code execution bug [3]. The third, a privilege escalation, was still unpatched when the information was published, and the vendor expects to fix it in the coming weeks, according to the same outlet [3]. Rapid7 also confirms that this privilege escalation had not been fixed and that Ivanti will patch it later [2].

This is the key point. SecurityWeek describes a fully patched appliance that was compromised through a chain of three zero days [3]. In the incident under investigation, the attackers stole credentials and tampered with the VPN appliance's logs [3][4].

Volexity details what they did next. According to SecurityWeek, the attackers stole domain credentials stored on the appliance and extracted limited Active Directory metadata. They also searched for LAPS passwords and BitLocker recovery keys, launched password spraying attacks and analysed authentication logs to identify valid users [3]. Volexity found no backdoor or web shell on the appliance. Even so, it assesses with high confidence that everything pointed to preparing lateral movement and a broader compromise of the network [3].

Patching closes the door but does not prove nobody entered earlier

CISA urges affected organisations to update immediately to the latest version, as Ivanti's advisory indicates. It also reminds them that version 22.8 reaches end of life on 31 January 2027 [1]. That is the first step and it cannot wait.

But the same agency describes attackers exploiting the flaw to steal credentials and exfiltrate data [1], and exploitation began before the advisory. Updates exist to fix CVE-2026-104935, and Rapid7 recommends looking for signs of compromise even after applying them [2]. A patched VPN compromised before the fix arrived is exactly the scenario to rule out.

The practical consequence is to assume that credentials that passed through the VPN, or were stored on it, may be exposed. If compromise is suspected, CISA recommends following Ivanti's recovery procedures [1]:

• Back up the configuration.
• Factory reset and update, or rebuild the instance in virtual and cloud environments.
• Restore the configuration.
• Change the passwords of all accounts, including domain, administration and local ones.
• Revoke and reissue certificates and renew API keys.

Nor is it wise to assume the risk is limited to targeted attacks. According to The Hacker News (thehackernews.com), Previdian's decoy sensors (honeypots) recorded 105 exploitation attempts from 50 unique IP addresses up to 14 October 2026 [4]. This is not a global figure and does not measure confirmed compromises. It does document active exploitation attempts against Previdian's sensors. For further recommendations, you can read the guide on how to protect a connected factory from cyberattacks.

What to review if the VPN gives access to the industrial network

The next section is Hodeitek editorial judgement and does not come from the cited sources. It sets out recommendations for a common industrial scenario: employees, integrators or machinery manufacturers using the same VPN to reach office and plant systems.

What to review in remote access

Before thinking about architecture, it helps to be clear about the starting point:

• Which version of Ivanti Connect Secure (or of whatever VPN you use) is in production and whether it is among the affected ones.
• Who has access (employees, suppliers, service accounts) and how long it has been since those accesses were reviewed.
• Which credentials are stored on the VPN appliance itself and which other accounts share that password.
• Whether the second authentication factor depends on the VPN itself or is independent of it.

Segment so that a compromised VPN does not reach the process

If the VPN falls, what matters is how far the attacker can go. As a design measure, it is worth separating the remote access zone from the OT network with firewalls and explicit rules, rather than giving flat access to the whole plant.

Supplier accounts should have the minimum privileges necessary and an expiry date. Credentials with access to the plant should be rotated after an incident like this one. Finally, it is worth considering penetration tests and red team exercises that start from a compromised VPN, to assess the segmentation barriers and look for undocumented paths. These general architecture measures do not replace the vendor's recommendations.

What to review to look for signs of compromise

This case has a trait that complicates detection. CISA warns that Ivanti's integrity checking tool may fail to detect the exploitation, because the attacker's commands run in memory. It also states that determining whether a compromise occurred requires network and memory forensic analysis [1]. According to The Hacker News, Volexity describes UTA0576 as having tampered with logs to cover its tracks [4].

If the compromised appliance is the one generating the logs, it cannot be the only source of truth. Useful monitoring sits outside it: Active Directory authentication logs, anomalous outbound traffic from the VPN, and remote access accounts connecting to segments they have never visited or at unusual hours. Since the described objective is credential theft and exfiltration [1], detection should focus on those behaviours.

Rapid7 recommends hunting for signs of compromise even after applying the patch. It notes that Ivanti had no reliable indicators at the time of the advisory, although Volexity has published some [2]. The Hacker News adds a lead: review incoming requests that include the «X-DSCGI-PATH» header [4]. For the specific indicators, the reference is Ivanti's advisory and the CISA Ivanti Connect Secure alert.

An industrial SME with no in-house team reviewing those logs daily may consider outside support. In that case, it is worth looking at managed monitoring and response services (SOCaaS/MDR) and checking what external monitoring they include.

Design remote access assuming the VPN can fall

The UTA0576 case does not invalidate patching: it puts it in its place. Updating is necessary, and in this case urgent. But a patched VPN is not a safe VPN when there are flaws the vendor does not yet know about or has not yet fixed [3]. If remote access reaches your OT network, it is worth reviewing segmentation, limiting privileges and monitoring what happens beyond the appliance itself.

Reviewing today how each supplier gets into your plant, and what someone spoofing that access could reach, is an exercise worth doing before the next advisory. If you want to approach it with a full view of the industrial environment, you can read about Hodeitek's approach to industrial OT security.