WordPress plugin vulnerability classification system

Short answer: WordPress plugin vulnerabilities are tracked in two parallel systems. CVE (with NVD and MITRE) is the universal cross-platform identifier, and the WordPress-specific databases – Wordfence Intelligence, Patchstack, and WPScan – add WordPress-specific cataloguing on top. Severity is rated using CVSS (Common Vulnerability Scoring System), a 0.0 to 10.0 numeric score that maps to four severity bands: critical (9.0+), high (7.0-8.9), medium (4.0-6.9), and low (0.1-3.9). “Critical” usually means unauthenticated remote code execution or arbitrary file upload. “High” usually means privilege escalation or authenticated SQL injection. “Medium” covers most XSS and weaker access control issues. The score is a starting point, not the whole story – context determines whether a “medium” actually matters to your site.

Every week, security databases publish 200 to 300 new vulnerability disclosures against WordPress plugins and themes. Most site owners never look at the disclosures directly – they see “your plugin has a vulnerability” in a security plugin’s dashboard, see a severity label like “high,” and either click update or do nothing. The classification system behind those labels is consistent, and once you understand what each rating actually means, you make better decisions about which updates need to happen this hour and which can wait for the next maintenance window.

This article walks through the four databases that catalogue WordPress vulnerabilities, the CVSS scoring system that produces the severity numbers, the CVE numbering scheme that gives each vulnerability a permanent identifier, what each severity tier means in practice, and how Hostney’s WordPress installations handle this end-to-end.

The four databases you will see referenced#

A WordPress plugin vulnerability typically gets catalogued in multiple databases. They are not competing – they describe the same vulnerability with different metadata and different audiences in mind.

Database	Operated by	Focus	Free tier	Paid tier
NVD (CVE)	NIST (US government)	Cross-platform CVE registry	Free, public	n/a
Wordfence Intelligence	Wordfence	WordPress-specific, full feed	Free, public	Premium $119/yr for plugin
Patchstack	Patchstack Sweden	WordPress-specific, with virtual patches	Free database access	Patchstack subscription
WPScan	Automattic (acquired)	WordPress-specific, CLI + API	API requires key, limited free	Paid plans for higher rate limits

NVD and the CVE system#

NVD – the National Vulnerability Database – is run by NIST. It is the master registry of CVE identifiers (Common Vulnerabilities and Exposures), which are the unique identifiers you see formatted as CVE-2026-12345 . Every WordPress plugin vulnerability with a CVE has an NVD record. NVD provides the standardised CVSS score, a description, references to upstream advisories, and the affected version range.

NVD is the source of truth for the CVE identifier itself, but it is slow. A vulnerability may be disclosed and exploited for weeks before it appears in NVD with a full score. WordPress-specific databases get there faster because they monitor the WordPress ecosystem directly.

Wordfence Intelligence#

Wordfence maintains its own vulnerability database that focuses on WordPress core, plugins, and themes. They publish a free API feed (the same data their plugin uses for premium customers) with ~12,000+ records and updates daily. Each record includes the CVSS score, severity tier, affected versions, patched version, CVE ID (if assigned), CWE classification, and a Wordfence-specific description.

Wordfence’s threat intelligence team often discovers and reports vulnerabilities themselves, so their database typically has new disclosures before they appear in NVD. Their CVSS scores are usually consistent with NVD’s once NVD catches up.

Patchstack#

Patchstack is a Sweden-based WordPress security company that runs both a vulnerability database and a “virtual patch” service. Their database is freely browsable, and they publish a public CVE feed. The differentiator is the virtual-patch product: Patchstack writes WAF rules that block exploit attempts at the request level, which can protect a vulnerable site even before the plugin itself is updated. The classification metadata is similar to Wordfence’s.

WPScan#

WPScan was acquired by Automattic in 2021 and is the database that powers the WPScan command-line tool. It is commonly used by penetration testers and security researchers because the CLI tool can enumerate a WordPress site’s plugins and check each one against the database. Free API access is rate-limited; higher rate limits require a paid plan.

WPScan tends to focus on technical detail (proof-of-concept payloads, exploit references) more than the other databases, which makes it useful for verifying whether a vulnerability is actually exploitable in your specific configuration.

The databases overlap heavily. A single plugin vulnerability typically has records in three or four of them, sometimes with slightly different scores or severity assignments because each database’s analysts may weight the attack vector differently. That is normal and not a sign anyone is wrong.

CVSS scoring: what the numbers actually mean#

