Blast radius: what one CVE actually reaches

A critical CVE on one appliance is rarely the whole story. The question that drives patch sequencing and incident triage is what that box can reach when it falls. This post runs a blast-radius analysis for a recently confirmed exploited entry on CISA's Known Exploited Vulnerabilities list: CVE-2026-104935 in Ivanti Connect Secure, added to KEV on 2026-10-13. We trace it through a generic reference architecture at example.com, then contrast it with a published-but-not-yet-exploited peer, CVE-2026-76504 in Cisco Catalyst SD-WAN Manager, to show how the same method separates "patch tonight" from "patch on the next window."

The lead finding: CVE-2026-104935 in Ivanti Connect Secure

Per the KEV entry, Ivanti Connect Secure contains an authentication bypass by spoofing vulnerability that allows a remote unauthenticated attacker to execute arbitrary commands. Two attributes stand out:

1. The precondition is network reach to the appliance's web front end. No credentials, no prior foothold, no user interaction.
2. The outcome is arbitrary command execution, not just information disclosure or session fixation.

That combination (unauthenticated RCE on a device whose job is to terminate remote-access VPN sessions) is why KEV inclusion matters here. CISA's current remediation directive, BOD 26-04 (Prioritizing Security Updates Based on Risk, effective 2026-06-10), carries forward the KEV criteria from the superseded BOD 22-01 and obligates federal civilian agencies to remediate listed vulnerabilities. The directive omits a one-size-fits-all deadline in favor of risk-based prioritization; treat the KEV listing itself (not an invented day count) as the trigger.

Blast radius against a reference architecture

Consider a typical mid-market deployment at example.com:

Internet
   |
   | TCP/443
   v
[ vpn.example.com ]  <-- Ivanti Connect Secure (ICS) appliance
   |
   |  terminates SSL VPN, writes session state,
   |  proxies internal URLs, holds LDAP bind creds
   |
   +--> AD / LDAP (ldap.corp.example.com, bind account)
   +--> RADIUS / MFA broker (mfa.corp.example.com)
   +--> Internal web apps (wiki, jira, grafana) via rewrite
   +--> SSH jump host (bastion.corp.example.com) via port-forward policy
   +--> Syslog / SIEM collector (siem.corp.example.com)

What does an attacker reach when CVE-2026-104935 lands?

• Command execution runs with the appliance's own privileges. On ICS that historically means direct access to the configuration database, VPN session tables, and any secrets the device uses to communicate with backing services.
• The LDAP bind account is the first high-value secondary target. If vpn.example.com authenticates users against ldap.corp.example.com with a service account that can enumerate the directory, the attacker inherits that read.
• Any live VPN session is a hijack candidate. The appliance holds the TLS keying material and the user-to-session mapping. "Authentication bypass by spoofing" in the KEV text suggests session identity assertions are part of the attack surface.
• URL rewrite policies turn the appliance into an internal HTTP proxy. If the policy allows reaching jira.corp.example.com or grafana.corp.example.com, so does an attacker who owns the box.
• Outbound logging is a problem. A compromised appliance writing to siem.corp.example.com is a trust-boundary violation; its logs are now attacker-controlled narrative, not evidence.

The blast-radius envelope is not just "VPN down." It covers directory enumeration, lateral HTTP to anything behind the gateway, credential theft from in-flight sessions, and a hole in the audit trail.

Am I exposed? A grounded self-check

A blast-radius write-up helps a defender answer that question in minutes, not days. Three evidence sources, in order of cost:

1. Asset inventory. Enumerate every FQDN resolving to an ICS appliance. One lightweight approach:

``bash # External view: TLS cert SANs that look like Ivanti ICS for host in $(cat edge_hosts.txt); do echo -n "$host: " timeout 5 openssl s_client -connect "$host:443" -servername "$host" \ </dev/null 2>/dev/null \ | openssl x509 -noout -subject -ext subjectAltName 2>/dev/null \ | tr '\n' ' ' echo done ``

Pair that with the vendor advisory's affected-version list and your CMDB.

1. Reachability. If the admin web interface is reachable from the internet rather than only from a management VLAN, your blast radius is maximal. The right control is not "patch faster"; it is "do not expose management planes."

1. Behavioral baseline. For every ICS appliance, pull 30 days of outbound connections from the SIEM. Any new destination (new internal subnet, new external IP) after the KEV publication date is a lead worth investigating.

The exposure question is: who can reach vpn.example.com:443, and what does that appliance's service account own? Answer those two and you know your blast radius without needing a working exploit.

Contrast: published, not yet exploited

The same method applied to CVE-2026-76504 (Cisco Catalyst SD-WAN Manager API authentication bypass, published 2026-10-14) gives a different sequencing answer, not a different kind of risk. The vendor describes improper handling of URI encoding in an HTTP request that bypasses an authentication rule and grants admin-user privileges on the manager. The blast radius on paper is severe: SD-WAN Manager drives configuration for every edge router it governs, and admin on the manager is admin on the fleet. What is missing, as of this writing, is confirmed in-the-wild exploitation. That absence is a scheduling input, not a dismissal. For a Manager instance reachable only from a management network, this is a "next change window" item; for one reachable from a user VLAN or (worse) the internet, treat it like the Ivanti finding until proven otherwise.

What the method gives you

Blast-radius thinking replaces two bad habits. The first is CVSS-sorted patch queues that ignore where the asset sits. The second is panic prioritization, where every KEV addition becomes a fire drill regardless of reachability. The discipline is small and repeatable:

• Name the appliance's trust relationships, not just its CVE score.
• Walk the service account's permissions out one hop.
• Check reachability from untrusted networks before you check the version string.
• Treat the appliance's own logging path as part of the compromise surface.

For CVE-2026-104935, that discipline produces a short, defensible action list: inventory ICS instances, pull management interfaces off the internet, rotate the LDAP bind and any device-held secrets after patching, and diff outbound connections against a pre-KEV baseline. None of that requires a proof-of-concept. All of it shrinks the radius before the next listing lands.

Verifiable security.