WordPress plugin vulnerabilities: how to know within an hour whether your site is affected

A plugin advisory is published somewhere every working day. The question a company owner actually has is narrower: does this one touch my site? Answering it needs a list of what the site runs, two public databases and about an hour, all inside your own admin panel.

Why plugins, not WordPress itself

WordPress core is one codebase with automatic updates since version 3.7 (developer.wordpress.org hardening page). A plugin is separate software with its own author, release rhythm and quality. The numbers reflect that.

The Patchstack vulnerability statistics, read on 2026-10-25, give two all-time disclosure counts, 21,470 via Patchstack and 23,923 from other sources, which add up to 45,393 published WordPress vulnerabilities. By software type, 41,648 (92 %) are in plugins, 3,401 (7 %) in themes and 344 (1 %) in core.

Of all published entries, 33,561 (74 %) are patched and 11,832 (26 %) are not.

The 60-minute procedure

1. Back up first (0–5 min)

The WordPress backup page says it plainly: "Back up your database regularly, and always before an upgrade." A site has two parts, the database and the files, and "you need both to be able to fully restore a typical WordPress site." The same page says to keep at least three backups, stored in different places and on different mediums.

Confirm today's copy exists before touching anything.

2. Inventory (5–15 min)

Go to Tools › Site Health › Info. The documentation describes two sections there, Active Plugins and Inactive Plugins; each lists the plugin, "the version of the plugin, the creator of the plugin, and whether auto-updates are enabled". The Active Theme and Inactive Themes sections do the same for themes, and the WordPress section gives the core version.

The screen has an export button that copies everything to the clipboard; paste it into a document dated today.

Two things the screen will not show. Must-use plugins in wp-content/mu-plugins "do not show in the default list of plugins on the Plugins page"; ask whoever built the site whether any exist.

And a plugin bought outside the directory is listed like any other but its updates come from the vendor, not from wordpress.org: Slider Revolution, visible on 78 sites in our sample, has no page at wordpress.org/plugins/revslider; the address resolves to a search page.

3. Look each plugin up (15–35 min)

Two public databases cover WordPress specifically.

Patchstack. The plugin page sits at patchstack.com/database/wordpress/plugin/<slug>, where the slug is the folder name under wp-content/plugins. It opens with a tally, then one row per vulnerability with the title, the affected version range and the disclosure date.

On 2026-10-25 the Contact Form 7 page showed "0 present, 7 patched", the newest row an order-replay flaw in versions up to and including 6.0.5 dated 15/04/2025; the Slider Revolution page showed "0 present, 24 patched", the newest a cross-site scripting flaw in 7.0.0–7.0.16 dated 30/06/2026.

The reading is mechanical: if your version falls inside a listed range, that row applies to you.

Wordfence Intelligence at wordfence.com/threat-intel is the second database. Wordfence also reports flaws to the CVE system: the NVD entry for CVE-2024-2242, a reflected cross-site scripting flaw in Contact Form 7 up to and including 5.9, names security@wordfence.com as its source. Look the plugin up there as well.

NVD. The general database files WordPress plugins under a CPE name. The CPE 2.3 naming specification (NIST IR 7695, linked from cpe.mitre.org) builds a well-formed name from attributes; the example on that page lists eleven of them, among them vendor, product, version and target_sw.

For CVE-2024-2242 the configuration reads cpe:2.3:a:rocklobster:contact_form_7:*:*:*:*:*:wordpress:*:* with versionEndExcluding 5.9.2: the vendor is rocklobster, the product contact_form_7, and the target_sw field is "wordpress".

Write the result next to each plugin in your inventory: open advisory affecting my version, fixed in a version I do not have yet, or nothing published.

4. Update in order (35–50 min)

The order below is our practice, not a WordPress rule.

1. Plugins with a published flaw that includes your version, one at a time, checking the site after each.
2. The remaining plugins. The Plugins screen has an "Update Available" view; select them, choose Update under Bulk Actions and Apply. The documentation adds: "Always make sure you have a current backup of your site before updating your plugins."
3. WordPress core, from Dashboard › Updates.
4. The theme, last, because that is where a visual change shows.

Since WordPress 5.5 an administrator can opt in to automatic updates plugin by plugin or in bulk from the Plugins screen; WordPress runs them twice a day by default and emails the owner after each attempt. For a company site: auto-updates on for small, well-maintained plugins, a manual tested update for the ones that render the shop or the forms.

5. Delete what you do not use (50–55 min)

The hardening page is direct: "if you are not using a specific plugin, delete it from the system." Deactivating is not enough; an inactive plugin's files are still on the server and still appear in the Inactive Plugins section. Deactivate, then Delete, and do the same for inactive themes under Appearance › Themes.

6. Stop announcing the version (55–60 min)

WordPress prints <meta name="generator" content="WordPress x.y"> into every page: the code reference describes wp_generator() as the generator tag "generated on the wp_head hook"; that tag is why 356 sites in our sample showed their core version. A theme or a small plugin can remove that action.

The hardening page: "Security through obscurity is generally an unsound primary strategy." Removing the tag makes you harder to find in bulk; it does not fix anything. Do steps 1–5 first.

How Northwestern Tideline does this every day

The procedure above is what our Sentinel engine runs continuously for a company's sites, with two limits we keep in writing. First, we read primary sources daily: the Patchstack and Wordfence databases, NVD and CVE records, and the plugin authors' own changelogs.

Second, we observe only what a site shows to any visitor: the plugin folders referenced in the page source, the ?ver= strings on their assets and the generator tag. We do not log in, we do not probe, and we do not scan anything without written authorisation.

When an advisory's affected range covers a version a site publicly shows, a person reads the match before the company hears about it, with the advisory, the date and the fix version. What a site hides we do not count; the inventory in step 2 stays yours to keep.

The product is described on the Tideline page, and the other six areas in cybersecurity for companies in the age of AI. If you want your sites' plugin lists matched against published advisories and a written update plan, send us the domains.

This guide describes public documentation and databases as read on the dates given, not your site.