CVSS – Common Vulnerability Scoring System – is the industry-standard severity rating. The current version is CVSS 3.1 (the FIRST organisation, which maintains it, has CVSS 4.0 in adoption but most WordPress databases still publish 3.1 scores). The score is a 0.0 to 10.0 decimal, and it maps to four severity tiers:

Score range	Severity	Typical examples
9.0 – 10.0	Critical	Unauthenticated RCE, arbitrary file upload, authentication bypass
7.0 – 8.9	High	Authenticated RCE, privilege escalation, SQL injection (authenticated)
4.0 – 6.9	Medium	Stored XSS, CSRF, broken access control on non-critical endpoints
0.1 – 3.9	Low	Reflected XSS with limited impact, information disclosure
0.0	None	Theoretical issue with no practical impact

The score is calculated from several base metrics, not assigned arbitrarily. The metrics that matter most for WordPress plugins:

• Attack vector: network (anyone on the internet can attempt it), adjacent (same network only), local (requires shell access), physical. Most WordPress plugin vulns are network.
• Attack complexity: low (works against any vulnerable site without preparation) or high (requires specific conditions). Most plugin vulns are low complexity.
• Privileges required: none (unauthenticated), low (subscriber/contributor), or high (admin). This is the single biggest swing in the final score. An unauthenticated RCE is critical; the same flaw requiring admin access is medium at most because an admin can already do anything.
• User interaction: none (purely server-side) or required (needs a user to click something).
• Scope: changed (the vulnerability lets the attacker escape the plugin’s normal boundaries, e.g. write to files outside the plugin’s directory) or unchanged.
• Confidentiality / integrity / availability impact: none, low, or high.

A vulnerability that scores 9.8 (critical) on CVSS is typically network / low complexity / no privileges required / no user interaction / changed scope / high impact on all three of confidentiality, integrity, and availability. That profile describes unauthenticated remote code execution, which is the worst-case WordPress plugin scenario.

A vulnerability that scores 5.4 (medium) might be the same code path but with “privileges required: low” (subscriber-level access needed). The lower privilege requirement drops the score below the high threshold because in practice most WordPress sites do not have arbitrary subscriber accounts, and the attacker has to get a subscriber session first.

Where CVSS scores can mislead you#

The CVSS score is a useful starting point, not a final answer. A few cases where the score does not reflect real risk:

• A medium-rated CSRF on the admin user role. CVSS may rate it medium because privileges-required is none and user-interaction is required, but if your site has admins who occasionally browse the web, the practical risk is closer to high.
• A critical-rated unauthenticated RCE in a plugin you never use a public endpoint of. The CVSS rating assumes the vulnerable endpoint is reachable. If the plugin is installed but its frontend is locked behind authentication or behind an IP allowlist, the practical risk is lower.
• A high-rated authenticated SQL injection where the required privilege is a role you never grant. If only Contributors can trigger it and you do not let anyone register, the risk is low even though the CVSS is 7.5.

The right discipline is to read the description, look at the privileges-required field, and ask “does this match my site’s configuration?” The CVSS score gets you 80% of the way; the last 20% is context.

CVE numbering: how identifiers work#

CVE identifiers follow the format CVE-YYYY-NNNNN . The year is the year the CVE ID was assigned (not necessarily the year the vulnerability was discovered or disclosed). The numeric suffix is sequential within the year and has no built-in meaning – CVE-2026-99999 does not imply it is more or less severe than CVE-2026-00001 . Both are just identifiers.

CVE IDs are assigned by CNAs (CVE Numbering Authorities). Wordfence, Patchstack, and Automattic are all CNAs for WordPress vulnerabilities, which means they can assign CVE IDs directly without going through MITRE. This is why a vulnerability often gets a CVE ID within days of disclosure now – it used to take weeks when only MITRE could assign them.

When you see a vulnerability referenced multiple ways – CVE-2026-12345 , WPVDB-2026-1234 (WPScan’s internal ID), WORDFENCE-2026-1234 (Wordfence’s internal ID), PATCHSTACK-2026-1234 (Patchstack’s internal ID) – they are all pointers to the same underlying flaw. The CVE ID is the universal one.

CWE classification: what type of vulnerability is it#

Each vulnerability is also tagged with a CWE (Common Weakness Enumeration) ID that describes the type of flaw. The CWEs you will see most often on WordPress plugins:

