On July 17, 2026, a GitHub Security Advisory dropped for CVE-2026-63030, a critical unauthenticated remote code execution vulnerability in WordPress core. Not a plugin. Not a theme. WordPress itself. The vulnerability, nicknamed wp2shell, affects versions 6.9.0 through 7.0.1 and lets an attacker take full control of a site without a login, without a password, without any user interaction at all. By July 21, CISA had added it to the Known Exploited Vulnerabilities catalog. By July 22, public proof-of-concept exploits were circulating. If you are running WordPress and you have not updated since mid-July, you need to stop reading and go do that now.

The story behind the discovery is almost as wild as the vulnerability itself. The researcher who found it used GPT-5.6 Sol Ultra — a $25 AI tool — to identify the flaw. Exploit brokers were offering $500,000 for a working WordPress core RCE. The researcher disclosed it responsibly instead. Whether you find that inspiring or terrifying probably depends on how you feel about AI-assisted security research.

What wp2shell actually does

The exploit chains two separate vulnerabilities together. Neither one is dangerous on its own. Together, they give an unauthenticated attacker remote code execution on any default WordPress installation.

The first bug is a logic flaw in the REST API batch processor. WordPress has a batch endpoint at /wp-json/batch/v1 that lets you send multiple API requests in a single call. The endpoint validates each sub-request and then executes them in separate loops. When wp_parse_url() fails on a sub-request path, the error gets pushed to the validation array but not the matches array. This desynchronizes the two arrays, causing every subsequent request to dispatch under the wrong handler. It is a classic validation-execution mismatch — the kind of bug that looks harmless in a code review because each piece of logic is correct in isolation.

The second bug is a SQL injection in the author__not_in parameter. The posts endpoint accepts this parameter to exclude specific authors from query results. When provided as a scalar string instead of an array, the value gets interpolated directly into raw SQL. Parameter validation normally catches this, but the batch desynchronization from the first bug lets you bypass the check entirely. A recursive batch call sidesteps the GET method restrictions, yielding pre-authentication UNION-based SQL injection.

Chaining them gets you admin access and code execution. The SQL injection lets you create an administrator account in the database. You log in with that account, upload a malicious plugin, and the server executes your code. Full site compromise. Database access, file system access, the ability to install persistent backdoors, redirect visitors to malware, or use the server as a staging ground for attacks on other sites.

Why this one is different

WordPress plugin vulnerabilities are routine. We cover them regularly on this blog because they keep happening and people keep getting burned. But a critical RCE in WordPress core is a different category of problem entirely.

There are roughly 400 million WordPress sites on the internet. When a plugin has a vulnerability, the blast radius is limited to the sites that installed that specific plugin. When WordPress core has a vulnerability, every site running a supported version is a target. The affected versions — 6.9.0 through 7.0.1 — cover the vast majority of actively maintained WordPress installations.

Cloudflare reported that the vulnerable code path can be reached when a persistent object cache is not in use. Most small and medium WordPress sites do not have Redis or Memcached configured, which means most WordPress sites are fully exposed. The researchers at Searchlight Cyber confirmed the exploit works against a default WordPress installation with no additional plugins required.

WordPress treated this as its highest-priority security issue and pushed forced automatic updates to affected sites. If your site has automatic updates enabled, you probably patched without knowing it. But automatic updates are not universal. Many managed WordPress hosts disable them. Many site owners have turned them off after a bad update broke something. And many sites are running on infrastructure where automatic updates simply do not work.

What you should do right now

If you run a WordPress site, check your version immediately. You need to be on 6.9.5, 7.0.2, or later. If you are on anything between 6.9.0 and 7.0.1, you are vulnerable.

If you cannot update immediately, there are temporary mitigations. You can block the /wp-json/batch/v1 endpoint at the web server or WAF level. Cloudflare deployed WAF rules on July 17 that protect proxied sites automatically. But these are band-aids, not fixes. The only real solution is updating WordPress.

Even after patching, you should investigate for signs of compromise. Check your HTTP access logs for unusual batch endpoint requests. Look for unfamiliar administrator accounts. Scan for PHP files that should not be there. The vulnerability has been actively exploited in the wild since at least July 21, and proof-of-concept code is publicly available. If you were running a vulnerable version during that window, assume compromise until you can confirm otherwise.

The bigger picture

A researcher found a critical WordPress core RCE using a $25 AI tool. Exploit brokers were willing to pay $500,000 for it. Those two facts together should reshape how you think about software security in 2026.

The economics of vulnerability discovery have changed. AI tools can now audit code at a scale and speed that human researchers cannot match. The barrier to finding critical bugs has dropped dramatically. The market for those bugs — both on the legitimate side through bug bounties and on the offensive side through exploit brokers — has not adjusted yet. That gap is going to cause problems.

For WordPress site owners, the lesson is the same one it has always been, just more urgent: update your software. The window between disclosure and exploitation keeps shrinking. In this case, it was four days between the advisory and CISA adding it to the KEV catalog. By then, public exploits were already circulating. If you are not patching within 24 hours of a WordPress security release, you are leaving the door open.

Sources: Rapid7 analysis, Cloudflare WAF response, Searchlight Cyber research, WordPress 7.0.2 release