wp2shell: Critical WordPress Core RCE

What You Need to Know

On Friday, July 17, 2026, the WordPress Security Team released emergency security updates for WordPress Core addressing two vulnerabilities that, when chained together, allow unauthenticated remote code execution. The chain, now widely known as wp2shell, is the first critical unauthenticated RCE in WordPress Core in nearly a decade.

If you run a WordPress site, this one matters. Exploitation does not require a vulnerable plugin, a vulnerable theme, or a logged-in attacker. A vulnerable WordPress installation exposed to the public internet is enough.

The short version

wp2shell chains two separate vulnerabilities in WordPress Core:

• CVE-2026-60137 – an unauthenticated SQL injection issue involving the author__not_in query parameter.
• CVE-2026-63030 – a REST API batch request route-confusion issue that can be chained with the SQL injection to achieve remote code execution.

The chain was discovered and responsibly disclosed by Adam Kues of Assetnote / Searchlight Cyber. His technical writeup explains how the batch API validation and execution paths could be desynchronised, allowing attacker-controlled parameters to reach a route that would normally sanitise them. From there, the SQL injection can be leveraged through WordPress post caching, oEmbed cache rows, changesets, and action hooks to create a rogue administrator account and execute code through normal admin capabilities, such as uploading a plugin.

In practical terms: successful exploitation gives an attacker full administrative control of your WordPress site and the ability to execute code with the privileges of the web server.

What is remote code execution?

Remote code execution (RCE) means an attacker can run their own code on your website’s server, from anywhere in the world, without needing a username or password. In plain English: a stranger can take control of your website without ever logging in.

RCE is the most serious category of web vulnerability. It is not just someone defacing your homepage – it is someone being able to install malware, steal your customer data, send spam from your domain, or use your server to attack other websites.

Who is affected

The affected versions differ slightly between the two vulnerabilities:

• WordPress 6.9.x – affected by both vulnerabilities. Patched in 6.9.5.
• WordPress 7.0.x – affected by both vulnerabilities. Patched in 7.0.2.
• WordPress 6.8.x – affected by the SQL injection only. Patched in 6.8.6.
• WordPress 6.7 and earlier – not affected.

Because 6.8.x is not exposed to the REST API route-confusion issue, it is not vulnerable to the full RCE chain – but it should still be updated promptly to address the SQL injection.

If your site runs WordPress 6.8.x, 6.9.x, or 7.0.x, confirm immediately that it has updated to the appropriate patched version.

Why didn’t my site update automatically?

WordPress enabled forced automatic updates for this release because of its severity. In theory, that means most sites should have patched themselves within hours of the July 17 release. In practice, many sites did not. Common reasons include:

• Automatic updates disabled in wp-config.php – a developer may have added define( 'AUTOMATIC_UPDATER_DISABLED', true ); at some point.
• A plugin is blocking updates – some “update manager” or security plugins override WordPress’s default update behaviour.
• Managed hosting settings – some hosts delay or gate core updates behind their own testing process.
• File permission problems – if WordPress cannot write to its own files, the update silently fails.
• The site is pinned to an older branch – sites on 6.8.x only receive the 6.8.6 update, not 7.0.2.

Do not assume your site patched itself just because WordPress said it would. Log in and check the version number. It takes ten seconds.

How quickly this is being exploited

This is the part that should worry you. According to Wordfence’s telemetry (all times IST):

• July 17, 2026 – WordPress releases patched versions 6.8.6, 6.9.5, and 7.0.2. Forced automatic updates are enabled due to severity.
• July 18, 00:29 IST – First exploit-shaped probing observed against the REST API batch endpoint.
• July 18, 00:42 IST – First clear SQL injection attempt observed.
• July 18-19 – Proof-of-concept exploit code and independent reproductions begin circulating publicly.
• July 20 – Searchlight Cyber publishes Adam Kues’ full technical writeup, along with a public checker at wp2shell.com.

Exploitation activity began within hours of the patch release. Sites that did not update promptly were exposed while public technical details were circulating and attackers were already probing for vulnerable installations.

How to update WordPress

