KEV prioritization notes

Public-data triage of recent CISA Known Exploited Vulnerabilities. The goal is to turn an exploited-vulnerability feed into owner questions, platform groups, and first actions.

Snapshot

Item	Current state
Source pull	2026-07-24 CISA KEV CSV
Catalog size at verification	1,653 KEV rows
Curated sample	14 recent rows
Product groups	SharePoint, WordPress, FortiSandbox, SonicWall SMA1000, Oracle EBS, Langflow, DD-WRT, Check Point SmartConsole, ADFS, KNX
Output	Team briefing, methodology, full dataset, rebuild script
Safety boundary	No exploit code, scanning, paid intel, or private telemetry

flowchart LR
    A["CISA KEV CSV"] --> B["curated sample"]
    B --> C["platform grouping"]
    C --> D["priority label"]
    D --> E["first defender action"]

Loading

This is a small vulnerability prioritization exercise built around a simple question:

If several vulnerabilities are already known to be exploited, what would I look at before deciding what gets handled first?

The point is not to reproduce a scanner report or publish exploit steps. The point is to show defender judgment: exposure, exploit evidence, affected product, business reach, deadline pressure, and what action would actually reduce risk.

What I used

• CISA Known Exploited Vulnerabilities catalog, pulled on 2026-07-24.
• VulnCheck public KEV criteria and documentation as the research lens.
• Vendor advisories linked from CISA KEV entries.
• NVD links from CISA notes for CVE record cross-checking.

This first pass uses public data only. I did not query VulnCheck's authenticated API in this workspace.

Why this exists

CVSS is useful, but it is not enough by itself.

A vulnerability with active exploitation, a common internet-facing product, a short remediation window, and clear attacker utility can be more urgent than a higher-scoring issue that is not reachable in your environment.

For this pass, I sorted recent KEV additions by:

1. Confirmed exploited status through CISA KEV.
2. Product exposure type.
3. Likely attacker utility.
4. Due date pressure from CISA.
5. Whether the issue chains with another CVE.
6. Whether defenders can take a concrete action quickly.

The scoring logic is documented in METHODOLOGY.md. Platform grouping notes are in analysis/triage-notes.md.

For a short version written like a team update, see BRIEFING.md.

Current sample

The full 14-row sample is in DATASET.md and data/recent-cisa-kev-sample.csv.

Workstream	Sample CVEs	First move
SharePoint	CVE-2026-58644, CVE-2026-50522	One platform owner review for patch state, exposure, and pre-patch logs.
WordPress	CVE-2026-63030, CVE-2026-60137	Treat as a chain and review public sites before splitting into separate tickets.
Edge appliances	CVE-2026-25089, CVE-2026-39808, CVE-2026-15409, CVE-2026-15410, CVE-2021-27137	Patch or isolate fast, then review management access and appliance logs.
Business applications	CVE-2026-46817	Verify Oracle EBS exposure and preserve HTTP/authentication logs.
AI workflow tooling	CVE-2026-0770	Check exposure and access control before arguing about score.
Identity and admin tools	CVE-2026-56155, CVE-2026-16232	Validate privileged access, patch state, and admin token/session evidence.
Building automation	CVE-2023-4346	Find the real owner and confirm whether normal IT has visibility.

Observations

The first thing that jumps out is clustering. SharePoint shows up twice, WordPress shows up twice, appliance classes repeat, and several entries involve systems that often sit close to the edge of an environment.

That changes the workflow. I would not treat these as 14 unrelated rows. I would group by platform owner and exposed surface:

• SharePoint: verify patch state, exposure, and suspicious web requests.
• WordPress: treat the two CVEs as a chain, not separate chores.
• Edge and appliance tech: isolate first if patching will take time.
• Oracle EBS: treat payment-system exposure as a business owner problem, not only an IT ticket.
• AI workflow tooling: check whether the tool is reachable beyond trusted users.
• Identity/admin tools: check privileged access and token/session evidence.

The second thing is deadline pressure. Several entries in the sample have a due date of 2026-07-24 or earlier. That does not automatically mean every organization has the same risk, but it does mean the question should move from "is this important?" to "where do we own this and is it reachable?"

For the fuller notes, see analysis/triage-notes.md.

What I would ask in a real environment

• Do we own this product or a managed service version of it?
• Is it internet-facing, partner-facing, VPN-only, or internal-only?
• Do we have a vulnerable version or only a product family match?
• Is there active exploitation evidence or only theoretical severity?
• Are logs retained long enough to check pre-patch activity?
• Can we isolate the system if patching cannot happen today?
• Who owns the product and who can approve emergency change?

Limits

• This is not an exploit project.
• This is not a full threat intel report.
• The priority labels are a reasoning exercise, not universal truth.
• The sample uses public KEV and vendor-linked data. It does not include paid intelligence, telemetry, asset inventory, or private incident data.

Reproduce

Run the refresh script from a PowerShell prompt:

powershell -ExecutionPolicy Bypass -File .\scripts\refresh-cisa-kev.ps1

The script downloads the current CISA KEV CSV into data/ with a timestamped filename. Those local downloads are ignored by Git so the repo does not fill up with snapshots.

Additional checks are in VERIFY.md.

Files

• data/recent-cisa-kev-sample.csv: 14 recent KEV entries with a lightweight prioritization layer.
• BRIEFING.md: short team-facing summary of what I would act on first.
• DATASET.md: readable view of the full curated dataset.
• METHODOLOGY.md: scoring rubric, assumptions, and limits.
• analysis/triage-notes.md: platform grouping notes from the current sample.
• scripts/build-sample.ps1: rebuilds the curated sample from the live CISA KEV CSV while preserving the manual priority notes.
• scripts/refresh-cisa-kev.ps1: pulls the latest CISA KEV CSV and writes a timestamped local copy.
• SOURCES.md: source links used for the first pass.
• VERIFY.md: commands used to verify the repo.