WordPress’s AI-Discovered wp2shell Flaw Is Fueling a Global Webshell Wave

Hackers began planting webshells on WordPress sites within days of the critical wp2shell bug going public, a flaw one researcher says he found using an OpenAI model. WordPress patched the issue, tracked as CVE-2026-63030 and CVE-2026-60137, on July 17. Proof-of-concept code followed within a day, and by the weekend multiple security firms were logging real intrusions.

Searchlight Cyber, the firm that found the bug, withheld technical detail specifically to buy defenders time to patch quietly. That window lasted barely a weekend. The same speed that let one researcher find and prove out a critical WordPress core flaw in days let other teams rebuild it almost as fast, and by July 19 at least two dozen independent proof-of-concept exploits were already circulating.

A Route-Confusion Bug and a Type-Juggling Flaw Make One Critical Chain

wp2shell is not one bug. It is two, chained together. CVE-2026-63030 is a route-confusion flaw in the WordPress REST API’s batch endpoint, the interface plugins and outside apps use to bundle several requests into one call. It lets an anonymous request slip past permission checks that should have blocked it.

That confusion opens a path to the second flaw, CVE-2026-60137, a SQL injection in WP_Query’s author__not_in parameter. WordPress’s own validation logic expected an array of numbers there. Feed it a string instead and the check never fires, according to a technical breakdown from application security firm Brandefense. Chained together, the two bugs take an anonymous HTTP request all the way to code execution on a stock install. No plugin, no login, no special configuration needed.

WordPress shipped fixes for every affected branch on July 17: version 7.0.2 for the current major release, 6.9.5 for the previous one, and 6.8.6 for a narrower band that carried only the SQL injection piece. Rapid7 lists a CVSS score of just 7.5 for the batch-route bug, even though the GitHub Security Advisory rates the overall chain Critical, a reminder that the numeric score and the plain-English label do not always agree.

Only the 6.8 branch escaped the full chain, and only because the batch endpoint that makes the route confusion possible did not exist yet in that version.

A Language Model Did the Reverse Engineering

The researcher credited with finding the batch-route bug is Adam Kues, who works at Assetnote, the attack-surface-management arm of Searchlight Cyber. He reported it through WordPress’s HackerOne bug bounty program. According to CyberNews, Kues has said the entire discovery process, from spotting the flaw to building a working exploit chain, ran through GPT-5.6 Sol Ultra, OpenAI’s current flagship model, the same one that powers ChatGPT.

CyberNews put a number on it, reporting that the AI-assisted research cost roughly $25 in model usage. The SQL injection half of the chain had already been flagged separately by three other researchers, identified in coverage only by the handles TF1T, dtro, and haongo. Two lines of research were converging on the same hole in WordPress Core before anyone thought to chain them together.

The Disclosure Weekend Lasted About 48 Hours

Searchlight Cyber’s plan was to publish the vulnerability’s existence without a technical write-up, giving site owners a few quiet days to patch before anyone could reverse-engineer the mechanics. Kues later admitted that plan barely survived the weekend.

We held off on publishing this issue to give defenders a chance to upgrade their WordPress instances over the weekend, but during that time, Calif and Hacktron were able to independently reproduce the full chain before other PoCs surfaced on GitHub.

Adam Kues, researcher at Assetnote, in comments reported by Help Net Security.

By Sunday, July 19, threat intelligence firm VulnCheck counted more than two dozen unique proof-of-concept exploits targeting wp2shell. Maurice Fielenback, head of cyber threat intelligence at Hexastrike, said his team had flagged initial exploitation attempts that same Sunday and by Monday was handling “several confirmed and suspected incidents,” in comments also reported by Help Net Security.

1. July 17, 23:29 UTC: Defiant, the company behind the Wordfence security plugin, logs the first wp2shell-related probing on customer sites, hours after WordPress shipped the patched versions.
2. July 17, 23:42 UTC: A clear SQL injection attempt follows just 13 minutes later, according to Defiant’s own aftermath report.
3. July 19: Hexastrike flags its first exploitation attempts, and VulnCheck logs more than two dozen unique proof-of-concept exploits already in circulation.
4. July 20: Johannes Ullrich, dean of research at the SANS Technology Institute, publishes honeypot data showing two-stage attacks already running at scale.
5. July 21: Researchers at Field Effect trace scanning activity to more than a dozen distinct IP addresses across several countries, and Kues publishes a follow-up detailing the AI-assisted discovery process.

Less than four days separated a quiet patch release from internet-wide scanning traced across more than a dozen countries.

Webshells Dressed Up as Security Plugins

Cloud security company Wiz has tracked the attacks since disclosure. Researchers Shahar Dorfman and Gili Tikochinski wrote that much of the traffic hitting vulnerable sites is mass scanning, some of it from legitimate security tools and some from criminals hunting for open doors. Where scanning turns into a real intrusion, a pattern repeats: attackers query the REST API for administrator usernames and emails, then attempt local file inclusion, a trick for coaxing a server into reading files it should not, against wp-config through admin-ajax.php to pull database credentials and authentication keys.

