WPDeeply
Download free plugin

Methodology

How WPDeeply sources vulnerability data, matches versions and calculates risk.

Input 01

Exploitability

Can an unauthenticated visitor trigger it, or does it need an account with capabilities? Unauthenticated always outranks authenticated.

Input 02

Reachability

Is the component active on the site being scanned? An inactive plugin still needs patching, but it does not get ranked as urgent.

Input 03

Remediability

Does a patched version exist? A fixable critical is a smaller problem than an unfixable medium with no maintainer.

Input 04

Maintenance

Release cadence and directory standing. A plugin removed from WordPress.org is treated as unmaintained regardless of its CVE count.

What each rating means

Critical Exploitable now, active on the site, fix exists. Do it today.
High Serious, but needs a condition you may not meet, or has no patch yet. Plan the replacement.
Medium Real but constrained, usually authenticated or low impact. Fix on your next maintenance pass.
Low Maintained, patched, no open findings. Keep updating and move on.

Where the data comes from

Published CVE records daily
WordPress.org plugin API daily
Plugin changelogs and release tags weekly
Vendor security advisories on publication
Our own testing and reports continuous
Disagree with a rating?

Send the plugin slug and your reasoning. Corrections are published with the date they were made.

research@wpdeeply.com

This page exists so you can check our work. If you think a rating is wrong, the rules below are what to argue with.

Where vulnerability data comes from

WPDeeply aggregates published vulnerability records from established WordPress vulnerability intelligence sources, plus WordPress.org directory metadata and its own research archive. The sources actually in use are listed on data sources, and that page changes only when an integration genuinely goes live.

How versions are matched

  • A component is identified by its directory slug and the version in its file header.
  • That version is compared against the affected range on each record, and against the first patched version.
  • A component is reported as affected only when its version falls inside an affected range and below the patched version.
  • Where a record gives no patched version, the finding is reported as unresolved rather than fixable.

How severity is decided

Where a CVSS score exists it is shown. But the position in your report is not the CVSS score — it is a combination of the score, whether the component is active, whether the vulnerability requires authentication, and whether a fix exists. A critical-scored issue in a deactivated plugin ranks below a high-scored issue in an active one.

Definitions

  • Abandoned — no release in 24 months, or removed or closed on WordPress.org.
  • Unsupported — the component or the PHP/WordPress version it runs on no longer receives security fixes from its maintainer.
  • Unnecessary attack surface — installed code that is not currently in use: inactive plugins, unused themes.
  • Unresolved — a published vulnerability with no patched version available.

Risk ratings on plugin profiles

LOW, MEDIUM, HIGH and CRITICAL on a plugin profile describe the plugin’s current state for a typical site: whether anything is unresolved, how recently it was maintained, its directory standing, and its vulnerability pattern over time. A long history of promptly patched issues is not automatically bad — it often means somebody is looking.

Limitations

  • False positives — forks and white-labelled bundles keep the upstream version string; hand-edited headers lie.
  • False negatives — a vulnerability nobody has published cannot be matched, and premium plugins outside the directory are covered less completely.
  • Timing — records appear when they are published, not when the flaw was introduced.

Resources

Corrections

Report a bad match or a wrong rating to triumphoid@proton.me with the plugin slug and version. Corrections to published findings are made in place and noted.