How to Triage a CVE from Raw Feed to Actionable Priority

TL;DR

Every day, 50–200 new CVEs hit the NVD. Most are noise for your stack. This post walks through a reproducible triage workflow: pull the CVE data, cross-reference your asset inventory, check KEV/EPSS, verify exploitability, and land on a decision — patch, mitigate, or drop. Uses this week’s Zammad CVE-2026-102490 as the running example.

The Problem: CVE Feed Noise

If you follow the NVD API or any CVE RSS feed, you’ve seen it: a wall of 200 CVE IDs with no context about whether any of them matter to you. Feeding every new CVE to the team at triage level causes alert fatigue and makes actual priorities hard to find.

The fix isn’t filtering by CVSS score. It’s a structured workflow that connects the CVE to your assets before the clock starts.

The Workflow

Step 1: Fetch the CVE Record

Never triage from the RSS summary line. Pull the full record.

curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-102490" | jq '.vulnerabilities[0].cve'

From the record, extract:

• Affected products and versions (CPE strings or explicit version ranges)
• Description (what breaks, and in what way)
• CVSS vector (base score, attack vector, complexity, privileges required)
• References (vendor advisory, PoC, blog post)

If the NVD hasn’t published yet (common in the first 24–48 hours after disclosure), pull from the CNA’s page directly. CVE-2026-102490 was first published by DIVD (Dutch Institute for Vulnerability Disclosure), not NVD. The NVD record came later with enriched data.

Step 2: Check KEV Status

curl -s "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-102490" | grep -i "due date"

If the CVE is in the KEV catalog, you have a hard deadline. CISA’s BOD 22-01 requires remediation within 2 weeks (for federal), and BOD 26-04 extends similar timelines to critical infrastructure. For private orgs, KEV is the strongest signal that active exploitation exists — this isn’t theoretical.

CVE-2026-102490 was added to KEV on October 2 with a due date of October 5. That’s 72 hours.

Step 3: Check EPSS

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-102490" | jq

EPSS gives you a probability score (0–1) for exploitation in the next 30 days. CVE-2026-102490 has an EPSS score of ~0.006 (0.6%, 48th percentile) — meaning about 6 in 1,000 similar CVEs get exploited in that window. Not high, but KEV overrides: it’s already in the wild.

Rule: KEV status trumps EPSS. If a CVE is in KEV, it’s exploited regardless of what EPSS says. EPSS is a forward-looking signal for things not yet in KEV.

Step 4: Cross-Reference Asset Inventory

This is where triage gets real. Check whether your stack runs the affected software:

CVE-2026-102490 → Zammad 1.5.0 < 7.1.0-alpha (all versions) → Do we use Zammad? → Yes (v6.8.0) → PATCH

The affected versions line says “all versions < 7.1.0-alpha.” If you run Zammad 6.8.0, you’re affected. If you don’t run Zammad, you’re done — this CVE is noise.

This step requires a maintained asset inventory. If you don’t have one, start with:

• CMDB (if you use one)
• Docker/container image inventory
• Ansible/Puppet config outputs
• Simple dpkg -l, rpm -qa, pip freeze, go list -m all on each host

For the running example: a mid-size org using Zammad for ticketing would be affected. A startup using Zendesk instead? This CVE doesn’t apply.

Step 5: Verify Exploitability

Two sub-steps here:

a) Check the vendor advisory. DIVD’s advisory (csirt.divd.nl/CVE-2026-102490) confirms: the local zammad user can escalate to root. The companion CVE-2026-102489 (session fixation → RCE) can be chained with this privilege escalation for a full remote exploit chain.

b) Look for PoC code. Search GitHub, Exploit-DB, and Twitter for working proof-of-concepts. If PoC code exists and works against your version, the exploitability confidence goes up.

For CVE-2026-102490, DIVD published a working PoC showing root escalation via the /api/v1/tickets endpoint. No auth required beyond the local zammad user.

Step 6: Make the Decision

Apply one of four outcomes:

For CVE-2026-102490 with a Zammad installation: patch immediately. The CVE is in KEV, due Oct 5, and PoC is confirmed.

Real-World: This Week’s KEV Additions

This week’s KEV batch included several entries that demonstrate the triage workflow in action:

• CVE-2026-102490 (Zammad, KEV Oct 2, due Oct 5) — Local priv esc to root, chained with CVE-2026-102489 (session fixation → RCE). Affects all Zammad < 7.1.0-alpha.
• CVE-2026-88779 (Citrix NetScaler, KEV Oct 4, due Oct 7) — Memory buffer restriction, potential DoS. Due Oct 7 is tight (48h).
• CVE-2026-76504 (Cisco SD-WAN, KEV Sep 30) — Hex encoding issue allows unauthenticated admin access.

Each follows the same pattern: fetch record → check KEV/EPSS → match inventory → verify exploitability → decide.

Common Triage Mistakes

Mistake 1: Triaging CVSS without checking asset inventory. A CVSS 9.8 on an application you don’t run is less urgent than a CVSS 5.3 on your internet-facing Zammad instance.

Mistake 2: Waiting for the NVD record. The NVD enriches later — CNA advisories come first. Don’t delay triage waiting for NVD’s version of the data.

Mistake 3: Dropping low-EPSS CVEs without checking KEV. EPSS is probabilistic. A CVE with 0.1% EPSS that’s also in KEV is actively exploited — the EPSS hasn’t caught up yet.

Mistake 4: Triaging without version matching. “Affected: all versions” doesn’t mean “all installations of this software are affected.” Check your specific version against the vendor’s range.

Mistake 5: Skipping the exploitability check. CVSS describes potential impact. Exploitability describes likelihood. Both matter. A CVSS 7.5 with PoC code and KEV status is more urgent than a CVSS 9.0 with no exploit in the wild.

The Triage Checklist

A quick reference for daily triage:

1. Pull full CVE record (NVD or CNA advisory)
2. Note affected products/versions and CVSS vector
3. Check KEV status (and due date)
4. Check EPSS score (forward-looking signal)
5. Cross-reference against asset inventory
6. Verify exploitability (vendor advisory, PoC, blog)
7. Decide: patch / mitigate / monitor / drop
8. Log the decision and rationale

Steps 3–5 should run automatically from your RSS digest. Step 6 requires a human look. Step 7 is where experience matters.

Conclusion

Triage isn’t about reading every CVE. It’s about having a repeatable workflow that turns a CVE ID into a decision in under five minutes per item. The workflow scales: automation handles the data fetching and asset matching, and humans handle exploitability verification and edge cases.

The goal isn’t to process 200 CVEs a day. It’s to process the 3–5 that matter to your stack, and drop the rest with confidence.

Further Reading

• CISA KEV Catalog
• EPSS API
• BOD 26-04: Prioritizing Security Updates Based on Risk
• DIVD CVE-2026-102490 Advisory
• NVD API Documentation