WordPress RCE Vulnerabilities Put Millions of Sites at Risk

There's a particular kind of dread that spreads through the open source security community when a vulnerability isn't in some obscure third-party plugin — it's in the default install. No exotic configuration required. No sketchy marketplace download. Just WordPress, out of the box, doing what it's supposed to do, and quietly handing an attacker a shell.

That's where things stand right now.

A recently disclosed exploit chain — broken down in detail by the Low Level YouTube channel — chains two separate vulnerabilities in WordPress core to achieve unauthenticated remote code execution. The proof-of-concept works reliably, takes seconds, and the affected version range, according to Secure ISS's reporting on WordPress core critical and high severity vulnerabilities, runs from 6.8.5 up through 7.0.1. Version 7.0.2 patches the issue. If you're running something in that window, this isn't a "patch when convenient" situation.

The Setup: A Feature That Made Sense

The first vulnerability lives in the batch/v1 REST API endpoint. To understand why this endpoint exists, you need to think about how WordPress actually gets used. Content editors make frequent, incremental changes in the block editor. Without batching, every keystroke-adjacent update would fire off a separate POST request — noisy, inefficient, and rough on performance. The batch endpoint was built to bundle up to 25 REST API requests into a single call. Architecturally, that's reasonable.

The design included a safeguard: authentication requirements still applied to each sub-request. You couldn't use the batch endpoint to sneak through a request you weren't authorized to make individually. Or so the theory went.

The bug is subtle enough to make you appreciate it even while being annoyed it exists. The serve_batch_request_v1 handler builds two parallel arrays — matches and validation — and indexes them off the same offset when dispatching requests. When a sub-request path fails URL parsing, it gets appended to validation but not to matches. The arrays fall out of sync. They're no longer describing the same things at the same positions.

The consequence, as the Low Level presenter explains: "A sub request is dispatched under a different sub request handler. That is a route confusion."

The fix was a single added line of code that appends a failed parse to both arrays, keeping them aligned. That's it. One line. Its absence meant you could use the batch handler to dispatch a GET request — something the endpoint was never designed to support. Which brings us to why a GET request matters at all.

The Payload: SQL Injection Through the Back Door

Bug number two is a SQL injection in WordPress's post query method, specifically in the author__not_in parameter. That field accepts post author IDs, and historically, the exposed surface for manipulating it — a parameter called author_exclude — was sanitized before it could touch author__not_in. The sanitization worked. The problem is that it only ran on requests coming through the front door.

The route confusion from bug one lets an attacker dispatch a request through the batch handler's internals, bypassing that sanitization entirely. The author__not_in field gets hit with unsanitized input. SQL injection achieved.

But here's where the exploit gets genuinely interesting, and genuinely difficult. This is a blind SQL injection — meaning the attacker doesn't see query results directly. The classic approach to blind SQLi involves conditional time delays: ask the database a yes/no question, sleep for ten seconds if the answer is yes, check how long the response took. Methodical, but painfully slow when you're trying to extract a SHA-256 hash one character at a time.

The exploit doesn't do that. Instead, it uses the SQL injection — which is technically a SELECT operation, not an INSERT — to poison WordPress's internal object cache. The chain goes something like this: make a request to a non-existent post, which causes WordPress to create a temporary oEmbed cache entry; use the SQL injection to retrieve that cache entry's ID; poison the batch request through a customizer change; then make a request to the wp/v2/users endpoint — which, critically, is running in an admin context internally — to create a new admin user. That admin user logs in and uploads a plugin. The plugin is a web shell.

The Low Level presenter, describing this sequence, puts it simply: "They somehow figured out how to use an SQL select injection, which is by default not allowed to do database insertions, to do an object cache poisoning and object hydration cache poisoning that creates a fake post, and that fake post uploads a web shell."

Even explaining it in prose, there's something almost elegant about it. Each step solves a constraint imposed by the previous one. It's a logic puzzle where the answer happens to be "unauthorized root access."

The Scale Problem

Here's why this lands harder than your average WordPress vuln: WordPress isn't a developer toy. According to market share data compiled by WebPopDesign, WordPress powers roughly 42% of all websites. That's not just tech blogs and agency portfolios. It's restaurant websites, nonprofit landing pages, small business storefronts — the Thai place on your block almost certainly isn't running a custom React frontend.

Most of those operators are not monitoring CVE feeds. They're not watching security YouTube. They updated WordPress when their hosting dashboard nagged them, or they didn't, and they're running whatever version they installed two years ago. The affected version range here is specific enough that being behind on updates actually offers accidental protection — the vulnerable batch endpoint feature didn't exist in older releases. But relying on that is not a strategy. Patch to 7.0.2 or later.

The AI Angle, and Why It's Worth Sitting With

The Low Level presenter raises a point that he's careful not to oversell but clearly finds significant: the proof-of-concept for this exploit appeared roughly ten hours after the vulnerabilities were publicly disclosed. He notes that "AI was definitely involved in the creation of this POC."

Set aside the question of attribution for a moment and focus on the mechanics. The two vulnerabilities individually aren't catastrophic. A route confusion bug that lets you dispatch GET requests through a batch endpoint isn't obviously weaponizable. A blind SQL injection that can't be read directly is laborious to exploit. What the POC does is identify a path that connects them — specifically the object cache poisoning route — that converts a technically-interesting-but-slow blind SQLi into an instantaneous, reliable shell. That's a non-obvious insight, and the turnaround was genuinely fast.

Whether AI "solved" this or assisted a skilled researcher in solving it faster is a question the presenter wisely doesn't answer definitively. What's harder to argue with is the outcome: working exploit, ten hours, no errors.

What Defenders Should Actually Do

The patch is available. That's the whole answer for most people. But the Low Level breakdown also surfaces a secondary risk worth naming: if a box running vulnerable WordPress has already been compromised, the current landscape of Linux kernel local privilege escalation vulnerabilities means an attacker who got in as an unprivileged web user may not have stayed unprivileged for long. The presenter's recommendation for a potentially compromised host is blunt — pull the code, destroy the instance, rebuild clean, patch, restore. That's aggressive advice, but it's not wrong.

For defenders who want to think about the systemic issue rather than just this specific fix: unauthenticated batch endpoints are a category of risk, not just a WordPress quirk. Any endpoint that aggregates and dispatches sub-requests needs careful handling of mismatched state between parsing steps. The bug here was an index mismatch between two arrays — the kind of thing that's easy to miss in review and trivial to verify in retrospect. "This single line was not in this request handler," the presenter notes, "and because of that, you were able to use the REST API batch handler to batch request a GET request."

One line. Millions of sites.

Open source at scale means that one line in a shared codebase has blast radius far beyond what any proprietary product would face. That's not an argument against open source — it's an argument for taking its security infrastructure seriously, which is a conversation the WordPress ecosystem has been having for years with mixed results. The difference now is that the window between disclosure and working exploit is measured in hours, not weeks.

If you haven't already, go check your WordPress version.

---

Dev Kapoor is Buzzrag's open source and developer communities correspondent.