Ivanti's VPN Flaw Makes a Clean Scan an Incomplete Answer

A clean integrity check is an uncomfortable result when the attack can run in memory. That is the operational problem in the October 13 warning about Ivanti Connect Secure: an appliance can need investigation even when a familiar check has not found altered files. CISA says attackers have exploited CVE-2026-104935 for credential theft and data exfiltration, and explicitly warns that Ivanti's Integrity Checker Tool may not detect evidence of this exploitation. The immediate response is bigger than finding the correct software download.

Ivanti describes the exploitation known at disclosure as limited and urges customers on affected versions to act immediately. That wording establishes observed attacks, not their full population. The vendor recommends upgrading, running its integrity checker and using layered controls that include network monitoring and log review. CISA adds the crucial qualification: determining whether a device was compromised requires network and memory forensics. Regular checking and a warning about the check's limits are compatible, provided nobody treats a negative result as a certificate of safety.

Volexity's first-hand account concerns a customer investigation begun on October 5. It says exploitation started on October 3 against an appliance running the then-current 22.8R2.4 release. The attacker combined authentication bypass, code execution and privilege escalation to reach root privileges. The first two weaknesses are tracked together as CVE-2026-104935; the investigator says a fix for the separate privilege-escalation weakness is still forthcoming. These are findings reported by the incident responder, not an independent reproduction by this publication.

The unusual feature of that investigation was repeated use of the exploit chain for commands, rather than a persistent backdoor or web shell. Volexity also reports attempts to remove traces and restore altered state. It cautions that not every cleanup operation's success was established. Those details explain why searching only for a conspicuous malicious file would ask too narrow a question.

For an operator, patch status and incident status belong in separate records. One describes whether a known route into the device has been repaired. The other describes what happened while that route was available and what access might have been obtained. Closing the first record does not supply missing evidence for the second. That distinction is especially important here because the agency's alert names stolen credentials and exported data, consequences that cannot be reversed simply by changing the appliance's software version.

The affected-version information also needs care. CISA identifies the 25.1.1.1-and-earlier, 25.1.2.2-and-earlier and 22.8R2.4-and-earlier release ranges. Rapid7's published branch mapping lists 25.1.1.2, 25.1.3.0 or 25.1.3.1, and 22.8R2.5 as corresponding resolved releases. This is not a recommendation to install an arbitrary numerically newer image. Operators need the vendor's current advisory and hardware or virtual-appliance migration guidance for their specific deployment.

Ivanti's machine-readable CVE record explicitly lists 25.1.3.0, 25.1.3.1 and 22.8R2.5 as unaffected, while its description excludes 22.7R2.14 and earlier from this vulnerability. The record does not enumerate every resolved version in Rapid7's branch table. The vendor's detailed support advisory did not render in the source reader used for this article, so the branch mapping above is attributed to Rapid7 rather than presented as an independently audited installation plan.

Nor is the older-version exclusion an argument for downgrading. Being outside one vulnerability's affected range does not establish an older release's overall security or support suitability. CISA separately notes that the 22.8 line reaches end of life on January 31, 2027. A team on that line therefore has an immediate vulnerability response and a subsequent lifecycle decision to manage. Completing today's update should not cause the support deadline to disappear from the operating plan.

Severity labels provide another opportunity for the wrong shortcut. Ivanti's CVE record assigns an 8.6 CVSS 3.1 base score, classified as high, with no required privileges or user interaction. CISA's added assessment marks exploitation active, automation possible and technical impact total. These fields describe different aspects of the problem. A queue sorted only by the largest numeric score could obscure the combination that matters here: a reachable gateway, an attacker who does not need an account, and exploitation already observed.

CISA's Known Exploited Vulnerabilities catalog added this CVE on October 13, lists October 16 as its due date and flags forensic triage. That is a federal vulnerability-management entry, not a universal legal deadline for every private business. The agency's BOD 26-04 guidance explains that applicable timelines depend on the asset's exposure and other risk characteristics. Nothing in the date makes waiting attractive for an organization with an affected, exposed gateway.

The agency's broader implementation guidance is useful because it treats evidence collection as part of vulnerability response. It calls for identifying the affected systems, activating the relevant responders and establishing communications that do not depend on potentially compromised infrastructure. That last point is practical, not ceremonial. A response team needs a reliable place to coordinate decisions about a gateway whose trustworthiness is itself under investigation.

