WordPress + AI: the security debt nobody budgeted for

WordPress security researchers logged over eleven thousand new vulnerabilities across the platform's ecosystem in 2025 — a sharp year-over-year jump, with an even sharper rise in the share of those rated highly exploitable. Industry reporting on the trend points at the same accelerant behind most of 2026's other AI-code security stories: speed without review.

What the numbers actually show

A widely cited 2026 WordPress security report recorded over eleven thousand new vulnerabilities disclosed across the ecosystem in 2025 alone — a roughly 42% increase year over year — with a disproportionate jump of over 100% in vulnerabilities rated highly exploitable specifically. The same reporting explicitly names AI-assisted, "vibe-coded" development as a direct contributor to that acceleration, not a coincidental correlation.

One concrete example from 2026: a WordPress AI-assistant plugin installed on more than a hundred thousand active sites shipped a critical vulnerability that accidentally exposed login credentials on a publicly reachable page — the kind of mistake that's hard to make when a human is deliberately reviewing what a credential-handling code path does before it ships, and much easier to make when that review step gets skipped in favor of "it works."

The specific patterns to check for

Unauthenticated user enumeration. WordPress's REST API exposes user data at /wp-json/wp/v2/users by default on many configurations. If it returns real usernames with no authentication required, that's a direct feed for credential-stuffing attacks — the attacker already has half of what they need.

XML-RPC amplification. xmlrpc.php, if left reachable and unrestricted, allows the system.multicall method to bundle many login attempts into a single HTTP request — turning a slow, easily rate-limited brute-force attempt into a fast, hard-to-detect one.

Migration and backup artifacts. Sites moved or scaffolded quickly often leave .bak files, exported SQL dumps, or debug logs sitting in a publicly reachable directory — an AI-assisted migration is no more likely to clean these up afterward than a rushed manual one, and often less likely, since nobody's manually walking the file tree checking for leftovers.

Cracked or unreviewed themes and plugins. An AI assistant asked to "add this feature" will sometimes suggest or install a plugin without any way to evaluate its provenance — and pirated or backdoored themes remain a common entry point specifically because they're difficult to distinguish from the real thing by appearance alone.

How to check your own WordPress site

Request /wp-json/wp/v2/users directly and confirm whether it returns real usernames. Request /xmlrpc.php and check whether it responds at all — if you don't use it for anything (most sites don't, unless connecting the mobile app or a specific external publishing tool), it should be disabled entirely, not just left "unused."

curl -s https://yoursite.com/wp-json/wp/v2/users | head -c 300
curl -s -o /dev/null -w "%{http_code}\n" https://yoursite.com/xmlrpc.php

Search common backup and export paths directly (/wp-config.php.bak, /backup.sql, /wp-content/debug.log) for anything a migration or a fast AI-assisted deploy might have left behind and never removed.

The fix

Disable REST API user enumeration (a one-line filter in functions.php or a lightweight, reputable security plugin), disable xmlrpc.php entirely if you don't rely on it, and add a deploy-time step — manual or automated — that removes backup, debug, and export files before a site or migration goes live rather than relying on remembering to clean up afterward. Treat any AI-suggested plugin or theme the same way you'd treat one from an unfamiliar developer: check its source, its review history, and whether it's still actively maintained, before installing it on a production site.

Common questions

More reading: Exposed storage buckets and secrets · Broken access control · All 53 scan engines, explained