EUVD and CVE 2026: Using Vulnerability Feeds Properly

The EUVD is operational - and ENISA is a CVE Root of its own

The European Vulnerability Database entered regular operation on 13 May 2025. Legally it rests on the NIS2 Directive, which tasks ENISA with building a European vulnerability registry. In substance the EUVD is an aggregator: it brings together data from open vulnerability databases, advisories and alerts issued by national CSIRTs, vendor guidance on patches and mitigations, and the Known Exploited Vulnerabilities catalog maintained by the US agency CISA (ENISA, EUVD press release).

A single entry typically contains a description of the vulnerability, the affected products, services and versions, a severity rating, and pointers to available patches or guidance from competent authorities (ENISA). The interface offers three dashboard views: for critical vulnerabilities, for exploited ones, and for EU coordinated cases (ENISA). That second view is where the real gain sits - more on that shortly.

The second change carries more structural weight: since November 2025 ENISA has been a CVE Root for European entities within its scope, including vulnerabilities discovered by or reported to EU CSIRTs (ENISA). As a Root, ENISA recruits, trains and supports CNAs, facilitates their transition, and is responsible for the assignment of CVE IDs and the publication of CVE Records within its scope (ENISA).

For SMEs the message is undramatic: no competing numbering system is emerging, but a second, European anchor point with its own curation. The EUVD does assign its own IDs in the format EUVD-YYYY-NNNNN, yet it carries the corresponding CVE IDs as aliases - so entries can be resolved in both directions.

Four feeds, four questions: EUVD, CVE Program, NVD and KEV

The most common mistake is assuming you have to pick one feed. In reality the four major sources answer different questions and complement one another.

The orders of magnitude show how closely the EUVD and the NVD sit together: 365,977 entries in the EUVD (ENISA, as of 15 July 2026) compare with 366,327 CVE entries in the NVD (NIST, as of 15 July 2026). So the EUVD is not an extract but a peer-level feed - with the difference that it additionally folds in CSIRT advisories and the exploited status. By 15 July 2026, 40,654 EUVD entries had been published (ENISA), after 49,703 across the whole of 2025 (ENISA) - roughly 207 new entries per day.

Why 'actively exploited' outweighs the CVSS score

The most widespread prioritisation rule goes: first everything at CVSS 9.0 and above, then the rest. It is intuitive and, in that form, misleading. A look at the EUVD figures makes this clear.

• 82,227 EUVD entries carry a CVSS base score between 7.0 and 10.0 - roughly 22 percent of the entire catalog (ENISA, EUVD, as of 15 July 2026). A work queue of that size is not prioritisation, it is capitulation.
• 17,659 entries sit at CVSS 9.0 to 10.0, the critical band (ENISA, EUVD, as of 15 July 2026). That is still nearly 5 percent of the catalog - far beyond what an SME team can process.
• 1,647 entries are flagged as actively exploited in the EUVD (ENISA, EUVD exploited filter, as of 15 July 2026). That is 0.45 percent of the catalog - an order of magnitude that is operationally workable.

The comparison between the two sets is what counts. Of the 17,659 critical entries, only 562 are also flagged as exploited (ENISA, EUVD, as of 15 July 2026) - that is 3.2 percent. Anyone working strictly down a CVSS 9.0 list spends the bulk of their time on vulnerabilities for which no evidence of exploitation exists.

The reverse check is even more revealing: 1,085 of the 1,647 entries flagged as exploited score below CVSS 9.0 - 66 percent (ENISA, EUVD, as of 15 July 2026). A pure CVSS sort therefore pushes two thirds of the demonstrably exploited vulnerabilities to the back of the queue. 200 of those entries carry a base score below 7.0 (ENISA, EUVD, as of 15 July 2026) and would be filed as 'medium' in many processes - although they are being attacked.

CVSS describes how bad a vulnerability would be if someone exploited it. The exploited status describes that someone is doing so. For deciding the order of work, the second statement is the more relevant one.

— Assessment based on EUVD data (ENISA, as of 15 July 2026)

This is not an argument against CVSS. The score remains useful for sorting within a group and for judging vulnerabilities without exploitation data - it is simply the wrong first filter. How closely the exploited views align is shown by the cross-check: the EUVD lists 1,647 exploited entries (ENISA, as of 15 July 2026), the KEV catalog 1,642 (CISA, catalog version 2026.07.14) - the EUVD feeds its exploited view from sources including the KEV catalog (ENISA).

The prioritisation rule: exploited, exposed, rest

The figures support a rule that works without a tool chain: three stages, processed in this order.

1. Known exploited - immediately. If an entry from the EUVD exploited filter or the KEV catalog hits a component in your inventory, that is the task of the day: patch it, and where no patch is available, apply the mitigation recommended by the vendor or CSIRT. Only a fraction of the 1,647 exploited entries (ENISA, as of 15 July 2026) touches a typical website stack.
2. Internet-exposed and critical - planned. Anything at CVSS 9.0 to 10.0 on a publicly reachable component goes into the next maintenance run. Exposure is the decisive additional criterion: a critical flaw in a library that only runs inside the internal build is less urgent than the same flaw in a publicly reachable CMS.
3. Everything else - in the cycle. The remainder moves into the regular patch rhythm; monthly is a workable cadence for most SME websites. What matters is not the frequency but that the cycle demonstrably happens and does not get dropped in the first stressful week.

This rule has an underrated side effect: it makes inaction justifiable. Documenting that an entry is neither flagged as exploited nor internet-exposed, and therefore runs in the cycle, is a traceable decision - towards clients, insurers or auditors considerably more robust than a list nobody was able to work through. How to evidence such decisions towards third parties is covered in the article on NIS2 requirements for supply chain and service providers.

Without an inventory, every feed is worthless

