WordPress: 11,334 flaws in 2025, and 91% come from plugins
by detektd team
Patchstack coordinates a large share of vulnerability disclosures in the WordPress ecosystem, through its bug bounty program and its role as a CVE authority. Its State of WordPress Security in 2026 report, published in February, reviews 2025: 11,334 new vulnerabilities, 42% more than in 2024. WordPress core accounts for only 6, all low priority. Everything else comes from extensions: 91% from plugins, 9% from themes.
new vulnerabilities in the WordPress ecosystem in 2025, up 42% year over year, 91% of them in plugins (Patchstack, 2026)
A dependency like any other
A WordPress plugin is exactly what an npm package is to a JavaScript application: third-party code, written by someone else, running with your site's full privileges. A site often stacks several of them, each maintained at its own pace, sometimes by a single person. That's why the number of flaws follows the number of extensions rather than the quality of core.
Not all these flaws are equal. Patchstack estimates that 4,124 of them (36%) warranted a protection rule, and that 1,966 (17%) were serious enough to be exploited at scale. That subset is the one growing fastest: +113% highly exploitable flaws in one year. Paid extensions aren't safer: 1,983 valid reports (29% of the total) concern them, 76% exploitable in real attacks, and they have three times more actively exploited flaws than free extensions.
Five hours, and often no fix
Two figures sum up the problem. First, 46% of flaws had no fix from the vendor when they were disclosed: updating is useless when no update exists. Second, for the most exploited flaws, the weighted median delay between disclosure and mass exploitation is five hours, and about half of high-impact flaws were exploited within 24 hours.
of WordPress flaws disclosed in 2025 had no fix available at the time of disclosure (Patchstack, 2026)
The host's firewall doesn't close the gap. Patchstack tested several hosts' protections against real attacks: on known, exploited WordPress flaws, they blocked only 12% of attacks, and 26% on a broader sample. A generic WAF rule recognizes a textbook SQL injection, but not a perfectly legitimate request sent to an AJAX action a plugin forgot to protect.
Anatomy of the most exploited flaw
According to Patchstack, broken access control was the most exploited flaw class in 2025. In a plugin, it almost always takes the same shape: an entry point (AJAX action, REST route) that performs a sensitive operation without checking who's asking. The wp_ajax_nopriv_ hook makes the action reachable by logged-out visitors, and the lack of current_user_can() and nonce verification does the rest.
// Vulnerable: any visitor, logged in or not, can change any option
add_action('wp_ajax_nopriv_myplugin_save', 'myplugin_save');
add_action('wp_ajax_myplugin_save', 'myplugin_save');
function myplugin_save() {
update_option($_POST['key'], $_POST['value']);
wp_send_json_success();
}
// Fixed: logged-in admins only, nonce checked, allowlisted option
add_action('wp_ajax_myplugin_save', 'myplugin_save');
function myplugin_save() {
check_ajax_referer('myplugin_save');
if (!current_user_can('manage_options')) {
wp_send_json_error(null, 403);
}
$value = sanitize_text_field(wp_unslash($_POST['value'] ?? ''));
update_option('myplugin_banner_text', $value);
wp_send_json_success();
}The vulnerable version lets anyone change any site option, for instance users_can_register and default_role, which is enough to sign up as an administrator. The same pattern exists on the REST API side: a route declared with 'permission_callback' => '__return_true' is public, however sensitive what it does.
Reducing exposure
- Delete deactivated or unused plugins: a deactivated plugin stays on disk, and its files often remain directly reachable.
- Turn on automatic extension updates (available since WordPress 5.5), at least for security fixes: against a five-hour window, a manual update arrives too late.
- Follow the security advisories for your extensions and, for unfixed flaws, deactivate the extension or apply a targeted virtual patch.
- Harden the rest: define('DISALLOW_FILE_EDIT', true) in wp-config.php, two-factor authentication for administrators, and no copy of wp-config.php left on the server.
What detektd checks on a WordPress site
When detektd recognizes WordPress, it compares the core version the site advertises with known flaws, checks whether the account list is readable without authentication via /wp-json/wp/v2/users (the first step of a password attack), and looks for backup copies of wp-config.php that would expose the database credentials. The general checks apply too: headers, TLS, sensitive files, forms. A precise inventory of installed plugins and their versions, however, takes dashboard access, not an external scan.
Hijacked subdomains: one forgotten DNS record is enough
The CDC, Deloitte, PwC, Berkeley, Stanford: the Hazy Hawk group took over subdomains of major organizations without hacking anything, by claiming cloud resources they had deleted. In April 2026, a new wave targeted 34 US universities. How a subdomain takeover works, and why it's worse than a spam page.
ChainDrop: an npm worm shipped 444 poisoned packages with valid signatures
On August 4, a self-propagating worm infected more than 400 npm packages downloaded around 2 billion times a month, through their maintainer's own CI pipeline. The signatures were valid. That's exactly the problem.