Impact data: richer, structured, and forward-looking
We have been working on a significant update to the impact section of the WPVulnerability API. This update introduces new structured data blocks, deprecates the legacy format, and adds two entirely new fields. Here is what changed and what to expect in the coming weeks.
For full field definitions, value mappings, and examples, see the updated Impact documentation.
New structured CVSS blocks: cvss2, cvss3, cvss4
The API now returns three new CVSS blocks inside the impact object, each tailored to its CVSS version:
cvss4— CVSS v4.0 data, including the new Attack Requirements (at) metric and the split between Vulnerable System (vc,vi,va) and Subsequent System (sc,si,sa) impact metrics.cvss3— CVSS v3.0 and v3.1 data, with theversionfield distinguishing between them. Includes exploitability and impact sub-scores when available from CVE/NVD.cvss2— CVSS v2.0 data, with its own metric structure: Authentication (au) instead of Privileges Required, and the classicnone/partial/completeimpact scale.
All three blocks use full human-readable values (e.g. "network", "low", "none") instead of the single-letter abbreviations used in the legacy block. Each block is null when no data exists for that version.
The legacy cvss block is now deprecated
The original cvss block remains in the API response for backward compatibility — its fields, types, and abbreviated values are frozen and will not change. However, it is now considered deprecated. All new structured data goes into the cvss2, cvss3, or cvss4 blocks.
If you are building new integrations, use the new version-specific blocks. If you have existing integrations using the legacy cvss block, they will continue to work, but we recommend migrating to the new blocks when convenient.
New field: EPSS
The impact object now includes an epss field — the Exploit Prediction Scoring System probability score. EPSS estimates the likelihood (0.0 to 1.0) that a vulnerability will be exploited in the wild within the next 30 days.
While CVSS tells you how severe a vulnerability is, EPSS tells you how likely it is to actually be exploited. Together, they provide a more complete picture for prioritization.
New field: KEV
We are also introducing a kev block — data from the CISA Known Exploited Vulnerabilities catalog. KEV is a curated list of CVEs with confirmed evidence of real-world exploitation, maintained by the U.S. Cybersecurity and Infrastructure Security Agency.
When a vulnerability’s CVE appears in the KEV catalog, the API returns the date it was added, the CISA remediation deadline, and whether it is known to be used in ransomware campaigns. This is a binary, high-confidence signal: if it is in KEV, someone is actively exploiting it.
Combined with CVSS and EPSS, KEV adds a third dimension to vulnerability assessment: severity (CVSS), probability (EPSS), and confirmed exploitation (KEV).
Work in progress
This is a rolling deployment. Data is already available for a significant portion of vulnerabilities, but coverage will continue to increase over the coming weeks as we process and integrate additional records from our sources.
Current coverage status:
- CVSS v3 data is the most complete, covering ~98% of WordPress-linked CVEs from NVD and ~71% of EUVD records.
- CVSS v2 data is available for ~24% of EUVD records.
- CVSS v4 data is available for ~5% of EUVD records (this will grow as more sources adopt CVSS 4.0).
- EPSS is available for ~83% of EUVD records.
- KEV data is available whenever a CVE appears in the CISA catalog.
We will keep expanding coverage silently — no breaking changes, just more data filling in.
Updated documentation
The Impact documentation page has been fully rewritten to reflect these changes. It now includes a Concepts section explaining CVSS, EPSS, KEV, and CWE, followed by detailed documentation for each CVSS version (newest first), EPSS, KEV, and CWE, with API examples and value mapping tables for every block.