This is the real bottleneck. A feed makes statements about products and versions. Turning those into a task requires the other side: a maintained list of what actually runs on your own website. Without it, even the best feed is just a news ticker.

A simple probe shows how unspecific a feed stays without an inventory: a full-text search for 'wordpress' returns 18,901 hits in the EUVD, one for 'apache' 3,618 (ENISA, EUVD search, as of 15 July 2026). Without knowing which plugin runs in which version on your site, neither list is usable; with that information it shrinks to a handful of entries.

A usable website inventory covers four layers. They sound mundane, yet are rarely maintained in full.

The effort lies less in creating the inventory than in keeping it current. An inventory captured once in a spreadsheet and then left alone is worse than no inventory after a few months - it creates false confidence. The methodology is laid out in the article on the SBOM as a software bill of materials for websites.

Matching components against the feeds - the practical routine

Reconciling inventory and feed need not be complicated. For a manageable number of websites the following routine holds up without a tool chain of your own.

1. Capture the inventory. One list per website covering CMS, extensions, frontend libraries and server software, each with its version. The largest one-off effort - after that it is only upkeep.
2. Normalise the names. Feeds name vendors and products inconsistently. Decide once per component under which designation it is listed in the feeds, and note that spelling in the inventory. This step is often skipped and is the most frequent reason matches fail to materialise.
3. Query the exploited view first. With roughly 1,650 entries (ENISA and CISA, as of July 2026), the EUVD exploited filter and the KEV catalog are small enough to check in full against the inventory - the most important query of the week.
4. Check critical entries against exposed components. Then take the CVSS 9.0 to 10.0 view, restricted to components reachable from the internet.
5. Document the decision. One line per relevant hit: patched, mitigated or deliberately deferred - with a reason and a date. That line is your evidence later on.
6. Fix a cycle. In our experience a fixed date beats any ad-hoc reaction to headlines: weekly for the exploited view, monthly for the rest.

The hardest step is the second one. A plugin is named differently in the directory than in the CVE record, a vendor appears under two spellings, a library is listed under its project name rather than its package name. Capturing that mapping cleanly once turns the weekly reconciliation into a routine of minutes. Skipping it means searching from scratch on every pass.

CRA from 11 September 2026: better feeds, more pressure to act

From 11 September 2026 the reporting obligations under Article 14 of the Cyber Resilience Act apply (Regulation (EU) 2024/2847, Art. 14; European Commission, 'Cyber Resilience Act - Reporting obligations'). Manufacturers of products with digital elements must then report actively exploited vulnerabilities - in stages and to tight deadlines.

The Single Reporting Platform is scheduled to be operational on the same date - the central entry point through which manufacturers report once instead of addressing each national authority separately (ENISA, Single Reporting Platform). The receiving CSIRT then distributes the notification to the other competent CSIRTs (European Commission, Art. 14 CRA).

For website operators who are not manufacturers within the meaning of the CRA, no reporting obligation of their own follows - but a tangible effect does: if manufacturers must report actively exploited vulnerabilities to deadlines from September 2026, more solid exploitation information will flow into the feeds, and it will flow earlier. ENISA, as the recipient of these reports, also operates the EUVD - the exploited filter can therefore be expected to gain in significance.

It is also worth looking at the inbound channel: providing a contact point for vulnerability reports via security.txt under RFC 9116 can surface problems before they appear in any feed. The reporting duties for operators of essential and important entities are laid out in the article on NIS2 incident reporting for website operators.

Naming the limits of the feeds honestly

A realistic view of feeds is part of due care. There are three constraints you should know before building a process on top of them.

• The exploited status lags reality. A vulnerability is exploited before anyone evidences and reports that exploitation. The 1,647 flagged entries (ENISA, as of 15 July 2026) are what is documented - not what is happening.
• Coverage is uneven across components. Widely used systems with active security research are well represented. A rarely used plugin or an in-house extension seldom produces a CVE entry - there, absence from the feed says very little.
• Feeds do not replace vendor advisories. The EUVD consolidates vendor guidance (ENISA), but the fastest information about a component still comes from the project or supplier itself. For the core components of your stack, subscribing directly is worthwhile.

Frequently overlooked is the difference between a vulnerability in your software and one in what your page loads in the browser. A modified third-party script has no CVE ID and appears in no feed - that requires monitoring the integrity of embedded scripts via Subresource Integrity. Related is how revocation information for certificates is distributed going forward; the article on the end of OCSP and the return to CRL puts that shift into context.

Bringing vulnerability feeds into daily operations

The feed landscape of 2026 is better than it has ever been: the EUVD provides a European-anchored, aggregated source with an explicit exploited filter, ENISA is structurally embedded as a CVE Root, and from 11 September 2026 mandatory manufacturer reports will feed in additional exploitation information (European Commission, Art. 14 CRA). Vulnerability management no longer fails on the availability of information - it fails on the link between feed and your own estate. As long as nobody knows which CMS version, which plugins and which JavaScript libraries run on a website, every EUVD entry remains an abstract notice about somebody else's software.

That is exactly where the CRA component cockpit from XICTRAQ comes in. It records the tech stack per website, detects outdated components based on the captured version state, and escalates approaching CRA deadlines in good time through the configured alerting channels. The obligation to be able to say at any moment what runs on your own website turns into a recurring workflow instead of a spreadsheet nobody maintains. In addition, the security scan checks the attack surface in a real browser, and the NIS2 readiness features map the reporting and deadline logic. The live demo shows the interplay; the plan allocation is set out in the pricing overview.

Getting started in practice needs no grand initiative. Capture the inventory of a single website, check it against the EUVD exploited filter, document the result. You will very likely find that the task list is short - and that you can justify it for the first time. That is more than most vulnerability processes deliver.