CVE Prioritization with EPSS and CERT-Bund: Patch What's Under Attack

A vulnerability with a CVSS score of 9.2 sounds like a red alert. However, there are many CVEs classified as ‘critical’, and IT teams never have enough time to deal with them all at once. Those who stubbornly patch based on severity simply work their way through a list and, when in doubt, may well overlook the very vulnerability that is currently being exploited.

The better question is therefore: Which vulnerability is most likely to be exploited, and does it affect our systems? Three data sources help provide the answer: CVSS, EPSS and CERT-Bund.

CVSS measures severity, not risk

The value of the Common Vulnerability Scoring System (CVSS) describes the technical severity of a vulnerability. The assessment takes into account the attack vector, complexity and the impact on confidentiality, integrity and availability. There are currently two versions in use, CVSS 3.1 and CVSS 4.0.

The problem is that the CVSS score does not indicate whether a vulnerability will ever be exploited in a real-world attack. Nevertheless, many vulnerability management programmes prioritise vulnerabilities based solely on this score. As a result, vulnerabilities with a medium score – which have long been actively exploited – are left unaddressed, whilst the team spends time on vulnerabilities rated as critical for which no exploit exists.

EPSS shows which vulnerabilities are actually being exploited

The Exploit Prediction Scoring System (EPSS) from FIRST.org comes into play precisely here. For each CVE, it calculates a probability between 0 and 1 of it being exploited in the next 30 days. To do this, the model analyses, amongst other things, published exploit code and observed attack activity. According to FIRST.org, the values are recalculated daily, so the prioritisation changes in line with the threat situation.

In short: CVSS answers the question ‘How bad would it be?’, whilst EPSS answers the question ‘How likely is it?’. Only when both values are considered together do they provide a realistic picture.

CERT-Bund and the BSI classify vulnerabilities for Germany

The National Vulnerability Database (NVD) run by NIST is the central reference for CVE entries, CVSS scores and technical metadata. For organisations in Germany, there is an additional source: CERT-Bund, the BSI’s Computer Emergency Response Team, with its Warning and Information Service (WID). CERT-Bund assesses vulnerabilities in the German context and publishes warnings with recommendations for action. Organisations can subscribe to these specifically for the software they use.

Together, the NVD, EPSS and CERT-Bund provide three perspectives: technical severity, global likelihood of exploitation and an assessment specific to Germany.

A recent example: PHP2Shell

How these sources interact became apparent in October 2026. Two vulnerabilities in the PHP core, CVE-2026-109618 and CVE-2026-109619, allow code execution on web servers without authentication. Both are rated 9.2 under CVSS 4.0. Details had been leaked even before the scheduled patch release date, and on the day the updates were released, technical analyses of how to exploit the vulnerabilities were already circulating, as Huntress has documented. According to ingenieur.de that widespread exploitation was likely within a few hours.

The CVSS score alone would not have distinguished PHP2Shell from many other critical vulnerabilities. It was the exploitation indicators that made the difference. In the first few hours, these came from the BSI; shortly afterwards, EPSS clearly mapped them: On 27 October, the score for both CVEs stood at 0.99999 (FIRST.org EPSS API).

Risk-based vulnerability management starts with your own inventory

Even the best assessment is of little use if it is unclear where the affected software is running. A risk-based process can be described in four steps:

1. Recording: New CVEs are continuously received from NVD and CERT-Bund and are cross-referenced against the asset inventory. Only what is actually in use is relevant.

2. Assess: CVSS, EPSS and any CERT-Bund alerts are incorporated into a joint risk assessment. Added to this is the question of whether the system is accessible from the internet.

3. Prioritisation: A high CVSS score, a high EPSS score, an active alert and an exposed system mean: act immediately. A high CVSS score with a low EPSS score on an internal system can wait.

4. Action: Patches are applied and documented in this order. For systems for which no patch is available, a Plan B is required: hardening, isolation or replacement.

The result: the IT team first closes the vulnerabilities that are actually being exploited.

In the Managed SOC, prioritisation is largely automated

With several thousand new CVEs each year, it is virtually impossible to maintain this process consistently by hand. In suresecure’s Managed SOC, automated rules and use cases handle a large proportion of the detection, enrichment and prioritisation. Internally, we estimate a level of automation of around 85 per cent, based on approximately 1,000 pre-defined use cases that continuously cross-reference CVE, CVSS and EPSS data with the customer’s environments. The IT team no longer needs to compile data and can focus on the actual decision: which vulnerability should be patched first?

Vulnerability reporting is an integral part of Full-Managed SOCaaS and Co-Managed SOCaaS, both based on a SIEM/SOAR setup. Analysis is carried out from Germany, with hosting and processing carried out in compliance with the GDPR.

Important to note: A CIRT response following a successful attack is not automatically included in the Managed SOC. Active interventions are carried out only to the extent authorised in advance in the Statement of Work. In the event of an emergency, a separate IR retainer is provided.

Documented prioritisation also supports compliance evidence

Anyone who records why a particular vulnerability was patched and when has, at the same time, evidence for audits and inspections. The requirements vary depending on the regulatory framework:

• BSI’s IT-Grundschutz: requires structured vulnerability management as part of the ISMS.

• NIS2: applies to important and particularly important organisations and requires risk management, which includes the handling of vulnerabilities.

• KRITIS: applies to operators of critical infrastructure, who have their own obligations, some of which are sector-specific.

• DORA: applies to financial institutions and sets out specific requirements for ICT risk management.

Those who patch based on risk spend their time addressing the right vulnerabilities

No IT team can close every critical CVE immediately. Nor do they need to. The key is to close the right vulnerabilities first and to base this decision on data rather than on a single score. CVSS, EPSS and CERT-Bund provide this data; it is only by cross-referencing it with your own inventory that it becomes actionable.

PHP2Shell demonstrated just how little time there can be: there was barely more than a day between the leak and the first technical analyses of the exploit. At this pace, prioritisation only works if it is automated and there are clear rules governing who decides and who applies the patches.

FAQ