If you run WordPress, the message is brutally simple: patch now. According to watchTowr principal security researcher Jake Knott, attackers began exploiting two newly fixed bugs within hours of WordPress releasing patches late Friday, and by early Saturday morning successful exploitation was already underway.

This matters because the chain leads to unauthenticated, pre-authentication remote code execution (RCE). In other words, threat actors did not need a logged-in user or special preconditions. Knott says watchTowr could trivially reproduce CVE-2026-63030 within minutes of public disclosure, then reproduce the second issue, CVE-2026-60137, with additional effort. The speed of replication is the point: once public proof-of-concept material and exploit code are out, real-world attacks tend to accelerate, especially when defenders are still in “wait for the weekend update” mode.

WordPress released patches for both CVEs late Friday, and by Saturday it was game over. Knott explains that early exploitation used public exploit code to exfiltrate hashed credentials first. Remote code execution followed once additional details became public. He also notes “widespread impact” across organizations of every size and vertical, based on watchTowr’s vantage point across a global client base.

So what are these vulnerabilities? CVE-2026-60137 is a moderate-severity SQL injection issue. CVE-2026-63030 is the critical one: a REST API batch-route confusion bug. The mechanics are classic “how did the server get confused?” security failure. A route confusion flaw causes arrays containing sub-requests, validation results, and matched handlers to become misaligned. That misalignment means WordPress can treat requests as trusted that it should block, including requests that should not pass validation.

Individually, each bug is difficult to exploit. Chained together, they can cause havoc because they allow unauthenticated RCE against vulnerable WordPress instances. Impact is not hypothetical. The security ecosystem started moving quickly too: the content management system credited Searchlight Cyber researcher Adam Kues with finding and reporting CVE-2026-63030. In a subsequent Friday advisory, Kues dubbed the bug “wp2shell,” and he said the attack “has no preconditions” and can be exploited by an anonymous user in a stock install with no plugins.

Kues also provided a free “wp2shell checker” to determine whether an instance is vulnerable. Meanwhile, PatchStack reported exploitation of both CVEs as of Friday night, though it did not share attack details. VulnCheck’s research team, which also began researching the patches on Friday, verified more than two dozen unique proof-of-concept exploits targeting WP2Shell as of Sunday. That proof-of-concept proliferation is a second-order risk for executives: even if your initial patch process is fast, you can still get burned by diversity in payloads, tooling, and attack paths.

The “why now” question is also harder to ignore. Knott told The Register that there’s “a very good chance the miscreants had an AI assist,” arguing that reproducing vulnerabilities with frontier AI models was only a matter of time and tokens after public disclosure. That tracks with what teams see in practice: AI tends to compress the time between disclosure and working exploitation by accelerating iteration, translation, and edge-case hunting. The headline takeaway for boards is not “AI is magic.” It is that remediation timelines are getting shorter, and attackers can cheaply operationalize new techniques.

Let’s get the versioning and patch scope you need for governance. WordPress 6.9 is affected by both vulnerabilities. WordPress 6.9.5 contains fixes for both. WordPress 6.8 is only affected by the SQL injection flaw, and WordPress 6.8.6 fixes it. WordPress 7.1 Beta 1 is also vulnerable, while Beta 2 fixes both CVEs. Versions prior to 6.8 are not affected.

John Blackbourn, a WordPress core developer, recommended that affected users “update your sites immediately.” Because of severity, the WordPress security team “enabled forced updates via the auto-update system” for sites running affected versions. That forced update lever is important from a risk-management perspective. It signals WordPress judged exploitation likelihood as high enough to override the usual “wait for your maintenance window” instinct.

Finally, the operational response. watchTowr observed more than 100 backdoor accounts created by different threat actors using variations of public tooling, after spraying the internet indiscriminately and hitting anything reachable. Knott says honeypots recorded tens of thousands of exploitation attempts. After creating backdoor admin accounts, watchTowr observed attackers deploying fake WordPress plugins to achieve RCE, exfiltrate credentials or secrets, or download additional tooling for further compromise. In one case, watchTowr watched a threat actor repeatedly attempt to pull down Overlord RAT, a Golang-based remote access trojan.

If your organization patched on Monday, Knott warns you should assume you might be dealing with fallout already in place. He recommends defenders inspect WordPress instances for new administrator accounts, malicious plugins, or other suspicious files, regardless of whether they’ve patched. Strategic stake: this is not only a “software update” story. It is a workflow story. The organizations that routinely treat patching as a ticket will lose time. The organizations that treat patching as a live incident response process will reduce the chance that the attacker’s first move is also their persistence mechanism.