Ivanti is telling customers to patch immediately after confirming that a high-severity authentication bypass in its Connect Secure (ICS) remote access gateways is being exploited in the wild. The flaw, tracked as CVE-2026-104935, lets an unauthenticated remote attacker run arbitrary commands on vulnerable appliances with no user interaction and little attack complexity. Volexity, which discovered and reported the bug, says a previously unknown actor it calls UTA0576 has been chaining it with two additional flaws since at least October 3 to obtain root-level code execution on fully patched devices. Ivanti says it is aware of "limited exploitation" and is working directly with the affected organizations.

Affected versions and the fix

The vendor lists three vulnerable release trains:

  • ICS 22.8R2.4 and earlier
  • ICS 25.1.2.2 and earlier
  • ICS 25.1.1.1 and earlier

NVD's record describes the issue as an authentication bypass by spoofing (CWE-290) in ICS before version 25.1.3.0, allowing a remote unauthenticated attacker to execute arbitrary commands. The same record states that ICS version 22.7R2.14 or prior is not impacted. Organizations on any affected build should treat upgrading as urgent rather than waiting for a maintenance window; the CISA alert published October 13, 2026 repeats the version ranges and urges immediate patching.

Ivanti's guidance is to review the security advisory, move to the fixed version as soon as possible, and run the Integrity Checker Tool (ICT) on a regular schedule.

How the intrusion unfolded

Volexity's account is notable less for malware than for the absence of it. UTA0576 did not drop a web shell or implant on compromised appliances. Instead, the actor re-exploited the device for every command it wanted to run, keeping nothing persistent on disk, and then altered logs to conceal the activity. That operational style is specifically designed to defeat integrity scanning: a tool that looks for modified or unexpected files has little to find when the attacker never writes one.

The chain is not a single-bug story. According to Volexity, CVE-2026-104935 was combined with two other vulnerabilities to reach unauthenticated root-level code execution, and the actor was able to do this against fully patched devices — meaning the patch level at the time of the campaign did not close the full path. Ivanti has since fixed two of the flaws in the chain but is still working on a privilege escalation vulnerability that UTA0576 used as part of the same sequence. Defenders should therefore not assume that remediating CVE-2026-104935 alone terminates the intrusion path described by Volexity.

Timeline pressure is tight. Threat intelligence firm Defused independently corroborated Volexity's findings and reported seeing the first signs of exploitation in the wild beginning October 1, two days before the chaining activity Volexity dates to October 3.

Exposure

Shadowserver now counts more than 5,500 ICS instances reachable from the internet. That figure does not indicate how many of those systems are honeypots or how many have already been upgraded or otherwise hardened, so it should be read as an upper-bound measure of the attack surface rather than a count of vulnerable hosts.

Proof of concept

A public proof-of-concept repository for the flaw exists at ApexBreach/CVE-2026-104935-Proof-of-concept. Its description characterizes the bug as unauthenticated remote code execution via authentication bypass by spoofing (CWE-290) on Ivanti Connect Secure, and states that the exploit abuses the vulnerable parameter to obtain remote command execution with root privileges on affected systems. Because the flaw is trivially reachable without credentials, any internet-facing ICS instance that has not been upgraded should be assumed to be at risk from commodity attempts as well as targeted ones.

Detection and mitigation

  • Upgrade to the fixed release (25.1.3.0 or later for the 25.1 line) as the primary action; confirm the running build after the upgrade rather than trusting the change ticket.
  • Run the Integrity Checker Tool regularly, and treat a clean ICT result as necessary but not sufficient. UTA0576's log tampering was explicitly intended to slip past it, so pair file-integrity results with external telemetry.
  • Hunt for exploitation that leaves no files behind. Because commands were executed through repeated re-exploitation rather than a persistent implant, review authentication and access logs on and around the appliance, and look for gaps, truncation, or inconsistencies in those logs — including periods where logging appears to stop or restart.
  • Correlate ICS logs with upstream VPN concentrator, firewall, and SIEM data, since the appliance's own record may have been edited.
  • Restrict management interfaces and administrative access from the public internet where architecture permits, and monitor for anomalous outbound connections from the gateway itself.

Ivanti's zero-day history

Connect Secure has been a repeated target because a compromised VPN gateway sits inside the perimeter and offers a direct path to corporate and customer data. Ivanti patched an authentication bypass (CVE-2023-46805) alongside a command injection flaw (CVE-2024-21887) in early January 2024, then addressed a server-side request forgery (CVE-2024-21893) two weeks later. In January 2025 it fixed a remote code execution flaw, CVE-2025-0282, and later a second RCE tracked as CVE-2025-22457 that China-linked espionage groups had exploited since at least mid-March 2025.

CISA has flagged 36 vulnerabilities across Ivanti products as actively exploited since November 2021, 12 of which have also been used by ransomware operators. Ivanti employs more than 3,000 people, works through a network of over 7,000 partners, and serves more than 40,000 customers worldwide with its IT asset management products.

Technical background

Authentication bypass by spoofing (CWE-290) covers a family of bugs in which an application decides who a caller is based on a value the caller can supply — a header, a cookie, a query parameter, or a signed token whose signature is not actually verified. When a gateway trusts such a value to mean "this request came from an authenticated session" or "this request originated from a trusted internal hop," an unauthenticated attacker can simply assert the trusted identity and inherit the privileges attached to it.

The generic pattern looks like this: a reverse proxy or access gateway terminates the client connection, authenticates the user, and then forwards the request to a backend service while adding a marker — often an HTTP header — indicating the user's identity. If the backend accepts that marker from any source and the gateway passes client-supplied headers through unchanged, the marker can be forged. An illustrative (not Ivanti-specific) request shape would be:


GET /admin/diagnostic HTTP/1.1
Host: gateway.example.com
X-Forwarded-User: admin
X-Authenticated: true

The same class of mistake applies to path- or parameter-based trust decisions, where a component reads an identity or routing value from a parameter it does not validate. When the trusted branch of code leads to command execution — for example, a diagnostic or administrative routine that shells out — the bypass escalates directly to remote code execution, frequently as root because the gateway service runs with elevated privileges. That is why these flaws are so damaging in VPN appliances: the pre-auth boundary is the only real control, and behind it sits a process with broad authority.

The defensive lesson is architectural. Trust markers should be stripped from inbound client requests and re-added only by the component that performed authentication; backend services should verify a cryptographic signature or mutual authentication rather than a bare header; and privileged diagnostic functionality should not be reachable through the same unauthenticated path as the login page. Generic verification of such a boundary can be done with a plain request that omits credentials and observes whether the response differs from an anonymous baseline:


curl -sk -D - https://gateway.example.com/ -o /dev/null
curl -sk -D - -H 'X-Forwarded-User: admin' https://gateway.example.com/ -o /dev/null

A behavioral difference between those two responses is a signal worth investigating — though absence of a difference proves nothing, since the trusted value may be a cookie, a query parameter, or something else entirely.

References