TL;DR: Multiple KEV-listed vulnerabilities, including CVSS 10 flaws in Adobe ColdFusion and Ubiquiti UniFi OS, are being prioritised because they are actively exploited and not merely high severity, according to Senserva. The practical lesson is to rank patching by exploitation status, exposure, and business criticality, not by score alone.
At a glance
What this is: Senserva highlights that KEV-listed, actively exploited vulnerabilities in ColdFusion, UniFi OS, SharePoint, WordPress and Exchange should outrank CVSS-only patch decisions.
Why it matters: For IAM, PAM and broader security teams, the lesson is to prioritise remediation by real-world exploitation and asset exposure, not by severity scores alone.
Context
CISA KEV listing changes the meaning of vulnerability priority. A perfect CVSS score still tells you only that a flaw can be severe, not that it is being used in the wild, and patch teams that rely on score alone can easily miss the issues most likely to become an access path.
For identity and access programmes, the governance implication is direct: exploitable internet-facing systems, legacy platforms and admin-facing services create downstream account, privilege and session risk even when the vulnerability itself is not an identity flaw. The control gap is prioritisation discipline, not just patch volume.
Key questions
Q: What should teams do first when a vulnerability is added to CISA’s KEV catalog?
A: Treat the item as an active exploitation concern, not a normal patch ticket. Confirm whether the affected asset is internet-facing, verify patch state, and check for signs of compromise before moving on to lower-risk backlog items. The fastest reduction in exposure comes from pairing remediation with containment and log review.
Q: Why do KEV-listed flaws matter more than high CVSS scores alone?
A: KEV-listed flaws matter because they reflect observed exploitation, not just theoretical impact. A lower-scoring issue that is actively used by attackers can create more immediate risk than a higher-scoring issue that has not been weaponised in the wild. Prioritisation should follow attacker behaviour.
Q: What breaks when patching is ranked only by severity scores?
A: Severity-only patching often leaves exposed, actively exploited systems sitting behind cosmetic priorities while teams spend time on issues that are easier to measure but less urgent. The failure is not technical patching itself, but the queueing logic that ignores live exploitation and asset exposure.
Q: How should organisations handle remediation when KEV items affect identity-adjacent systems?
A: When KEV items hit Exchange, SharePoint, VPNs or admin platforms, organisations should escalate them across IAM, PAM and platform operations as potential access-path incidents. Those systems can turn a vulnerability into privileged access or session abuse, so the response needs shared ownership, not siloed ticketing.
Technical breakdown
Why KEV status changes patch order
The CISA Known Exploited Vulnerabilities catalog is a threat-informed signal, not a theoretical severity measure. CVSS estimates impact and exploitability in the abstract, while KEV indicates that exploitation has already been observed or reported. That distinction matters because a lower-scoring flaw with live exploitation can be more urgent than a higher-scoring issue with no active attack activity. Patch programmes that ignore this end up optimising for score instead of adversary behaviour, which is the wrong control objective.
Practical implication: use KEV presence as a hard prioritisation input before you sort by CVSS or EPSS.
How patch queues should blend exposure and business criticality
A vulnerability becomes materially more dangerous when it sits on an internet-facing service, an admin platform, or a system that supports authentication, federation, or privileged operations. In that case, the patch decision is not just about technical severity but about blast radius. Internet exposure, legacy support constraints, and business dependency all change the order in which remediation should happen. This is especially true where exploited software sits adjacent to identity infrastructure or remote administration paths, because the attacker does not need the most severe flaw if they can reach the most useful one.
Practical implication: rank exposed, high-value systems ahead of internal-only assets even when the internal asset has a higher CVSS score.
Why EPSS helps, but does not replace exploitation evidence
EPSS estimates the probability that a vulnerability will be exploited, which makes it a useful refinement to patch triage. But it is still probabilistic, while KEV reflects observed exploitation pressure. When both are present, teams get a clearer view of urgency, especially for older CVEs that remain attractive because they are still exposed in forgotten systems. The operational mistake is treating EPSS as a substitute for incident-aware threat intelligence. It is best used as a secondary lens after KEV and asset exposure have already shaped the queue.
Practical implication: use EPSS to sort within your KEV backlog, not to decide whether a KEV item deserves attention.
Threat narrative
Attacker objective: The attacker’s objective is to turn a publicly known, actively exploited flaw into reliable access, execution or administrative control before defenders patch it.
- Entry occurs through an internet-facing application or service with a publicly known vulnerability that is already being exploited in the wild.
- Attackers then use the flaw to gain unauthorized execution, traversal or authentication bypass, depending on the product and issue type.
- Once inside, they can reach administrative functions, pivot into connected services or use the compromised system as a foothold for broader access.
- The impact is account compromise, remote code execution, privileged access, or a pathway to wider environment control.
Breaches seen in the wild
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Patch prioritisation has become an exploitation governance problem, not a vulnerability scoring problem. CVSS remains useful, but it cannot tell a defender which flaw is being operationalised right now. KEV status changes the control objective from catalogue management to risk reduction under adversary pressure. Practitioners should treat exploited exposure as a governance trigger and not wait for perfect remediation windows.
KEV-backed patch queues expose the weakness of score-first operating models. Many vulnerability programmes still sort by severity and then hope business context is added later, which is too slow for live exploitation. The better model is exposure first, KEV second, then score and business criticality. That sequence turns patching into a decision process aligned to attacker behaviour instead of a reporting exercise.
Identity-adjacent systems deserve separate urgency because they widen the blast radius of every exploit. When a KEV-listed flaw sits on Exchange, SharePoint, VPN, admin consoles or other access-bearing services, the vulnerability is no longer just a server issue. It can become a credential, session or privilege problem very quickly. That means IAM, PAM and platform teams need shared triage rules, not separate queues that delay response.
Exploitability metrics are most valuable when they are used to reorder, not justify, remediation. EPSS can help distinguish between several urgent items, but it should not be the gate that decides whether a KEV entry is acted on. The governance signal here is simple: if a vulnerability is known to be exploited and the asset is exposed, remediation should already be in motion. Patch teams should use this as the default operating rule.
From our research library:
- The median time to fully patch a vulnerability in CISA's Known Exploited Vulnerabilities catalog rose to 43 days, according to Verizon's 2026 Data Breach Investigations Report.
What this signals
KEV-driven prioritisation is the clearest practical test of whether vulnerability management is threat-informed. If a programme still lets CVSS override exploitation evidence, it is not responding to current attacker behaviour. That matters most where internet-facing systems and admin services sit close to IAM and PAM functions, because the patch queue is also the access-risk queue.
Patch teams should expect more pressure to prove why an exploited vulnerability was left unpatched. The governance burden is shifting from backlog reporting to decision accountability, especially when public KEV signals and vendor advisories already exist. For practitioners, the question is no longer whether every flaw is fixed, but whether the highest-risk exposed flaw is fixed first.
For practitioners
- Prioritise KEV-listed vulnerabilities before CVSS-only findings Build patch queues so that CISA KEV presence automatically moves an issue into the highest remediation tier, then sort that tier by exposure and business criticality.
- Tag internet-facing identity and admin systems as urgent Create a separate remediation lane for Exchange, SharePoint, VPN, remote management and other access-bearing platforms because exploitation there can quickly expand privilege and session risk.
- Use EPSS only to order the urgent backlog Apply EPSS after KEV and exposure have already determined priority, so probabilistic scoring does not delay fixes for confirmed exploitation.
- Include legacy systems in every KEV review Check older Windows and other long-tail platforms during each patch cycle because attackers often target forgotten assets that remain reachable even when primary systems are current.
- Align patch decisions across IAM, PAM and platform teams Set a shared escalation rule for systems that can affect authentication, federation or privileged administration so exploitation risk is handled consistently.
Key takeaways
- KEV-listed vulnerabilities change patch priority because they are already being exploited, which makes them operationally different from unexploited high-severity findings.
- The article’s examples show why exposure, admin reach and business criticality often matter more than CVSS when teams decide what to patch first.
- Security teams should treat KEV status as the top triage signal, then use EPSS and asset context to order the remaining urgent work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Actively exploited flaws create the entry conditions for credential access and later movement. |
| Recommendation — Map KEV-listed exposures to ATT&CK credential access and lateral movement to prioritise monitoring and remediation. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities Identified and Prioritised | The article is fundamentally about prioritising vulnerabilities by real-world risk. |
| Recommendation — Prioritise vulnerabilities using threat-informed risk criteria rather than severity scores alone. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This is a patch triage and remediation discipline article centered on active vulnerability management. |
| Recommendation — Use continuous vulnerability management to elevate exploited weaknesses ahead of routine backlog items. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The article depends on monitoring known exploited vulnerabilities and tracking remediation status. |
| Recommendation — Apply RA-5 to keep exploited vulnerabilities visible until they are remediated. | ||
Key terms
- Known Exploited Vulnerability: A Known Exploited Vulnerability is a flaw that has confirmed active exploitation in the wild and is tracked for urgent remediation. In governance terms, KEV status turns patching from a general hygiene task into a time-bound operational obligation.
- Patch Prioritisation: Patch prioritisation is the process of deciding which fixes must be applied first based on real-world risk, exploitability, asset exposure, and business impact. Good prioritisation combines vulnerability data with inventory, privilege scope, and operational criticality so teams fix what attackers can actually reach.
- Exploitability signal: Any indicator that a vulnerability is likely to be used soon or is already being used, such as exploitability ratings, proof-of-concept code, or catalog membership. These signals help convert a long vulnerability list into a shorter response queue.
- Internet-Facing Asset: An internet-facing asset is any system, service, or resource reachable from the public internet. That can include production hosts, cloud storage, APIs, staging systems, and remote consoles. These assets matter because attackers can enumerate and test them without internal access, making misconfigurations and forgotten services immediate security concerns.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM and secrets management for practitioners who need to connect identity controls to wider security operations. It helps teams apply identity thinking to access, privilege and lifecycle governance across the programme.
Published by the NHIMG editorial team on July 22, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org