The 8 CVE Sources Behind a Modern WordPress Vulnerability Database

Why One CVE Source Is Never Enough

Every WordPress security scanner is ultimately only as accurate as the vulnerability data it consults. A scanner that checks your plugins against a single database will miss any CVE that was published to a different registry, assigned a different identifier, or documented under a package ecosystem the database does not track. In practice, that means real vulnerabilities going undetected not because the scanner lacks the technical capability to find them, but because the underlying dataset has a gap.

The WordPress ecosystem is unusual in that vulnerability records are distributed across multiple overlapping sources with different licensing models, different publishing cadences, and different levels of detail. A mature scanner needs to aggregate from several of these sources simultaneously, deduplicate the resulting records, and resolve conflicts when the same vulnerability is described differently across different registries.

Understanding which sources exist (and what each one uniquely contributes) gives you a framework for evaluating any scanner's data quality claims.

NVD and Mitre: The US Government Foundations

The National Vulnerability Database, maintained by NIST, is the most widely cited CVE repository in the world. Records are published under a CC0 public-domain licence, carry standardised CVSS severity scores, and serve as the authoritative source for CVE identifiers assigned through the US government's CVE Numbering Authority program.

Mitre's CVE List V5 is the canonical source for the CVE identifiers themselves, the CVE-YYYY-NNNNN format that security advisories reference universally. While NVD adds scoring and enrichment to these records, the Mitre list is the root from which all downstream databases derive their identifiers.

Together, these two sources form the foundation of any credible vulnerability database. Their limitation for WordPress-specific coverage is their generality: a plugin CVE may be published to NVD weeks after it has already been documented in WordPress-specific sources, and the NVD record may lack the plugin slug or version range needed to match it against an installed plugin list automatically.

GHSA and OSV.dev: The Open-Source Ecosystems

GitHub Security Advisories is a significant shift in how vulnerability data is published for open-source packages. GHSA records are published under CC0, structured as machine-readable JSON, and linked directly to the affected package in whichever ecosystem it belongs to, Packagist for PHP, npm for JavaScript, and so on. For WordPress plugins distributed through Packagist, GHSA coverage is often faster and more structured than NVD.

OSV.dev, the Open Source Vulnerabilities project, aggregates vulnerability data across multiple ecosystems including Packagist and WP-specific advisories, publishing under a CC-BY-4.0 licence. Its strength is breadth: it pulls from GHSA, NVD, and several community-maintained databases, and publishes in a consistent schema that makes programmatic consumption straightforward.

Between them, GHSA and OSV.dev provide coverage that is particularly strong for the PHP ecosystem, which is exactly where WordPress's plugin vulnerabilities live.

Wordfence Intelligence and WPVulnerability.com: WordPress-Specific Layers

The two databases that are purpose-built for WordPress each bring coverage that generic ecosystems miss. Wordfence Intelligence v3 is a proprietary database built by a company that analyses millions of WordPress sites and has direct relationships with plugin authors. Its partial-free tier provides CVE records that include WordPress-specific metadata: affected plugin slugs, patched version numbers, and exploit type classifications that map directly onto scanner logic.

WPVulnerability.com operates as a community-maintained database under a CC-BY-SA licence. It captures vulnerabilities that may not yet have a formal CVE assignment, documents findings reported through responsible-disclosure channels, and includes detailed write-ups that go beyond the brief descriptions in NVD records.

These two WordPress-specific sources are often ahead of the general databases by days or weeks on newly discovered plugin vulnerabilities, which is precisely the window when exploitation risk is highest.

CIRCL, Patchstack, and EPSS: EU, Vendor, and Scoring Context

CIRCL (the Computer Incident Response Center Luxembourg) operates a European public CVE search service that provides an independent mirror of CVE data with additional enrichment. Its utility for a WordPress scanner is primarily as a redundancy layer and a source of European threat-intelligence context that may differ from US-centric databases.

Patchstack previously operated a public RSS feed for WordPress vulnerability disclosures. While Patchstack has since moved to a commercial model, their historical feed data remains valuable as a fail-soft fallback for records published during the period it was active.

EPSS (the Exploit Prediction Scoring System, maintained by FIRST.org) is not a CVE database in the traditional sense but deserves mention alongside the data sources because it transforms the vulnerability record from a static severity score into a dynamic exploitation-likelihood estimate. When a scanner cross-references a CVE against EPSS, it can tell you not just how severe a vulnerability is but how likely it is to be exploited in the next thirty days based on real-world threat intelligence signals.

How Nightly Aggregation and Deduplication Works

Pulling from eight sources creates an immediate problem: the same vulnerability may appear under different CVE identifiers, different CVSS scores, or slightly different package slug formats across different databases. A scanner that naively concatenates all eight source lists will present duplicate findings to users, inflate finding counts, and create confusion about which record to trust.

The solution is a nightly aggregation pipeline that merges records by a composite key (typically the combination of vulnerability type, affected plugin slug, and CVE identifier) and then applies a deterministic rule for resolving conflicts. When two sources assign different CVSS scores to the same vulnerability, a common approach is to retain the highest score, which errs toward caution. The merged, deduplicated result is then published as a unified feed that the scanner pulls in a single round-trip.

For the full breakdown of how CVE sources are merged and deduplicated, WPSecScan's feature documentation covers the exact pipeline logic, conflict resolution rules, and the published data schema.

What to Ask a Scanner Vendor About Their Data Pipeline

Armed with this understanding of the available sources, the questions to ask any scanner vendor become concrete. Which of the eight major sources do they include? How frequently is the aggregated feed updated? Nightly automation is meaningfully different from weekly manual updates. Do they deduplicate across sources, or do duplicate records appear in reports? How quickly does a newly published WordPress plugin CVE appear in their feed relative to its publication in the source database?

A vendor that cannot answer these questions with specifics is likely relying on a single source or a manually curated database with no published update cadence. For WordPress security, where the list of plugin CVEs changes daily, that is a meaningful coverage gap.