Ivanti Connect Secure CVE-2026-104935: Patching Is Not Recovery
No affiliate links appear in this article. Facts come from Ivanti’s advisory, CISA, NVD and Volexity’s incident write-up, all linked in Sources. This piece is written for defenders and change boards and contains no exploitation detail.
Table of contents
- Why this matters
- What did Ivanti disclose on October 13?
- Why a clean Integrity Checker result is not enough
- Which upgrade path fits your appliance?
- What does recovery involve if you suspect compromise?
- How often has Connect Secure been on KEV?
- What to do about it
- FAQ
- Sources
Why this matters
On October 13, Ivanti published an advisory for CVE-2026-104935, an authentication bypass in its Connect Secure VPN appliance that lets a remote, unauthenticated attacker run arbitrary commands. Ivanti rates it 8.6 (High) under CWE-290, authentication bypass by spoofing, and says it is aware of “exploitation in the wild affecting a limited number of customers.” CISA added it to the KEV catalog the same day. According to the NVD entry, federal agencies have until October 16 to act.
A three-day deadline usually turns a CAB conversation into a patching sprint. This one shouldn’t stop at the patch. CISA says threat actors have used the flaw “to conduct credential theft and data exfiltration,” and that Ivanti’s own Integrity Checker Tool “may not detect evidence of exploitation.” Volexity, which found the attacks, reports that the chain used three zero-days, and only two of them are fixed. A VPN appliance that’s been patched can still be compromised, and it may still hold credentials that have already been taken.
That makes this two changes, not one. The first is the upgrade, which is time-boxed and well defined. The second is a compromise assessment and, where needed, a recovery that touches the appliance, every credential it stored and the certificates it presents. Our 3-day KEV clock runbook covers how to run the first change under deadline. This piece is about the second.
What did Ivanti disclose on October 13?
The advisory lists three affected branches and their fixes:
| Branch | Affected | Fixed in | Notes from Ivanti |
|---|---|---|---|
| 25.1.1 | 25.1.1.1 and prior | 25.1.1.2 (released Oct 5) | ISA6000 / ISA8000 |
| 25.1.2 | 25.1.2.2 and prior | 25.1.3.0, 25.1.3.1 | 25.1.3.0 shipped in July 2026 and needs ISA4500, ISA6500 or ISA8500 |
| 22.8 | 22.8R2.4 and prior | 22.8R2.5 (released Oct 12) | 22.8 is “only meant to be a temporary bridge” to 25.1 |
| 22.7 | Not affected (22.7R2.14 and prior) | n/a | Reaches end of life January 31, 2027 |
Two details in the FAQ section change how a CAB should read this. First, Ivanti says it “initially discovered a portion of this vulnerability as part of our product security program and patched it in the July release 25.1.3.0,” and was “working to backport the fix to the remaining supported versions when exploitation occurred.” Appliances already on 25.1.3.0 were protected. Everyone else was exposed between July and October 13 with no fix available for their branch.
Second, the fix covers two of the three bugs in the chain. Volexity’s write-up says CVE-2026-104935 tracks both the authentication bypass and the remote code execution bug. A separate privilege-escalation flaw, which gave the attacker root on the appliance, remained unfixed at publication. Volexity says Ivanti is working on it for “a future release in the coming weeks.” It gives no workaround in the meantime.
Volexity first saw the activity in the first week of October, on an appliance running 22.8R2.4, which it describes as fully patched at the time. It tracks the actor as UTA0576 and assesses, with low confidence, that the motive was criminal rather than espionage. We don’t attribute it further than that.
Why a clean Integrity Checker result is not enough
Ivanti’s advisory tells customers to “run the Integrity Checker Tool regularly.” CISA’s alert adds a caveat: the tool may miss this exploitation “because threat actor commands execute in memory.” Volexity goes further and says the tool “does not detect any modifications” from this chain. The attacker’s changes lived in memory, and configuration-store data was restored afterwards.
Volexity also reports that the attacker removed exploitation entries from the appliance’s debug and audit logs. So a clean Integrity Checker run combined with clean local logs is not evidence of a clean appliance. CISA’s guidance is direct: organizations “will need to conduct network and memory forensics to identify evidence of exploitation.”
For a change board, this means the “verify” step in the emergency change record can’t be “ICT passed.” It needs one of these:
- Memory capture before reboot. The upgrade itself restarts the appliance and wipes the in-memory evidence. If you want forensics, capture memory first or accept that you’ve lost it.
- Network-side evidence. Volexity suggests watching for large numbers of requests to the Connect Secure welcome page endpoint, and for mismatches between the requested URL path and a specific internal request header. Your network security monitoring or reverse-proxy logs may show this even after local logs were altered.
- Indicators from Volexity. Volexity has published indicators on its GitHub page. Check them against firewall, proxy and DNS logs from at least late September onward.
Which upgrade path fits your appliance?
The upgrade looks simple in the table, but one branch hides a hardware dependency. Ivanti’s note says that customers migrating to 25.1.3.0 need the new platform: ISA4500, ISA6500 or ISA8500. Hardware customers “will need to have the new physical servers in place.” Virtual and cloud customers need to build new devices from the 25.1.3.0 template. That’s a rebuild, not an in-place patch, and it can’t be finished in three days if the hardware hasn’t been ordered.
So the practical choice for most teams looks like this:
- On 22.8 with no new hardware: upgrade to 22.8R2.5 now to meet the deadline. Then open a planned change to reach 25.1 before January 31, 2027, when both 22.7 and 22.8 reach end of life.
- On 25.1.1.x (ISA6000/ISA8000): upgrade to 25.1.1.2. Ivanti released it on October 5, so it may already be in your queue.
- On 25.1.2.x: move to 25.1.3.0 or 25.1.3.1, which means the newer ISA platforms or a fresh virtual build.
- On 22.7R2.14 or earlier: you’re not affected, but you’re on a branch that dies in under four months. Treat the migration as the real risk item.
If any appliance can’t be upgraded by October 16, the KEV required action says to follow BOD 26-04 guidance “or discontinue use of the product if mitigations are unavailable.” That’s a federal requirement, but it’s a sensible default for everyone. Our BOD 26-04 decision matrix shows how to record that choice.
What does recovery involve if you suspect compromise?
CISA’s alert lists the recovery steps from Ivanti’s procedures, in order:
- Back up the appliance configuration.
- Factory-reset the appliance and upgrade it to the latest version. For cloud and virtual systems, rebuild the instance instead.
- Restore the configuration from the backup.
- Reset passwords for all accounts, including domain, administrator and local accounts.
- Revoke and reissue stored certificates, and reset stored API keys and license server credentials.
Step 4 is where scope grows. Volexity reports that the attacker pulled credentials stored on the appliance, including the domain credentials used for LDAP. It also queried Active Directory for LAPS credentials, BitLocker recovery information and password attributes, and ran password spraying against AD accounts. If you suspect compromise, the change isn’t limited to the VPN. It covers the LDAP bind account, any service accounts the appliance authenticates with, and potentially the LAPS-managed local admin passwords and BitLocker recovery keys the attacker could reach.
Each of those is its own change with its own blast radius. Rotating an LDAP bind account breaks VPN authentication until the appliance config is updated. Rotating LAPS passwords is routine but has to be confirmed across the fleet. Reissuing the appliance certificate can break pinned clients. Plan them as one linked change set with a single owner. Our compensating controls register guide covers how to document any piece you can’t finish right away.
How often has Connect Secure been on KEV?
We pulled every Ivanti entry from the CISA KEV catalog (version 2026.10.13) and filtered for Connect Secure. Since January 2024 there have been six entries. Five carry KEV’s “known” flag for ransomware campaign use, and the deadlines have ranged from 2 to 12 days. Before that, the catalog’s November 2021 launch included eight Pulse Connect Secure entries, the product’s former name.
| KEV entry | Date added | Due | Window | Ransomware use |
|---|---|---|---|---|
| CVE-2023-46805 | 2024-01-10 | 2024-01-22 | 12 days | Known |
| CVE-2024-21887 | 2024-01-10 | 2024-01-22 | 12 days | Known |
| CVE-2024-21893 | 2024-01-31 | 2024-02-02 | 2 days | Known |
| CVE-2025-0282 | 2025-01-08 | 2025-01-15 | 7 days | Known |
| CVE-2025-22457 | 2025-04-04 | 2025-04-11 | 7 days | Known |
| CVE-2026-104935 | 2026-10-13 | 2026-10-16 | 3 days | Unknown |
The pattern matters more than any single entry. The six entries came in four separate waves: January 2024, January 2025, April 2025 and now October 2026. Every one carried a deadline shorter than a typical two-week CAB cycle. If your VPN appliance’s emergency change still gets drafted from scratch each time, that’s three years running in which a standing template would have saved days. The live KEV tracker shows new additions as they land, and the CAB agenda generator can produce an emergency-session agenda in a few minutes.
More coverage of exploited vulnerabilities is on our cybersecurity hub.
What to do about it
- Inventory every Connect Secure appliance today, including virtual and cloud instances, and record its branch and version. Reconcile it against your external asset view so a forgotten instance doesn’t stay exposed.
- Decide on memory capture before you upgrade. The upgrade reboots the appliance. If you may need forensics, capture first.
- Upgrade by October 16 to 25.1.1.2, 25.1.3.0/25.1.3.1 or 22.8R2.5, depending on branch and hardware.
- Don’t close the change on a clean Integrity Checker result. Add a network-evidence review against Volexity’s indicators, covering late September onward.
- If compromise is suspected, run the full recovery: factory reset or rebuild, then rotate every stored credential, certificate, API key and license server credential. Extend rotation to the LDAP bind account and any AD secrets the appliance could reach.
- Track the unpatched privilege-escalation fix as an open risk item with a named owner, and schedule its patch as soon as Ivanti ships it.
- Open the 25.1 migration change now. Both 22.7 and 22.8 reach end of life January 31, 2027, and 25.1.3.0 may need new hardware with a lead time.
FAQ
Which Ivanti Connect Secure versions are affected by CVE-2026-104935?
Per Ivanti’s advisory: 25.1.1.1 and prior, 25.1.2.2 and prior, and 22.8R2.4 and prior. Fixed versions are 25.1.1.2, 25.1.3.0, 25.1.3.1 and 22.8R2.5. Version 22.7R2.14 and earlier are not affected.
What is the CISA KEV deadline for CVE-2026-104935?
CISA added it on October 13, 2026 with a due date of October 16, 2026. The deadline binds US federal civilian agencies under BOD 26-04. Other organizations commonly use KEV dates as a prioritization benchmark.
Does the Ivanti Integrity Checker Tool detect this exploitation?
Not reliably. CISA says the tool may not detect it because attacker commands execute in memory. Volexity says the tool did not detect modifications from this chain. Both recommend network and memory forensics if you suspect compromise.
Is the whole exploit chain patched?
No. Volexity reports three zero-days in the chain. CVE-2026-104935 covers the authentication bypass and remote code execution, both fixed on October 13. A separate privilege-escalation flaw was unpatched at publication, and Ivanti said a fix would come in a future release.
Do I need new hardware to fix CVE-2026-104935?
Only if you choose 25.1.3.0. Ivanti says that release requires ISA4500, ISA6500 or ISA8500 hardware, or a new virtual build from its template. Customers on 22.8 can install 22.8R2.5 and those on 25.1.1.x can install 25.1.1.2 without changing platforms.
What credentials should be rotated after a suspected compromise?
CISA lists passwords for all domain, administrator and local accounts, plus stored certificates, API keys and license server credentials. Given Volexity’s findings, also review the LDAP bind account and any Active Directory secrets the appliance could reach.
Sources
- Ivanti: Security Advisory, Ivanti Connect Secure (CVE-2026-104935)
- CISA: CISA Urges Patching Newly Exploited Vulnerability in Ivanti Connect Secure
- NIST NVD: CVE-2026-104935 detail
- Volexity: A Series of Unauthenticated Events, Chained Exploitation of Ivanti Connect Secure Zero-Days
- CISA: Known Exploited Vulnerabilities Catalog
- CISA: KEV catalog JSON feed (version 2026.10.13)
- Center for Internet Security: Advisory 2026-115, Ivanti Connect Secure
Published October 14, 2026.