CWE	Name	What it is
CWE-79	Cross-site Scripting (XSS)	Plugin output includes user input without sanitisation – attacker injects JavaScript
CWE-89	SQL Injection	Plugin builds a SQL query with user input without parameterisation
CWE-434	Unrestricted File Upload	Plugin lets users upload files without validating the extension
CWE-862	Missing Authorisation	Plugin endpoint does not check capability before executing
CWE-352	Cross-Site Request Forgery (CSRF)	Plugin action can be triggered by a forged cross-origin request
CWE-22	Path Traversal	Plugin reads/writes a file path constructed from user input without normalisation
CWE-502	Deserialization of Untrusted Data	Plugin unserializes user-controlled data, allowing PHP object injection
CWE-918	Server-Side Request Forgery (SSRF)	Plugin makes an outbound request to a URL controlled by the attacker

XSS (CWE-79) is by far the most common in WordPress plugin disclosures, accounting for roughly half of all entries. The dominance reflects how easy XSS is to introduce (any plugin that echoes user input without escaping it has the bug) and how thoroughly auditors look for it. The high-impact bugs are CWE-434 (file upload) and CWE-502 (deserialisation) because both lead to remote code execution.

The bigger picture on why this happens – the structural reasons the WordPress plugin ecosystem produces a steady stream of vulnerabilities – is a separate article. This one is about how the ones that exist get classified.

What critical / high / medium / low mean in practice#

Translating the score tiers into operational reality:

Critical (9.0-10.0)#

Drop everything and patch. Critical-rated WordPress plugin vulnerabilities are almost always unauthenticated remote code execution, arbitrary file upload, or authentication bypass. Scanners weaponise these within hours of disclosure. The window between “vulnerability disclosed” and “scanners are testing it on the internet” can be under 24 hours for a popular plugin.

If you have a critical vuln on an installed plugin and a patched version exists, update immediately. If no patch exists yet, either disable the plugin or apply a virtual patch (a WAF rule that blocks the specific exploit pattern). Patchstack publishes virtual patches for many critical disclosures within hours.

Examples that have hit recently: arbitrary file upload in a forms plugin (CVE-2024-XXXXX class), authentication bypass in a membership plugin, unauthenticated RCE in a backup plugin. Single critical vuln on a popular plugin produces millions of compromised sites within weeks.

High (7.0-8.9)#

Patch within a week, ideally sooner. High-rated vulnerabilities usually require some level of authentication (subscriber, contributor, or higher) and lead to RCE, SQL injection, or privilege escalation. The “requires authentication” filter knocks them out of the critical tier because the attacker has to acquire an account first, but for any WordPress site that allows public registration, the gap is often only minutes.

Authenticated SQL injection at subscriber level on a site with registration open is operationally indistinguishable from unauthenticated SQL injection. Take the privileges-required field seriously and ask whether your site actually enforces that gate.

Medium (4.0-6.9)#

Patch within a normal maintenance window (one to four weeks depending on your release cadence). Medium covers most stored XSS, most CSRF, broken access control on non-critical endpoints, and information disclosure of moderate sensitivity. Not catastrophic on their own, but stored XSS on an admin-facing endpoint can be chained with other issues to escalate privileges, and CSRF on a sensitive admin action can be triggered against a logged-in admin.

The case for treating medium as “soon” rather than “eventually”: stored XSS on a comment field, an editor on the team, the editor visits a different tab and the JavaScript runs in their authenticated session. Now the attacker has session-level access to whatever the editor can do.

Low (0.1-3.9)#

Patch in normal maintenance. Low usually means reflected XSS with limited impact, information disclosure of non-sensitive data (e.g. plugin version numbers), or theoretical issues that require specific configurations to exploit. Still worth patching – low-rated bugs are sometimes used as part of an exploit chain – but not urgent.

Time-to-patch expectations by severity#

Severity	Disclosed-to-attack time	Recommended patch window
Critical	Hours to 1 day	Within 24 hours
High	1-7 days	Within 7 days
Medium	Weeks	Within 30 days
Low	Months (if at all)	Next maintenance cycle

These are realistic numbers for a popular plugin. A vulnerability in a plugin with 50 active installs and zero scanner attention may sit unpatched for years and never be exploited. A vulnerability in a plugin with 5 million installs gets weaponised before the disclosure email finishes propagating.

How to read a Wordfence Intelligence record#

Every database has its own UI, but Wordfence Intelligence is the one Hostney’s panel uses, so it is worth knowing what each field tells you:

• Title: human description of the bug, e.g. “Contact Form Plugin <= 4.2.1 - Authenticated (Subscriber+) Stored Cross-Site Scripting"
• Software type: core / plugin / theme
• Software slug: machine identifier, e.g. contact-form-7
• CVE ID: the universal identifier, e.g. CVE-2026-12345
• CVSS score: numeric 0.0-10.0
• Severity: critical / high / medium / low band
• CWE: weakness type, e.g. CWE-79
• Vulnerable versions: range of versions affected, e.g. <= 4.2.1
• Patched version: the first version that fixes it, e.g. 4.2.2
• Researcher credit: who found and reported it
• Description: what the bug is, where it lives, what an attacker can do