One payload Wiz found was a 150 KB file disguised as a legitimate security plugin called CMSmap. Inside was a full attack platform with its own password-protected interface, file management, database access, port scanning, and multiple privilege-escalation modules. The code sat behind layers of hex-encoded and gzip-compressed text, unpacked only once the page actually ran. Wiz’s own telemetry found 60% of WordPress organizations had a vulnerable instance when the two CVEs were published, and a quarter had one exposed directly to the internet. A third payload registered its own REST API route behind a permissive callback that accepts any request, giving attackers a standing command channel disguised as an ordinary plugin.

Johannes Ullrich published a simpler variant caught in his own honeypots. The webshell landed inside a randomly named file under wp-content/cache, and visiting it without the right password string returned a fake error page instead of the shell. “I call these Jedi errors, this is not the page you are looking for,” Ullrich wrote. He found the webshell checked for five different PHP functions, including system(), exec(), and shell_exec(), any one of which would let it run commands. “The attacker later also added a new admin user to the WordPress database,” Ullrich noted, advising site owners to check the cache directory and their user list for anything unfamiliar.

Why Are Thousands of Sites Still Exposed?

A live tracker built by Macnica researcher Yutaka Sejiyama puts the patch rate at 81.6% across a sample of 124,580 WordPress sites. That leaves roughly 22,900 sites in that sample alone still running vulnerable code, days after both fixes and public exploits became available.

Patching does not necessarily undo what already happened. A scanning tool from InstaWP, a WordPress hosting and staging platform, warns that cleaning a live site does not clean its backups. Several hosting customers who updated WordPress kept seeing the same backdoor reappear on brand-new sites, because those sites were provisioned from a template snapshot captured while the original was already compromised.

This is not the first time this year that a core weakness, or a widely installed plugin, has put six-figure numbers of WordPress sites at risk. A separate authentication bypass exposed 200,000 WordPress sites running the Burst Statistics plugin earlier this year. The compressed timeline also echoes a wider pattern across web infrastructure: officials gave US federal agencies just four days to patch a LiteSpeed cPanel flaw already under attack.

What to Check on Your Site Right Now

Security researchers who have spent the past week responding to wp2shell incidents converge on the same short list of checks, whether or not a site shows obvious signs of trouble.

• Confirm the version, not the dashboard number. Forced automatic updates can fail silently, so verify the installed WordPress version directly rather than trusting the admin screen.
• Check the cache directory. Look for unfamiliar PHP files inside wp-content/cache, the exact location Ullrich’s honeypots caught the simplest webshells using.
• Audit every administrator account. Look for users created in the past week that nobody on the team recognizes.
• Review installed plugins for anything unexpected, especially ones nobody deliberately installed or that mimic well-known security tools.
• Preserve logs before any cleanup. Much of the exploit chain runs through POST request bodies that ordinary access logs will not show, so the database itself is often the best evidence of what happened.

Cleanup does not replace updating. A site scrubbed of a webshell but still running a vulnerable WordPress version is one bad scan away from getting hit again.

Frequently Asked Questions

Why Did a Core WordPress Bug Get a CVE Number?

Most WordPress security issues live in third-party plugins, and many of those never receive a CVE at all. wp2shell is different because both flaws sit inside WordPress Core itself, not an add-on, which is why WordPress’s security team and outside researchers treated it as serious enough to formally track and patch across every supported branch at once.

How Can I Tell if My Site Already Has a Wp2shell Backdoor?

Beyond checking wp-content/cache for stray PHP files, a scanning tool published by InstaWP flags rogue administrator accounts using patterns seen across real incidents, usernames like wpsvc_ or wp2_ followed by random characters, or email addresses on attacker-controlled domains rather than the site’s own. A webshell disguised as a plugin will often carry a fake WordPress.org Community author credit despite being only a few kilobytes in size.

Is wp2shell Exploited With One Request or Many?

Both descriptions are accurate at different stages. Reaching the SQL injection can happen through a single crafted HTTP request. But a full compromise typically takes a dozen or more requests, researchers at Eye Security found, since the data comes out through blind SQL injection one value at a time rather than all at once.

What if I Cannot Update WordPress Immediately?

Wiz recommends blocking anonymous access to the batch endpoint at a web application firewall, either the path /wp-json/batch/v1 or the query form ?rest_route=/batch/v1, or disabling anonymous REST API access entirely until the update can be applied. Researchers stress this is a stopgap; the underlying flaw still needs a real patch.

Were Pre-6.8 Versions of WordPress Ever at Risk?

No. Versions released before 6.8 never had the batch endpoint that makes the route-confusion bug possible, so they fall outside this particular chain entirely, even though older installs can carry their own unrelated security issues.