Patch what is exposed and exploitable first.
A severity score is useful context, not a complete queue. Prioritize with real exploitation evidence, reachable attack paths, affected versions, business impact, available fixes, and the strength of temporary controls.
Six questions
- Is exploitation known? Check authoritative vendor notices and the CISA Known Exploited Vulnerabilities Catalog.
- Are we actually affected? Confirm the installed product, edition, configuration, and version rather than matching only a product name.
- Is the vulnerable path reachable? Internet-facing, unauthenticated, administrative, local-only, and disabled features have different urgency.
- What can an attacker gain? Consider code execution, authentication bypass, data exposure, privilege escalation, denial of service, and persistence.
- Is a supported fix ready? Prefer the vendor patch, supported upgrade, feature disablement, or component removal.
- What reduces risk meanwhile? Use narrow WAF rules, access restrictions, segmentation, monitoring, or isolation while scheduling the permanent fix.
Practical priority bands
Emergency
Known exploitation plus affected and reachable systems, especially unauthenticated code execution, authentication bypass, or sensitive-data access.
Urgent
High-impact exposure with credible exploitability, a public proof of concept, weak prerequisites, or important externally reachable services.
Scheduled
Affected systems with meaningful prerequisites, limited exposure, strong compensating controls, or lower operational impact.
Monitor or not affected
Version or configuration is not affected, the component is absent, or available evidence is insufficient. Record the reason and revisit when facts change.
Do not confuse these signals
- CVSS: a standardized severity description, not proof of exploitation or your exposure.
- CISA KEV: evidence that a vulnerability has been exploited in the wild, not proof that every environment contains the affected product.
- Public exploit: may increase likelihood, but still requires version, configuration, and reachability analysis.
- WAF block: evidence that one request shape was stopped, not proof the vulnerable code is repaired.
- Scanner finding: a lead to validate, not automatically a confirmed compromise.
Record the decision
- CVE and vendor advisory.
- Affected asset and owner.
- Installed and fixed versions.
- Exposure and prerequisites.
- Known exploitation status.
- Business impact.
- Temporary controls and expiry.
- Patch window and rollback.
- Validation evidence.
- Final disposition.