The difficult scheduling question comes next. CISA advises collecting volatile evidence before altering or remediating systems when possible, since memory contents can disappear when a system is powered off. It also warns that patching can jeopardize artifacts. This does not justify leaving an exposed device running indefinitely while waiting for a perfect forensic image. It means evidence collection, containment and restoration need a coordinated decision, with the tradeoff recorded rather than discovered after the reboot.

For a small infrastructure team, the useful preparation is to decide who can collect that evidence and who has authority to interrupt access. For a larger organization, those may be different teams with different incentives. The network owner wants service restored; the responder needs enough information to understand the breach; the business owner needs a credible interruption plan. CISA's guidance specifically calls for explicit risk decisions balancing mission availability and integrity against exploitation. A change ticket should expose that balance.

Scope matters just as much as speed. The same guidance discourages collecting data beyond the incident or alert scope under time pressure. It asks for a record of each evidence item, its source system, collection time and collector. This makes triage a bounded investigation rather than an attempt to preserve the entire enterprise. For this incident, the purpose is to establish whether access occurred and what followed, while keeping the evidence interpretable for whoever takes over the response.

Identity is part of that scope. Volexity reports activity directed at directory credentials, local administrator passwords managed through LAPS, and BitLocker recovery information. It does not establish that every Ivanti customer lost those secrets. It does establish why the identity team belongs in a suspected gateway-compromise investigation. The possible loss is not limited to the appliance's own administrator login.

CISA's October 13 alert gives a concrete recovery outline for suspected compromise. It recommends backing up the appliance configuration, performing a factory reset and upgrading to the latest version, then restoring the configuration. For cloud and virtual systems, it specifies rebuilding the virtual instance and upgrading. Those recommendations should be followed with the current vendor procedures; this article is not a substitute for a platform-specific recovery runbook.

The credential portion of that guidance is easy to underestimate because it crosses ownership boundaries. CISA recommends resetting domain, administrator and local account passwords, revoking and reissuing stored certificates, and resetting stored API keys and license-server credentials. A reset of the appliance alone cannot perform all that organizational work. Each relevant secret needs an owner, a replacement path and verification that dependent services still operate after the change.

That replacement work also explains why an emergency response cannot be measured only by minutes of VPN downtime. Restoring connectivity is one business requirement. Establishing that stored authentication material has been addressed is another. A team that returns service quickly but leaves the identity work unassigned has not completed the recovery CISA describes. Conversely, broad credential changes without coordination can create avoidable operational failures. The practical task is a controlled recovery, not a race to report a green dashboard.

Exposure statistics should not turn that urgency into invented victim counts. BleepingComputer reports that Shadowserver tracks more than 5,500 internet-exposed ICS instances, while explicitly noting uncertainty about honeypots and already-secured devices. That is reporting about visible systems, not a census of compromised organizations. The public sources reviewed here do not establish the total number of victims. CISA's catalog also records ransomware use for this CVE as unknown, which is not evidence either of a ransomware campaign or of its absence.

The same restraint belongs in an internal incident report. CISA's triage guidance distinguishes no evidence of compromise, suspected compromise and confirmed compromise. It calls for heightened monitoring when no evidence is found, continued investigation of unresolved anomalies and escalation when warranted. These are different states, not interchangeable labels for finishing a ticket. Missing telemetry should remain a stated limitation of the conclusion.

A useful handover would therefore include the appliance's release and deployment type, the exposure assessment, collected evidence, changes made, credential actions and unresolved questions. CISA asks for a timeline, technical findings, containment and mitigation actions, and a recommendation on next steps. That is a more durable result than a screenshot of a successful update: it lets the next responder understand both what has been repaired and what is still unknown.

This disclosure should also sharpen the next operational review with an edge-device supplier. Ask how the product supports evidence collection, how recovery differs across deployment types and how release branches receive security fixes. Those are proposed evaluation questions, not claims that any alternative product is immune. In this case, the decisive result is a documented recovery that joins the gateway, its credentials and the investigation. A negative integrity check can contribute to that record. CISA has made clear that it cannot close the case by itself.

LaunchPad positionTrack vulnerability remediation, forensic findings and credential recovery separately before closing the response.