Before you update: make sure you have a recent backup of your site. Most hosting control panels include a one-click backup tool, and the update itself is very safe – but if anything does go wrong, a backup means you can roll back in minutes rather than rebuilding from scratch. If you are not sure how to take a backup, ask us before proceeding.

There are three ways to get your WordPress site updated:

1. Contact your web designer. If someone built or maintains your site, they should be your first call. Ask them to confirm your WordPress Core version and update to 6.8.6, 6.9.5, or 7.0.2 as appropriate.
2. Update WordPress via your hosting control panel. Most hosting plans include a one-click WordPress updater. Log in to your hosting control panel, find the WordPress or Softaculous section, and run the update from there. Alternatively, log in to your WordPress admin area and go to Dashboard → Updates.
3. Contact us and we will update WordPress for you. If you would like WebWorld to handle the update, open a support ticket and we will take care of it. This is a paid service – we will confirm the cost with you before any work begins.

How do I know if I’ve already been hacked?

This is the question most people ask after reading about a vulnerability like this. Here are the warning signs to look for:

• Unfamiliar administrator accounts – in wp-admin, go to Users → All Users and check every account with the Administrator role. If you see one you did not create, treat the site as compromised.
• Plugins or themes you did not install – check Plugins → Installed Plugins and Appearance → Themes for anything new.
• Unexpected posts, pages, or spam links – especially pharmaceutical, gambling, or crypto content you did not write.
• Changed files – if you have a file-integrity plugin (Wordfence, Solid Security, etc.), review its scan results for modified core files.
• Google Search Console warnings – “This site may be hacked” or “Deceptive site ahead” notices.
• Sudden traffic spikes or strange outbound traffic – your hosting control panel’s bandwidth graphs can show this.
• Visitors reporting browser warnings – red “dangerous site” interstitials from Chrome or Firefox.

You can also run your site through the public checker at wp2shell.com to confirm whether it is still vulnerable.

If any of the above looks familiar, do not just patch and move on. Patching closes the door, but it does not remove an attacker who is already inside. A compromised site needs to be professionally cleaned – contact us or your web designer immediately.

After updating: what to check

Once your site is patched, take a few minutes to verify everything is clean:

1. Confirm the update completed successfully. Check the version number in the bottom-right corner of wp-admin, or go to Dashboard → Updates.
2. Review administrator accounts for any unexpected users (Users → All Users).
3. Review recent plugin uploads and file changes for anything you did not authorise.
4. Check your site with the public checker at wp2shell.com.
5. If you have Wordfence installed, review firewall logs for blocked requests to /wp-json/batch/v1 or ?rest_route=/batch/v1.

Because the impact can include administrator creation and code execution, any suspected exploitation should be treated as a potential full site compromise. If you find anything suspicious, contact us or your web designer immediately.

What happens if I do nothing?

If your site stays unpatched, the realistic outcomes over the coming weeks are:

• Site defacement or malware installation – your homepage replaced, or malicious scripts injected into every page.
• Your site used to attack others – compromised sites are routinely used to send spam, host phishing pages, or launch attacks on other servers. Your domain’s reputation goes with it.
• Blacklisting by Google – once Google detects malware, your site is flagged in search results and browsers show a red warning screen to visitors. Getting removed from the blacklist takes days to weeks after cleanup.
• SEO damage – spam content and blacklisting can undo years of search ranking work.
• Customer data theft – if your site stores any personal data (contact forms, orders, accounts), a breach may be a notifiable incident under GDPR. That means reporting to the Data Protection Commission within 72 hours and potentially notifying affected customers. The reputational and regulatory cost of that dwarfs the cost of an update.

Updating takes minutes. Recovering from a compromise takes days, and the consequences can follow your business for months.

The bottom line

wp2shell is one of the most significant WordPress Core security events in recent years. The combination of unauthenticated reachability, no plugin or theme requirement, a massive global attack surface, a path to administrator access and code execution, and publicly available proof-of-concept code makes this vulnerability chain unusually serious.

The WordPress Security Team moved quickly to release patched versions, but public exploit activity began within hours. Patching remains the single most important step you can take.

If you have not already confirmed that your site is running a patched WordPress version, do that now.