CVE-2026-104935 is an authentication bypass in Ivanti Connect Secure that lets a remote, unauthenticated attacker run commands. Ivanti reports exploitation against a limited number of customers, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 13, 2026. Upgrade to a fixed release on your branch this week. Then check whether any exposed appliance was entered before the upgrade, because patching does not remove access an attacker already has.
Working through this in production? See how we run a cybersecurity risk assessment.
What is exposed
Ivanti lists three affected ranges. Any Connect Secure appliance in these ranges is in scope, whether it is hardware, virtual or cloud-hosted.
| Release line | Affected | Fixed release |
|---|---|---|
| 25.1.1.x | 25.1.1.1 and prior | 25.1.1.2 |
| 25.1.2.x | 25.1.2.2 and prior | 25.1.3.0 or 25.1.3.1 |
| 22.8R2 | 22.8R2.4 and prior | 22.8R2.5 |
Ivanti states that 25.1.3.0 and later do not contain the vulnerability. The advisory coverage we reviewed also notes that versions 22.7R2.14 and prior are not affected. Ivanti recommends that customers on 22.8 move to 25.1.1.2 or later, and use 22.8R2.5 only where an immediate move is not possible.
Advisory coverage gives the end-of-life date for Connect Secure 22.8 as January 31, 2027. A 22.8 appliance therefore needs a migration plan as well as a patch. Confirm that date with Ivanti before you plan around it.
Check the version on every appliance, including ones a managed service provider runs for you. Ask the provider for the version and the patch date in writing, and keep that record in your evidence file.
Why patching is not the whole job
The October 15 advisory summary we reviewed notes that patching does not remove persistence an attacker has already installed. It also recommends investigating any appliance that ran an affected version from October 3, 2026, regardless of its current patch state. Rapid7 reports that Volexity detected the threat actor activity in early October 2026. Ivanti’s July fix in 25.1.3.0 did not reach every supported branch. Rapid7 reports that exploitation occurred while Ivanti was backporting the fix, so a branch that had not yet received it may have been exposed during that period.
The exposure window therefore runs from early October, not from the day you patch. An appliance that was patched on October 15 may still have been entered on October 5.
What the attack chain looks like
Public analysis describes a chain of three flaws, not one:
- An authentication bypass tracked as CVE-2026-104935, which allows unauthenticated command execution.
- An arbitrary file write that leads to remote code execution, according to Volexity’s analysis as summarized in SANS NewsBites.
- A privilege escalation flaw that is not tracked by CVE-2026-104935. Volexity reported it, and Ivanti said a fix would come in a future release, in the coming weeks.
Ivanti says it found part of the authentication bypass and fixed it in the July 2026 release, 25.1.3.0. It was still backporting that fix to other supported branches when attackers began exploiting it. The October 13 patches address two of the three flaws. An upgrade to a fixed release closes the first two steps of the chain. Until Ivanti ships the privilege escalation fix, treat an exposed appliance as one that could still be escalated.
Triage: is this appliance in scope
Work through these steps for each appliance, and record the result.
- Inventory. List every Connect Secure appliance, including virtual and cloud instances, test systems and appliances run by a provider. Record the release line from the admin console.
- Compare with the affected ranges. Anything on 25.1.1.1 and prior, 25.1.2.2 and prior, or 22.8R2.4 and prior is in scope.
- Set the exposure window. Note whether the appliance was reachable from the internet on an affected version at any point since October 3, 2026.
- Patch on an emergency basis. Use the fixed release for your branch. Ivanti’s advisory lists no workaround as of October 14, so the fixed release is the primary remediation. If you cannot patch at once, restrict external access to the appliance and record that compensating control until the patch is applied. The restriction is our recommendation, not a vendor step.
- Hunt for compromise. At the time of the advisory, Ivanti stated that reliable indicators of compromise were not available. Rapid7 reports that Volexity has published several indicators. Check them, and do not rely on a clean indicator check alone.
- Preserve evidence before you change anything. CISA warns that the Integrity Checker Tool may not detect exploitation, because the commands run in memory, and says network and memory forensics are needed to find what the tool may miss.
Rapid7 recommends looking for signs of compromise even after the patch is applied. That advice applies to every exposed appliance.
Evidence to keep
An auditor or counsel will ask what you checked, when, and on which appliance. Keep these records in one file per appliance:
- The release line and build as read from the admin console, with the date and the name of the person who read it.
- The patch date, the fixed release installed, and the change ticket that approved it.
- The authentication, admin and configuration logs for the window from October 3, 2026 to the patch date, or the export that shows they were checked.
- Any new administrator, certificate, API key or license credential created during that window, and the owner of each.
- Forensic output requested from the provider or an incident responder, including what was asked for and what was returned.
- The credential reset log, listing each account and key, the date reset, and the owner who confirmed it.
If you find signs of compromise
CISA’s recovery procedure for a suspected compromise is specific, and it is worth following in order:
- Back up the appliance configuration. Review the backup before you restore it from a compromised appliance, because a backup taken from a live compromise can carry the attacker’s changes. This review step is our recommendation, not part of CISA’s procedure.
- Factory reset and upgrade. For a physical appliance, perform a factory reset and upgrade to the latest version. For a virtual or cloud instance, rebuild the instance and upgrade it.
- Restore the configuration from the reviewed backup.
- Reset credentials. Reset passwords for every account, including domain, administrator and local accounts. Revoke and reissue stored certificates. Reset stored API keys and license server credentials.
Do not treat the reset as the end of the matter. Counsel decides whether the event triggers notification, and the answer depends on what the appliance could reach. A VPN appliance usually holds credentials to the network behind it, so assume it could reach a great deal.
Watch the second CVE
Canada’s Cyber Centre updated its advisory on October 16, 2026, to state that open-source reporting indicates CVE-2026-111357 is being exploited in the wild. The advisory’s body lists Connect Secure among affected products, and its version list for Connect Secure differs from Ivanti’s and CISA’s. The update does not tie CVE-2026-111357 to a specific product.
Use Ivanti’s version table, not the one in the Cyber Centre body, to decide what is in scope. Confirm with Ivanti which product and release CVE-2026-111357 affects before you close the exposure review.
Timeline
- Early October 2026: Volexity detects in-the-wild activity, according to Rapid7.
- October 13, 2026: Ivanti publishes its advisory and fixes two of the three chained flaws. CISA adds the flaw to its Known Exploited Vulnerabilities catalog.
- October 16, 2026: Canada’s Cyber Centre reports open-source evidence of exploitation of CVE-2026-111357.
- October 20, 2026: Singapore’s Cyber Security Agency issues an alert on active exploitation.
Fixed releases also shipped on other dates, per advisory coverage: 25.1.3.0 in July, 25.1.1.2 on October 5, and 22.8R2.5 on October 12.
Questions buyers ask
Our appliance is patched. Do we still need an investigation? If it ran an affected version from October 3, 2026, yes. The October 15 advisory summary recommends an investigation for that window whatever the current patch state. A patch closes the door. It does not show whether someone was already inside.
A vendor manages our appliance. Is it still our problem? Yes, as exposure. The provider does the work, but you own the risk. Get the patched version and the patch date in writing, and keep them with your evidence.
Does a clean Integrity Checker result mean we are clean? No. CISA warns that the tool may not detect exploitation, because the commands run in memory. A clean result is one input, not a conclusion.
Should we reset every password even without evidence? Reset the credentials the appliance could reach if you find signs of compromise, using CISA’s list as the baseline. Without evidence, the decision is a risk judgment. Record the reasoning and the owner.
What if our version is not in the table? Confirm it with Ivanti before you rely on it. The advisory coverage we reviewed says versions 22.7R2.14 and prior are not affected, but a build outside the tables is a question for the vendor, not for a summary.
Does this trigger a notice to customers or regulators? Counsel decides. The answer depends on what the appliance could reach and whether access is confirmed. Some notification clocks start at discovery, so raise the question early if you find a compromise.
For the wider program, see penetration testing, which checks what an outside attacker can still reach after you patch. For the difference between a scan and a test, read penetration test vs vulnerability scan. For the same patch-this-week approach applied to a web platform, read PHP2Shell: what to patch this week.
Key facts
- CISA describes CVE-2026-104935 as a zero-day authentication bypass that allows remote, unauthenticated execution of arbitrary commands in Ivanti Connect Secure, and says threat actors are using it for credential theft and data exfiltration. CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 13, 2026 (CISA, October 13, 2026).
- CISA warns that Ivanti's Integrity Checker Tool may not detect exploitation, because threat actor commands run in memory, and lists a backup, factory reset, upgrade and credential reset as its recovery procedure when compromise is suspected (CISA, October 13, 2026).