Severity Scores Don't Tell You What to Fix First

On 22 September 2026, WordPress released version 7.1.2 to address CVE-2026-87902, a vulnerability that could allow remote code execution under specific server and theme conditions.

Within hours, Patchstack observed attackers probing websites for the weakness. By the following day, the company reported more than ten times the traffic observed during the first evening. Requests had also progressed from checking vulnerable systems to attempting to write PHP files.

For security teams, the question was no longer simply how severe the vulnerability was. It was which of their websites were affected, whether the exploit conditions were present, and who could act before the attacks progressed further.

A CVSS base score cannot answer those operational questions on its own.

Why Severity-Based Prioritisation Falls Short

Severity-based queues remain attractive because they are consistent, easy to automate and straightforward to explain during an audit.

However, three operational gaps can undermine the resulting remediation order:

Missing assets: A website maintained by a regional office or external agency may never enter the scanning inventory.

Unverified findings: A vulnerable software version does not always establish whether every condition required for exploitation exists.

Missing ownership: A confirmed critical exposure may remain unresolved because no team is authorised to patch the application.

On 10 June 2026, CISA issued Binding Operational Directive 26-04, requiring covered US federal agencies to prioritise remediation using asset exposure, known exploitation, exploit automation and the technical impact of exploitation.

CISA also ended its weekly severity-organised Vulnerability Bulletin after the 28 September 2026 edition as part of its transition towards risk-based vulnerability management.

Severity remains important, but remediation decisions also require evidence about the affected system and its actual exposure.

How Threat Intelligence Changes Vulnerability Priorities

Threat intelligence changes a remediation priority when it provides relevant evidence about the technology or systems an organisation uses. CTM360 organises its intelligence around Indicators of Exposure, Warning and Attack. In vulnerability management, the distinction can be illustrated as follows:

Indicators of Exposure (IoE): Exposure conditions, such as an internet-facing service running a vulnerable software component or an insecure configuration.

Indicators of Warning (IoW): Threat signals with an evidence-backed connection to the organisation, such as exploitation activity involving technology it uses.

Indicators of Attack (IoA): Evidence of active targeting, such as verified attempts to exploit one of the organisation's applications.

For example, reports of exploitation affecting a technology in the Digital Asset Register give the team a reason to reassess related findings. If the SOC confirms attempts against an affected application, the response also needs to include investigation of possible compromise.

How to Prioritise Vulnerabilities Based on Actual Risk

Begin with a manageable set of findings that includes known-exploited vulnerabilities and exposures affecting business-critical systems, including relevant findings below the top severity band. Confirm which assets and software versions are affected as part of triage.

Use four questions to establish the remediation priority:

How easily could attackers exploit it? Is there a known method of attack, or evidence that the vulnerability is already being exploited?

How important is the affected system? Does it support critical operations, store sensitive information, or provide access to other important systems?

Can attackers reach the system? Is it publicly accessible, or is there a realistic path from another compromised system? Check whether existing controls actually restrict that path.

What would happen if the system were compromised? Could it disrupt services, expose customer information, or affect business operations?

Validate the finding and relevant exploit conditions, then record the priority, supporting evidence, remediation owner and target date. Confirm the result after remediation before closing the finding.

Remediation priority depends on the affected asset, exploitation evidence, business impact and who can act.

What Should the Board Actually Measure?

Traditional vulnerability reports often focus on open findings grouped by severity. That approach measures backlog volume but may overlook important questions: How complete is monitoring? Which exposures have been validated? What remains unresolved?

Consider the following illustrative before-and-after reporting example.

Before

The quarterly security report states that 120 critical vulnerabilities remain open, without identifying whether all external applications are monitored or which findings are most urgent.

After

Asset reconciliation identifies 50 externally visible applications. A focused review of the 40 applications under routine monitoring selects 12 validated priority exposures from the original backlog. The report presents:

50 externally visible applications identified, of which 40 are covered by routine monitoring.

20% monitoring gap, representing 10 applications requiring assessment.

12 validated priority exposures on monitored applications, of which eight have been patched and rechecked to verify resolution.

Two exposures temporarily mitigated, pending permanent remediation.

Two exposures unresolved, including one without a confirmed remediation owner.

Eight verified closures out of 12 priority exposures give a patch completion rate of approximately 67% for that selected group. The other 108 findings remain tracked in the wider backlog. The percentage does not describe progress across all 120 findings or quantify the reduction in overall cyber risk.

The report also keeps temporary mitigations and unassessed applications visible. Temporary controls should have an owner and a review date while permanent remediation remains pending.

These figures are hypothetical. They demonstrate a reporting method, not measured CTM360 customer outcomes.

For continued oversight, CISOs should also track the time required to identify an exposure, assign an owner, complete remediation and verify the fix.

Who Should Own the Response?

Prioritisation is incomplete until a responsible team can act on the finding. A practical response ownership matrix might look like this:

For applications managed by external providers, the internal business owner should remain accountable for coordinating remediation.

A vulnerability should not disappear from management attention simply because ownership is uncertain.

How CTM360 Supports Exposure Validation

HackerView maintains the Digital Asset Register of external assets and identifies exposures such as vulnerable technologies, exposed services and misconfigurations. DeepScan runs technology-specific, active but non-intrusive checks to help validate whether a vulnerability affects a system.

These capabilities operate on CTM360's consolidated platform, providing asset-specific evidence to support remediation decisions.

Request a demo to see how HackerView and DeepScan identify external assets and validate relevant exposures.

FAQs

1. Our vulnerability scanner found thousands of issues. How do we decide what to fix first?

Start with vulnerabilities that have evidence of exploitation or a realistic attack path to important systems. Consider whether the affected asset is exposed, what business function it supports, which controls are effective and whether the finding has been validated. Assign a remediation owner and track the issue through to verified resolution.

2. Can a medium-severity vulnerability be more urgent than a critical one?

Yes. A medium-severity vulnerability under active exploitation on an exposed customer application may require more immediate attention than a critical vulnerability on an isolated development system. Internal systems can also create serious risks when attackers have a realistic path to sensitive data or critical infrastructure. Priority depends on the evidence of exploitation, attack paths, effective controls and business impact alongside severity.

3. Should we prioritise vulnerabilities using CVSS, EPSS or CISA KEV?

Use all three as inputs. CVSS base scores describe technical severity; Threat and Environmental metrics can add context. EPSS estimates the probability that a published vulnerability will be exploited in the wild within the next 30 days. It does not estimate the probability that your organisation will be compromised. CISA KEV identifies vulnerabilities with confirmed exploitation in the wild. Combine these signals with asset exposure, effective controls and business criticality, giving observed exploitation appropriate weight over predictions.

4. Does a vulnerability appearing in CISA KEV mean our system has been compromised?

No. KEV inclusion confirms exploitation in the wild. Organisations must separately establish whether their systems are affected and investigate evidence of compromise. Applying a patch addresses the vulnerability but does not establish whether an attacker accessed the system beforehand.