Does this CVE actually apply to you? Three filters before you patch

In May 2025, Cisco published an advisory for CVE-2025-20188 on the IOS XE Wireless Controller. CVSS 10.0. Hardcoded JWT, unauthenticated, root-level arbitrary file upload. The detail two paragraphs down said the bug only fires when the Out-of-Band AP Image Download feature is enabled, and that feature is off by default. A lot of shops ran emergency change-management for a max-severity bug that didn’t apply to them.

The same triage habit produced the inverse problem last month. CVE-2026-32202 scored 4.3 and sat in the routine-remediation bucket for 13 days while APT28 used it to steal credentials from government targets (the full timeline is here). Same approach, different failure mode.

The story is neither CVE. It’s that asking one number to answer three different questions produces predictable, recurring failures in both directions.

The obvious read

The conventional shape of CVE triage in 2026: a feed comes in, scanner buckets by CVSS, anything above 7 gets a ticket, anything above 9 escalates. EPSS and KEV get sprinkled in as supplements. The score does most of the work and the analyst does the rest. It’s a defensible default. It scales. It justifies itself in audit conversations.

What it doesn’t do is filter the queue. It ranks it. Every 9.8 gets a ticket whether or not the affected feature is enabled, whether or not the vulnerable interface is reachable, whether or not anyone is actually using the bug. The 132 CVEs that landed yesterday all show up in the morning queue, sorted but not reduced.

The pattern underneath

Three independent questions are being collapsed into one score.

Does the vulnerable code path exist in our running configuration? Can an attacker actually reach it from where they sit? Is anyone using it, and how do we know?

Each is its own filter. Each drops candidates the next one doesn’t need to process. Stacked in that order, they reduce a long list of advisories to the small number that warrant action this week. Compressed into a single CVSS score, they go missing.

The 2025 numbers establish how much that compression costs. Roughly 48,000 CVEs were published, about 132 per day. Only 57.6% included CPE identifiers, the asset-matching field scanners rely on. Verizon’s 2025 DBIR puts median time-to-remediate edge-device KEVs at 32 days, while Qualys data shows average time-to-exploit dropped to roughly negative one day in 2025, meaning some bugs are weaponized before public disclosure. Patching everything was never possible at 48,000 CVEs a year, and NIST’s April 2026 enrichment cutback made the math worse. The lever that moves it is filtering better.

Filter 1: applicability

The first question is whether the vulnerable code path exists in your running configuration. The advisory tells you which products and versions contain the bug. It does not tell you whether the code path is loaded in your install.

Cisco WLC CVE-2025-20188 is the cleanest version of the gap: max CVSS, feature off by default. FortiOS CVE-2024-21762 (CVSS 9.6) is structurally similar. The bug lives in sslvpnd, and Fortinet’s FG-IR-24-015 workaround is explicit that SSL-VPN must be running for the bug to fire. Shops using FortiGates as NGFW or IPsec concentrators were never exposed. The trap on that one was operators pattern-matching to past sslvpnd bugs where disabling web mode was sufficient; on 2024-21762, Fortinet warns specifically that web-mode-off is not a valid workaround.

Applicability can be architectural. Veeam CVE-2025-23120 (CVSS 9.9) only impacts domain-joined backup servers. Backup servers running as workgroup hosts, which is Veeam’s own long-standing hardening recommendation, are not affected. A shop with 200 VBR servers, 30 of them domain-joined, had 30 exposed assets. Scanners fingerprinting by version banner alone reported all 200.

It can also be subtler than that. Veeam CVE-2024-40711 carried CVSS 9.8 across 12.1.2.172-and-earlier, but watchTowr’s disclosure showed the unauthenticated path was only present on 12.1.1.56 and earlier. Versions in between had a partial fix that downgraded the same CVE ID to authenticated-only RCE. Same CVE, same score, materially different exposure depending on minor build.

The more useful reading habit: read the vendor’s workaround section before the CVSS. When Fortinet says disable SSL-VPN, or Veeam says the boundary is domain-joined versus not, they’re telling you exactly what the prerequisite is.

Filter 2: reachability

A CVE that survives Filter 1 still has to be reachable. The second question is whether an attacker can actually get to the vulnerable interface given network position, access controls, and trust boundaries.

SonicWall CVE-2024-40766 (CVSS 9.3) is the case where exposure is the bug. An improper-access-control flaw in SonicOS that Akira and Fog ransomware affiliates have been using for initial access since mid-2024, with Arctic Wolf reporting roughly 40 SonicWall intrusions in July 2025 alone. SonicWall’s own mitigation reads like a reachability checklist: restrict SSLVPN access to trusted sources, disable it entirely if not needed. An identical box with the SSL-VPN listener ACL’d or geo-fenced was effectively un-exploitable.

The Cisco ASA ArcaneDoor pair, CVE-2025-20333 (CVSS 9.9, post-auth RCE) chained with CVE-2025-20362 (6.5, unauth endpoint exposure), gives root on the firewall. CISA’s Emergency Directive 25-03 (September 2025) scoped mitigation specifically to public-facing Cisco ASA hardware. Same code, same CVSS, very different urgency depending on whether the VPN web server is reachable from the internet.

