Is your WordPress site a security risk? Plugins, PHP and what to check

Probably, if nobody updates it every week: 52.8% of WordPress sites run at least one plugin with a known vulnerability, and attacks on a newly disclosed hole start within hours. Check your plugins, your PHP version, your security headers and whether your login page is open to the internet.

Written by the nextwebsite.co team, and last checked on November 7, 2026.

The plugin layer is where sites go wrong

WordPress core is maintained by a large security team, and it updates itself. Plugins and themes are written by thousands of different developers, and they don't. 52.8% of WordPress sites run at least one plugin with a known vulnerability, measured from the outside, the way an attacker sees a site¹.

The pace is fast. 11,334 new WordPress vulnerabilities were disclosed in 2025, up 42% on the year before, and 91% of them were in plugins. The median time from disclosure to mass exploitation was five hours, and 46% of vulnerabilities had no patch available when they were disclosed². Updating once a month isn't enough when the attacks start the same afternoon.

Five things to check

1. Your plugins and theme. List every plugin, active or not, with its version, and look each one up in a public database such as WPVulnerability.net⁵. Delete what you don't use: a deactivated plugin's files can still be reached.

2. Your PHP version. WordPress runs on PHP, and PHP versions get security fixes for a limited time. php.net lists which versions are still supported⁴. 48.4% of PHP websites run a version that no longer gets security fixes, and PHP 7.4 alone is 19.7% of them³.

3. Your security headers. These are instructions your server sends with every page, telling browsers to always use HTTPS, which scripts to trust, and more. OWASP recommends a standard set, including Strict-Transport-Security and Content-Security-Policy⁶. Many WordPress hosts send none of them.

4. Your login page. If /wp-admin or /wp-login.php loads for anyone, bots will try passwords on it around the clock. At minimum, add two-factor sign-in.

5. Who's responsible. Someone has to apply updates every week and check that backups actually restore. If that's nobody, the site is drifting.

Fix it, or remove the layer

You can keep WordPress and keep it patched: weekly updates, fewer plugins, supported PHP, headers and two-factor sign-in. Or you can remove the layer that needs patching. A static site serves pages as files, with no PHP, plugin or database on the public server, so most of this checklist no longer applies.

Checklist

List every plugin and theme, and look each one up in a public vulnerability database.
Delete plugins you don't use; deactivated plugins can still be attacked.
Check the PHP version against php.net's supported versions.
Check for the main security headers: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and Referrer-Policy.
Put the login page behind two-factor sign-in, or take it off the public internet.
Make sure someone is responsible for updates every week, and that backups restore.

Check your own site

The free scan reads your platform, its version and every plugin it can see, and looks each one up in the public vulnerability database. It takes under a minute.

Or run just this check: the wordpress vulnerability checker.