Two bugs — individually awkward to exploit, devastating when combined — enabled unauthenticated remote code execution across WordPress installations of every size by Saturday morning.
Summary
- CVE-2026-63030 (critical REST API route confusion) and CVE-2026-60137 (SQL injection) chain together to allow pre-authentication RCE on WordPress 6.9 and certain other versions.
- Exploitation began within hours of Friday’s patch release, with tens of thousands of attempts recorded on honeypots and more than 100 backdoor administrator accounts created by multiple threat actors.
- Attackers progressed from credential exfiltration to RCE to deploying malicious plugins and remote access trojans in a rapid, automated campaign.
- WordPress has pushed forced updates via its auto-update system; patched versions are 6.9.5 and 6.8.6 for production releases.
- Any organisation that had not patched by the weekend should treat its WordPress instance as potentially compromised and inspect for rogue admin accounts, malicious plugins, and suspicious files.
What happened
WordPress released fixes for two security vulnerabilities late on Friday. Within a day, active exploitation was already well advanced. The two bugs — a moderate-severity SQL injection flaw tracked as CVE-2026-60137 and a critical REST API batch-route confusion bug tracked as CVE-2026-63030 — are difficult to exploit in isolation. Chained together, however, they provide any anonymous, unauthenticated attacker a direct path to remote code execution on a stock WordPress installation, no plugins required.
How the chain works
The route confusion flaw at the heart of CVE-2026-63030 causes the arrays containing sub-requests, validation results, and matched handlers to become misaligned, according to analysis by Hacktron researchers. The practical consequence is that WordPress loses track of which incoming requests have passed validation and begins treating all of them as trusted — including requests that should be blocked outright. Researcher Adam Kues of Searchlight Cyber, who discovered and reported the bug, named it wp2shell and confirmed that it carries no preconditions: a fresh, default WordPress install is sufficient to be at risk. Kues also released a free checker organisations can use to confirm whether their instance is vulnerable.
AI-assisted exploitation and rapid weaponisation
Jake Knott, principal security researcher at watchTowr, told The Register that frontier AI models almost certainly shortened the window between public disclosure and working exploits. “Once the vulnerabilities were publicly disclosed, reproducing them with the help of frontier AI models was only a matter of time and tokens,” Knott said, noting that his team reproduced CVE-2026-63030 within minutes and the SQL injection flaw with only modest additional effort. By early Saturday, exploitation was already under way — initially drawing on public exploit code to exfiltrate hashed credentials, then progressing to full RCE once further technical details became available. VulnCheck independently verified more than two dozen unique proof-of-concept exploits targeting wp2shell by Sunday.
Scale and attacker behaviour
watchTowr’s honeypots recorded tens of thousands of exploitation attempts over the weekend, along with more than 100 backdoor administrator accounts created by different threat actors using variations of publicly available tooling. Once access was established, observed post-exploitation activity included deploying fake WordPress plugins, exfiltrating credentials and secrets, downloading additional tools, and in at least one case repeatedly attempting to install Overlord RAT, a Golang-based remote access trojan. Knott described the broader pattern as indiscriminate internet-wide spraying: attackers hitting anything reachable and waiting to see what responded. Security firm PatchStack also reported exploitation of both CVEs as of Friday night, though did not publish specific attack details.
Affected versions and patching
WordPress 6.9 is affected by both vulnerabilities; version 6.9.5 addresses them. WordPress 6.8 is affected only by the SQL injection flaw, fixed in 6.8.6. WordPress 7.1 Beta 1 is also vulnerable; Beta 2 fixes both CVEs. Versions prior to 6.8 are not affected. Given the severity, the WordPress security team enabled forced updates through the platform’s auto-update mechanism for sites running affected versions. Core developer John Blackbourn publicly advised affected users to update immediately.
Why it matters
This incident is a textbook illustration of how the window between patch release and mass exploitation has compressed to the point where weekend timing offers no buffer. The combination of publicly available proof-of-concept code, AI-assisted reproduction, and automated scanning means that any internet-facing WordPress instance on an affected version should be assumed reachable by attackers within hours of a critical disclosure. For CISOs, the exposure is amplified by WordPress’s prevalence across corporate web properties, intranets, and customer-facing sites. The attack requires no authentication and no installed plugins, which removes two of the usual compensating controls organisations might rely upon. The post-exploitation behaviour — backdoor accounts, malicious plugins, RAT deployment — suggests attackers are prioritising persistence and lateral movement, not just opportunistic defacement. Organisations running WordPress at scale need a repeatable process for emergency patching outside business hours, and those that were not patched by the weekend face a likely-compromise scenario that demands forensic review rather than simply applying the fix.
What to do now
- Update all WordPress instances to version 6.9.5 (if running 6.9) or 6.8.6 (if running 6.8) immediately; ensure WordPress Beta environments running 7.1 Beta 1 are updated to Beta 2.
- Audit all WordPress administrator accounts for any unfamiliar or recently created entries and remove unauthorised accounts.
- Review installed plugins for any additions that cannot be attributed to known change activity, and remove or quarantine suspicious plugins.
- Inspect the WordPress file system for unexpected or recently modified files that could indicate backdoor deployment or additional tooling.
- Use the free wp2shell checker released by Searchlight Cyber to confirm whether individual instances remain vulnerable before or after patching.
- Even after patching, treat any instance that was exposed during the weekend as potentially compromised and conduct appropriate forensic review rather than relying on the patch alone to close the incident.