There’s also the boundary that flips on a checkbox. Atlassian Confluence CVE-2023-22522 was originally rated as requiring authentication. The detail buried in the advisory is that it can be exploited by users with anonymous-access permissions when that’s enabled. Plenty of Confluence Server/DC instances have anonymous read enabled on at least one space. Treating it as “post-auth, lower priority” was a category error for any instance with anonymous access turned on. Post-auth is a question, not an answer.

The principle works in reverse, too. Starting with Windows 11 24H2 and Server 2025, SMB signing is required by default on outbound and inbound connections for Pro/Enterprise/Education builds. A long tail of NTLM relay and SMB-shenanigans CVEs that mattered acutely on Windows 10 / Server 2019 fleets are largely defanged on a fresh 24H2/2025 estate. Same theoretical bug, different urgency because the default changed under it.

And then there’s segmentation. Change Healthcare’s February 2024 incident wasn’t a CVE story. BlackCat affiliates logged into a Citrix portal with no MFA using stolen credentials, moved laterally for nine days, and deployed ransomware. The breach is now confirmed at roughly 190 million people, the largest US healthcare breach on record. Citrix wasn’t isolated from sensitive systems. In a flat network, the “boring” CVE on the jump host matters far more than the same CVE in a properly tiered one.

Filter 3: exploitation signal layering

If a CVE survives applicability and reachability, the third question is what the available signals say about real-world risk. Four are worth checking: CVSS for severity ceiling, EPSS for probability of exploitation in the next 30 days, CISA KEV for confirmed exploitation, and the vendor’s own exploitation flag. None of them work alone.

CVSS-only fails the way CVE-2026-32202 demonstrated. Vendor-flag-only fails the way CVE-2024-26234 did: Microsoft published the April 2024 advisory with no exploitation indicator, then revised it the same day after Sophos posted proof of in-the-wild use. EPSS-only fails because roughly 88% of all CVEs sit below 0.10, which means “low EPSS” sweeps in nearly the entire catalog including occasional surprises (CVE-2026-32202 was one of them until April 27). KEV-only fails at the front edge. KEV is high-precision but it lags. CVE-2026-32202 hit the catalog the day after public exploitation was reported. CVE-2025-59287 (WSUS unauthenticated RCE, CVSS 9.8) hit KEV the day after Huntress and Unit 42 observed mass exploitation. If KEV is your only trigger, your patch cycle starts after the attackers’ does.

The more interesting detail is what NIST did on April 15, 2026. After CVE submissions grew 263% between 2020 and 2025, NVD shifted to risk-based triage. Only CVEs on KEV, used by federal systems, or qualifying as critical software under EO 14028 will get full enrichment, which NIST estimates at 15-20% of incoming volume. The other roughly 80% won’t get a CVSS score or a CPE list from NIST at all. Any triage pipeline that looks up “the NVD CVSS” or “the NVD CPE list” to decide whether you’re affected now misses four out of five new CVEs. Scanner output gets noisier; KEV becomes structurally more important not just as a signal but as the enrichment gate that decides which CVEs your tooling can even parse.

The pragmatic combination: KEV first as a hard signal (act). EPSS above roughly 0.1 paired with CVSS at or above 7 as a queue-with-intent input. Everything else into normal cadence after Filters 1 and 2. Vendor flag as early-warning supplement, never the sole gate.

What this means for prioritization

The three filters aren’t a checklist. They’re a way of reading the queue, ordered to drop candidates fastest.

The framework that codifies the same idea is SSVC (Stakeholder-Specific Vulnerability Categorization), originally from CERT/CC in 2019 and adopted in customized form by CISA in 2022. CISA’s deployer-tree variant runs five inputs (exploitation status, technical impact, automatable, mission prevalence, public well-being impact) into four outputs: Track, Track*, Attend, Act. The point is to make priority a function of your environment, not a global score.

CVSS v4.0, released November 2023, restructured its metric groups into Base / Threat / Environmental / Supplemental, and FIRST introduced the CVSS-B / CVSS-BT / CVSS-BE / CVSS-BTE naming convention specifically to push consumers away from quoting Base-only scores. FIRST themselves are saying out loud that the number on the NVD page is not the answer.

Business-impact tiering layers on top of these filters, not in front of them. A 10.0 that doesn’t apply doesn’t need to be tiered. A 7.5 that’s reachable on a revenue-generating system does. The companion piece on business-impact prioritization handles the layer above; this one handles the applicability and exposure decisions upstream.

PatchDay Alert is built around the same distinction. The daily digest flags CVEs when the exploitation signal changes, not just when the patch ships, which is the gap that put CVE-2026-32202 in the routine bucket for 13 days.

What to watch

Two structural conditions to watch through the rest of 2026.

The first is how badly the NVD enrichment cutback degrades scanner output in practice. Most scanners haven’t shipped major remediation logic changes yet. Watch for vendor updates that explicitly handle missing CPE and CVSS for the 80% of new CVEs that NIST is no longer enriching.

The second is whether CVSS v4.0 adoption picks up. As of mid-2026, the majority of NVD CVE records still display v3.1, which means the Threat and Environmental groups, the ones designed for environment-specific context, aren’t doing any work for the people who most need them.

When the next low-CVSS, high-KEV event lands, and it will, the gap will look exactly like CVE-2026-32202’s gap. The conditions that produced it haven’t changed. The teams that catch it early will be the ones already running the three filters.