On October 13, 2026, CISA added CVE-2026-104935 to its KEV catalog, with an October 16 due date. It affects Ivanti Connect Secure, Ivanti's SSL VPN gateway, and leads to unauthenticated command execution. Three days to act.
NVD has not yet published a score or versions as of writing. The reference for which versions are affected and which to install is the Ivanti security advisory.
| Field | Value |
|---|---|
| CVSS | not published by NVD (as of writing) |
| Vector | not published |
| NVD published | not published |
| CISA KEV added | 2026-10-13 |
| CISA due date | 2026-10-16 |
| Ransomware | not flagged by CISA |
What CISA Says
Ivanti Connect Secure contains an authentication bypass by spoofing vulnerability that allows a remote unauthenticated attacker to execute arbitrary commands.
An authentication bypass by spoofing: the appliance accepts as legitimate an identity or origin it never actually verified. The outcome is the worst one possible for an access gateway: a remote, unauthenticated attacker runs commands on the device.
The entry doesn't say what gets spoofed. I won't make it up.
Why Ivanti Connect Secure, Again
It's not the first time. Connect Secure has gone through several exploitation waves in recent years, including the 2024 ones we covered in our article on Ivanti's 2024 vulnerabilities. The pattern repeated each time: fast exploitation, implants dropped on the appliance, and persistence that sometimes survived upgrades.
The reason is structural. A VPN gateway is internet-facing by design, it holds authentication secrets (accounts, certificates, directory binding) and it sits on the edge of the internal network. A command run on the appliance means an attacker already inside.
Checking Integrity: Ivanti's ICT
Ivanti provides an Integrity Checker Tool (ICT) that compares the appliance's files against the expected image and flags modified or added files. It comes in an internal and an external version. On an appliance exposed during a period of active exploitation, it's the first check to run, before and after the upgrade.
Two caveats:
- use the ICT version Ivanti recommends for your Connect Secure release, per the security advisory or vendor documentation;
- don't treat a clean ICT result as absolute proof: in past campaigns, some implants were specifically designed to fool this check. Combine it with log analysis.
Detection
- ICT results: any modified or unexpected file is an incident signal
- Appliance logs: admin or configuration sessions with no matching login, unusual errors, unexplained reboots
- Internal network side: connections from the appliance's internal address to servers it never talks to (domain controllers outside authentication, file shares, workstations)
- Directory side: the LDAP/AD binding service account used from another source or at unusual hours
- Outbound traffic from the appliance to unknown destinations
Mitigation
- Apply the Ivanti fix or, failing that, the vendor's published mitigation, before the October 16 deadline.
- Run the ICT before touching anything, then after the upgrade, and keep the results.
- Restrict the admin interface to a management network: it never needs to be reachable from the internet.
- If the ICT or logs show an anomaly: follow Ivanti's response procedure (appliance reset, rebuild), then rotate every secret the appliance held: local accounts, certificates, the directory binding account, and passwords of users who logged in during the suspect period.
- Isolate the appliance on the inside: it should only reach the resources the VPN service needs.
Why Continuous Monitoring of VPN Gateways Matters
A VPN gateway is the first device an attacker scans and the last one you can afford to leave behind. When a CVE hits it in KEV with a three-day deadline and no NVD score, your reaction time depends entirely on how fast the alert arrives.
With cveo.tech, register your VPN appliances with their exact version and get alerted as soon as a CVE affecting them enters the CISA KEV catalog.