ENISA EU Vulnerability Database (EUVD)

https://euvd.enisa.europa.eu/

EU vulnerability database mandated by NIS2 Art. 12(2), operated by ENISA, the EU counterpart to CISA KEV for exploitation ground truth, plus CVSS/EPSS-enriched coverage of newly published vulnerabilities. Records carry EUVD-YYYY-NNNNN ids aliased to CVE/GHSA ids, references to vendor advisories, `baseScore`/`epss`, and (on the exploited listing) `exploitedSince` (EU-side actively-exploited signal to read NEXT TO cisa-kev every run; the two catalogs overlap but neither is a superset). tier: essential; attempted on EVERY intel run, and the check means ALL THREE listing endpoints, not just one: (1) newest records → `python3 tools/fetch_source.py enisa-euvd recent lastvulnerabilities` (≙ https://euvd.enisa.europa.eu/); (2) critical CVSS 9.0–10.0 → `python3 tools/fetch_source.py enisa-euvd recent criticals` (≙ https://euvd.enisa.europa.eu/search?fromScore=9&toScore=10); (3) actively exploited → `python3 tools/fetch_source.py enisa-euvd recent exploited` (≙ https://euvd.enisa.europa.eu/search?exploited=true). Drill one record with `enisa-euvd advisory <EUVD-id>`. REQUIRED FETCH METHOD: the bridge api subcommands only, the SPA at euvd.enisa.europa.eu returns an empty <noscript> shell to WebFetch (not a fetch failure; recipe transition per the agent definition). The JSON API lives on the separate services host euvdservices.enisa.europa.eu (bridge re-pointed 2026-05-11). Citation discipline: the API JSON is the data, never the citation, cite the vendor advisory / CERT primary the record references (CVE primary-source order puts EUVD below vendor/CERT but above researcher write-ups); where the EUVD entry itself is the source, cite the human detail page https://euvd.enisa.europa.eu/enisa/eu_vulnerability_database/<EUVD-id>, never the search/listing URL. | 2026-07-09 added as tier: essential on operator request (EUVD ground truth next to CISA KEV): all three listing endpoints verified live and current same day, lastvulnerabilities, criticals, and exploited each returned in-window JSON (exploited carries exploitedSince; e.g. EUVD-2026-40121 / CVE-2026-56290 exploitedSince Jul 7). | 2026-07-18 weekly audit: 'attempted' must mean a DISCOVERY SWEEP of the recent/criticals/exploited listings, not only per-CVE enrichment lookups. The 2026-07-18 intel fire used EUVD solely for CVE checks and missed WordPress WP2Shell (EUVD-2026-45280/45236, published 07-17, recovered by the audit) that the listings carried. S1 must walk the listing endpoints every run. | 2026-08-19: exploited and criticals listings plus two per-advisory lookups; supplied the structured affected/fixed build ranges behind two entries and independently corroborated both exploitation dates. | 2026-09-29: health-check flag was a false positive (check read the SPA front page of an api record, 377-alnum noscript shell); the documented recipe `enisa-euvd recent {lastvulnerabilities|criticals|exploited}` returns live same-day JSON (5.9/4.0/5.9 KB) and is now the content-check command (health_cmd). (2026-09-29T2134Z-audit) | 2026-10-02 (2026-10-02T0404Z-intel): `enisa-euvd recent {exploited|criticals|lastvulnerabilities}` returns only 4 items per list, so it is a spot check, not a sweep; it surfaced the two Zammad CVEs (exploitedSince 2026-09-30) and FortiMail. | 2026-10-03 S1: `recent` is a 4-item spot check; a real sweep is `python3 tools/fetch_source.py url --direct "https://euvdservices.enisa.europa.eu/api/search?fromDate=YYYY-MM-DD&toDate=YYYY-MM-DD&fromScore=8.5&toScore=10&page=0&size=100"` (items with aliases, vendor/product, epss, exploitedSince; page=1 for the rest). (2026-10-03T0404Z-intel) | 2026-10-04: `url --direct "https://euvdservices.enisa.europa.eu/api/search?exploited=true&fromDate=YYYY-MM-DD&toDate=YYYY-MM-DD&page=0&size=100"` returns the full exploited list where `recent exploited` returns about 4. The API epss field is a percent, not a probability; use api.first.org for the probability. Cite the human URL form euvd.enisa.europa.eu/enisa/EUVD-..., never the API.