The two fields that matter for triage are CVSS score (how bad) and patched version (whether a fix exists). If the patched version field is blank, no patch exists yet and the only mitigations are deactivating the plugin or applying a virtual patch.

Reading the database itself#

For anyone curious to look at the raw data:

• Wordfence Intelligence feed: https://www.wordfence.com/api/intelligence/v3/vulnerabilities/production (requires free API key)
• Patchstack public database: https://patchstack.com/database/
• WPScan vulnerability database: https://wpscan.com/wordpresses/ (also accessible via the WPScan CLI tool)
• NVD search: https://nvd.nist.gov/vuln/search (search by keyword “wordpress” or by CPE for a specific plugin)

If you maintain your own plugin inventory and want to programmatically check it against the disclosures, all four publish APIs. Wordfence Intelligence is the most generous on the free tier; WPScan is the most rate-limited but is the easiest to use from a shell script.

How Hostney handles classification end to end#

Hostney’s WordPress installations integrate with the Wordfence Intelligence feed and surface CVE matches per installation. The flow:

1. Daily ingestion: the current Wordfence Intelligence vulnerability database is pulled in and synced overnight, then matched against installed plugin / theme / core versions on every WordPress installation under the account.
2. Per-install matching: each match is stored with the full CVSS score, severity band, CVE ID, CWE, and patched version. The Vulnerabilities page in the control panel lists every active match across the account.
3. Severity-aware display: each row shows the severity badge (critical / high / medium / low) and the patched-version status (green check if a patch is available, exclamation if no patch exists yet).
4. Auto-update by default: every installation has auto-updates enabled by default for core (minor and major), plugins, and themes. When a patched version reaches the WordPress.org repository, the update is picked up automatically and applied after a short delay (default: 1 day for minor core releases, 5 days for major core, 2 days for plugins and themes). Delays are configurable per installation.
5. Manual override: the Vulnerabilities page has an “Update now” button that bypasses the delay window for a specific install / specific update. Used when the disclosure is critical and you do not want to wait the default 2 days.
6. Pre-update snapshots: before applying a core update, the system snapshots the database so an update that breaks the site can be rolled back without restoring from a customer backup.
7. Auto-clearing matches: once the auto-update applies the patched version, the match row clears automatically on the next sync because the installed version is no longer in the vulnerable range.

The result: a vulnerability in a popular plugin with an available patch will typically be applied to a Hostney-hosted site within 2 days of disclosure with zero customer action, and within minutes if the customer uses the manual override on the Vulnerabilities page.

Two limits worth being explicit about. First, there is no severity-based override – a critical CVE follows the same 2-day plugin delay window as a low-severity disclosure unless the customer manually overrides it. The reasoning is that auto-applying every disclosed update without delay would occasionally break sites when an upstream patch introduces a regression. Second, when no upstream patch exists (zero-day or abandoned plugin), the system flags the vulnerability but cannot patch it. The customer’s options in that case are deactivating the plugin or relying on server-level ModSecurity rules to block the exploit pattern, which Hostney runs by default on every WordPress site.

For broader context: is WordPress safe and secure covers the wider picture of where breaches actually come from; why WordPress plugin vulnerabilities are out of control explains why the disclosure rate is what it is; and the relationship between Wordfence and server-level security covers what plugin-layer scanners catch that server-layer rules miss and vice versa.

Quick reference#

• CVE is the universal vulnerability identifier ( CVE-YYYY-NNNNN ). Wordfence, Patchstack, WPScan are WordPress-specific catalogues that reference the same CVEs with extra detail.
• CVSS is the 0.0-10.0 severity score. Critical 9.0+, high 7.0-8.9, medium 4.0-6.9, low 0.1-3.9.
• CWE describes the type of flaw (XSS, SQL injection, file upload, etc.).
• “Critical” usually means unauthenticated RCE or file upload. “High” usually means authenticated RCE, privilege escalation, or SQL injection.
• The CVSS score is a starting point – the “privileges required” field is the most important context check.
• A vulnerability is only urgent if your site actually exposes the vulnerable endpoint in a way the disclosure assumes.
• Time-to-patch targets: critical within 24 hours, high within a week, medium within a month, low within normal maintenance.
• Hostney auto-updates plugins, themes, and core by default with configurable per-install delays; a one-click override on the Vulnerabilities page bypasses the delay for urgent disclosures.