Know if a WordPress CVE applies to your site

A vulnerability database is useful when it helps you decide what to patch today. Records usually include a CVE id, affected versions, and whether a fix shipped. This hub is how to read those fields for the sites you actually run.

If you landed here with a version string (6.7.1, 6.9.x, WordPress 7), treat the number as a lookup, not a panic button.

Looking up a core version

Confirm the installed version in wp-admin under Updates, or with WP-CLI (wp core version). Then open the matching WordPress core security release on wordpress.org/news and read the affected range, not only the headline.

A patched later release in that line is not vulnerable to a bug fixed earlier. Partial updates happen after failed FTP uploads, so compare files if wp-admin and the filesystem disagree.

Run the vulnerability scanner anyway. Core CVE headlines often distract from the plugin that is actually exploitable on your stack. For recent high-impact core issues, see the wp2shell hub for post-update checks.

Plugin advisory patterns

Most day-to-day WordPress vulnerability work is plugin and theme advisories, not core drama.

When Patchstack, Wordfence, or a vendor publishes a mass advisory, run the scanner first, then read the advisory for version ranges. Marketing tweets rarely include the range you need.

Cross-check: vendor changelog, CVE/NVD when present, scanner output, and filesystem version (wp plugin list or the plugin header in wp-content/plugins/).

Common types in WordPress context

Related: XSS guide, security issues, plugin risks. Absolute “X% of all vulnerabilities are XSS” marketing stats go stale quickly. Use the type labels to understand impact, not as eternal percentages.

CVSS cheat sheet

CVSS scores run from 0.0 to 10.0. A common reading of CVSS v3.x bands:

Also read the vector, not only the number: privileges required, user interaction, attack complexity, whether a public exploit exists, and whether the issue stays inside one component or affects the whole site.

A medium unauthenticated issue on a popular plugin can outrank a high bug that only affects a rare admin-only screen you do not use.

How to read a WordPress CVE record

When you open a CVE or ecosystem advisory, look for these fields first:

• Component: which plugin, theme, or core package
• Affected versions: inclusive ranges, not just “old”
• CVE / advisory ID: so you can cross-check NVD, the vendor, and your scanner
• Severity / impact: what an attacker can do
• Fix: patched version, or “no fix; remove”
• Prerequisites: does the attacker need an account, or is it unauthenticated?

If a write-up skips versions or a fix path, treat it as incomplete until you confirm against the vendor advisory or a trusted tracker.

Where to verify

Cross-check important hits against at least two of:

1. Vendor / plugin author advisory or changelog
2. A CVE tracker such as NVD when a CVE id exists
3. Your scanner’s finding details (component + version)
4. Reputable WordPress ecosystem vulnerability databases used by researchers and tools

Treat absolute “we track N vulnerabilities” claims with skepticism unless you can see methodology. Counts change daily and marketing pages inflate them.

Turn a hit into a short report

For each finding on a site you manage, write down:

1. Site name and environment (production vs staging)
2. Component and installed version
3. Advisory or CVE id
4. Confirmed in affected range? Yes / no
5. Exposed to the internet? Auth required?
6. Action: update / replace / remove / accept temporary risk
7. Done date and who owns the follow-up

That beats a screenshot of a red badge. It also keeps client work honest when several sites share the same abandoned plugin.

Patch sooner when more of these are true: unauthenticated or low-privilege path, RCE / SQLi / auth bypass, plugin still on disk, high-traffic or payment site, public exploit already out. You can wait a short, scheduled window when the issue needs a rare admin role, has no known exploit, and a tested update is hours away on staging. Wait forever is not a strategy.

Worked example

Scanner reports Plugin X 3.2.0 is vulnerable to unauthenticated SQLi; fixed in 3.2.1.

1. Confirm Plugin X 3.2.0 is on the site, including if it is deactivated
2. Read the advisory: affected range, fix version, prerequisites
3. Update to 3.2.1 on staging, then production; or remove if unused
4. Apply the update; delete the plugin if you are replacing it
5. Re-scan vulnerabilities and run a malware / core check if the window was long enough for abuse
6. Review users, admin emails, and scheduled tasks for surprises
7. Harden the path that made exploitation likely: logins, firewall, backups

If the advisory says “no fix,” remove the component.

Why plugins dominate

WordPress core is maintained by a large project and ships security releases on a predictable cadence. Most public WordPress ecosystem vulnerabilities show up in third-party plugins and themes because that is where most custom code and attack surface live.

Themes matter too, especially page builders and “null” theme packs. Core is rarely the first place opportunistic attackers look when an old plugin sits unpatched.

Related reading

• Vulnerability scanner
• WordPress security scanner comparison
• WordPress plugin security risks
• WordPress security checklist
• Best WordPress security plugins
• Deeper background on WordPress security vulnerabilities