Searchlight Cyber didn’t wait for a CVE number before naming what it found. The researchers called the bug “wp2shell” and published details last week, describing a SQL injection flaw sitting inside WordPress core itself, not some abandoned plugin nobody updates. That distinction matters more than it sounds. Within days the flaw had a formal designation, CVE-2026-63030, and within days after that, attackers were already chaining it with a second core vulnerability, CVE-2026-60137, to get unauthenticated remote code execution on a platform that still runs something like forty percent of the web. If you needed a fresh reminder of how thin the margin has gotten between disclosure and exploitation, this is it. This is where cybersecurity stops being a policy conversation and turns into a stopwatch.

A Core Bug, Not Another Plugin Mess

Most of the WordPress vulnerability news you read in a given month comes from the plugin ecosystem. Fifty thousand plugins, wildly uneven code quality, and a lot of abandoned projects nobody bothered to deregister. That’s a real problem, but it’s a familiar one, and it’s largely opt-in: you can audit your plugin list, trim it, and cut a huge amount of risk. wp2shell doesn’t offer that escape hatch. It lives in core, in code that ships with every install by default, which means the exposure isn’t tied to a site owner’s plugin choices. It’s tied to whether the site is running WordPress at all.

SQL injection bugs that lead straight to unauthenticated remote code execution are also rare enough that when one shows up in core, it gets attention fast, from both sides. Defenders scramble to patch. Attackers scramble to weaponize before that patching finishes. Searchlight Cyber’s decision to publish before a CVE existed wasn’t reckless, that’s a normal part of coordinated disclosure, but it did mean the vulnerability had a nickname and a writeup circulating in security circles before it had the kind of formal tracking number that trips automated patch-management alerts. That gap, small as it looks, is exactly where exploitation research lives.

Three Days Is Basically Instant

According to Dark Reading, attackers were widely chaining CVE-2026-63030 with CVE-2026-60137 within three days of disclosure. Three days to go from “here’s a technical writeup” to “here’s a working exploit chain being fired at one of the largest attack surfaces on the internet” isn’t a slow week for a threat actor, it’s closer to the new baseline. The SANS Internet Storm Center noted exploitation attempts starting shortly after the bug went public, which tells you the reverse-engineering work was likely already underway the moment the details hit a blog post, CVE number or not.

This is the part that should reshape how security teams think about patch cadence. A CVE identifier used to function as a kind of starting gun, the signal that told vulnerability management systems to open a ticket and start the clock. When exploitation starts before the CVE is even assigned, that starting gun has already fired somewhere else, and your ticketing system is the thing running late.

The Same Clock Is Running On GitHub

It isn’t only WordPress admins racing a shortening clock. Researchers this week disclosed a campaign called FakeGit spanning roughly 7,600 malicious GitHub repositories, more than 800 of them posing as AI tools or Model Context Protocol servers, built to deliver a malware family called SmartLoader. The mechanics are different, lookalike developer profiles, cloned project names, README files polished enough to pass a quick skim, but the underlying bet is the same one wp2shell’s operators made: move faster than the verification step. A developer grabbing an MCP server off GitHub because it looked legitimate is making the same trust decision, at the same speed, as a site owner who hasn’t gotten around to patching core yet. Neither one is careless. Both are just outrun.

What Actually Slows These Down

None of this means patching stops mattering, it means patching alone isn’t the whole plan. If you run WordPress, get to CVE-2026-63030 and CVE-2026-60137 today, not this sprint. Beyond that single fix, a few habits close the gap that made this exploitation window possible in the first place:

• Put a web application firewall in front of anything running WordPress core, tuned to catch SQL injection patterns rather than relying solely on core patches to be current.
• Enable brute-force protection and rate limiting on admin login paths; a lot of exploit chains still need a foothold that a locked-down login page denies.
• Treat threat detection as an ongoing subscription, not a one-time install, log file access to wp-content and wp-admin, and alert on anything writing new PHP files outside the plugin directories you expect.
• Build defense in depth around the assumption that core will eventually have a bug like this one, database accounts with least-privilege access, file integrity monitoring, and network segmentation so a compromised web server doesn’t hand over the rest of your environment.
• Have an incident response plan that already covers “core CMS RCE” as a scenario, so nobody’s improvising a webshell hunt for the first time under pressure.

On the developer side, the FakeGit campaign argues for the same discipline applied to repositories: check maintainer history, star count, and commit patterns before installing anything that touches AI tooling or MCP servers, and don’t let a slick README substitute for actually reading the code you’re about to run.

Frequently Asked Questions

What is wp2shell, exactly?

It’s the nickname Searchlight Cyber gave to a SQL injection vulnerability in WordPress core, now tracked as CVE-2026-63030, that can lead to unauthenticated remote code execution when chained with a second flaw, CVE-2026-60137.

How urgent is patching this?

Very. Exploitation attempts began within days of disclosure and are already being chained across a large share of WordPress’s installed base, so this belongs at the top of the patch queue rather than in a routine maintenance window.

Sources

• WordPress Exploitation Underway (CVE-2026-63030)
• ‘WP2Shell’ Opens Millions of WordPress Sites to Remote Takeover
• FakeGit Campaign Uses 7,600 GitHub Repositories to Spread SmartLoader Malware