WordPress RCE Vulnerability (wp2shell): How to Check and Secure Your Site

WordPress released an urgent security update on July 17, 2026, to patch a critical remote code execution vulnerability affecting recent versions of WordPress core.

The vulnerability chain, commonly called wp2shell, can allow an unauthenticated attacker to execute code on a vulnerable WordPress website. It does not depend on a malicious plugin, a compromised administrator account, or a visitor clicking a link.

WordPress enabled forced automatic updates because of the severity of the issue. On July 21, the US Cybersecurity and Infrastructure Security Agency added both vulnerabilities involved in the attack chain to its Known Exploited Vulnerabilities catalog, confirming that attackers are using them against real websites.

If you manage a self-hosted WordPress website, check its version now—even if automatic updates are enabled.

The Quick Answer

Your site needs immediate attention if it runs one of these WordPress versions:

Installed WordPress version	Risk	Required update
7.0.0–7.0.1	Affected by the wp2shell RCE chain	Update to 7.0.2 or newer
6.9.0–6.9.4	Affected by the wp2shell RCE chain	Update to 6.9.5 or newer
6.8.0–6.8.5	Affected by the related SQL injection issue	Update to 6.8.6 or newer
Earlier than 6.8	Not affected by these two specific CVEs	Upgrade to a currently maintained release

The safest option is to update to the latest stable WordPress release available for your website. WordPress officially recommends updating affected sites immediately.

What Is the wp2shell WordPress Vulnerability?

wp2shell is not a single programming error. It is an attack chain made possible by two vulnerabilities in WordPress core.

CVE-2026-60137: SQL injection

The first vulnerability affects how WordPress processes the author__not_in parameter in WP_Query.

An SQL injection vulnerability can allow specially prepared input to alter a database query. This flaw affects WordPress 6.8.0 through 6.8.5, WordPress 6.9.0 through 6.9.4, and WordPress 7.0.0 through 7.0.1.

CVE-2026-63030: REST API route confusion

The second vulnerability affects WordPress’s REST API batch endpoint. Under certain conditions, WordPress can confuse which route a request should be processed against.

On WordPress 6.9 and 7.0, attackers can combine this route-confusion weakness with the SQL injection vulnerability to achieve remote code execution. The official advisory classifies CVE-2026-63030 as critical.

In simpler terms, the two bugs work together:

One bug causes WordPress to process part of a request incorrectly.
The second bug allows the attacker to interfere with a database query.
Together, they can allow commands or malicious code to run on the server.

Searchlight Cyber, whose researcher discovered the RCE chain, reported that it could be exploited by an anonymous visitor on a standard WordPress installation with no plugins installed.

Why Is Remote Code Execution So Serious?

Remote code execution, usually shortened to RCE, is one of the most dangerous classes of website vulnerability.

If an attacker successfully exploits an RCE flaw, they may be able to:

Add a hidden administrator account
Modify WordPress, plugin, or theme files
Install malware or a persistent backdoor
Redirect visitors to scam or malware pages
Access information stored in wp-config.php
Steal database or service credentials
Use the server to send spam or attack other systems
Change or delete website content

The exact damage depends on the server configuration and the permissions available to the web server. However, an attacker does not need complete control of the hosting account to cause significant damage.

This is also a WordPress core vulnerability. Installing fewer plugins does not protect a vulnerable WordPress 6.9 or 7.0 site from this particular attack chain.

How to Check Your WordPress Version

Dashboard → Updates

Your installed WordPress version and any available core updates will appear on this screen.

You can also find the version under:

Dashboard → At a Glance

Administrators with SSH and WP-CLI access can check from the WordPress installation directory:

wp core version

Do not rely entirely on an earlier automatic-update email. Open the website and confirm the installed version directly.

What about WordPress.com websites?

WordPress.com manages WordPress core updates automatically. Sites hosted directly on WordPress.com normally run the latest stable WordPress version without requiring the site owner to install core updates manually.

The urgent manual checks in this guide mainly apply to self-hosted WordPress installations, including websites hosted through independent hosting providers.

How to Update WordPress Safely

WordPress recommends backing up your files and database before beginning an update. A backup gives you a recovery point if the update exposes an unrelated plugin, theme, or server compatibility problem.

Step 1: Create a backup

Back up both parts of the website:

The WordPress database
WordPress files, including wp-content, themes, plugins, and uploads

Confirm that the backup has completed successfully. Having a backup job configured is not the same as knowing that a usable backup exists.

Step 2: Install the WordPress security update

Open:

Dashboard → Updates

Click Update Now under the WordPress core update.

For the wp2shell RCE chain, the minimum patched releases are:

WordPress 7.0.2
WordPress 6.9.5

WordPress 6.8 users should install at least version 6.8.6 to patch CVE-2026-60137, even though that branch is not affected by the complete RCE chain.

With WP-CLI, you can update WordPress core using:

wp core update

wp core update-db

wp core version

The final command should report a patched or newer release.

Step 3: Clear caches

After the update, clear any caches that sit between visitors and WordPress:

WordPress caching plugins
Hosting-provider cache
Reverse-proxy cache
CDN or edge cache
Object cache, where applicable

A cache does not normally change the installed WordPress version, but clearing it prevents old responses or assets from making the post-update website appear broken.

Step 4: Test the website

Check the parts of the site that matter to your publishing and business workflow:

Homepage and important landing pages
WordPress administration area
Post and page editor
Contact and registration forms
Search
Login and logout
Checkout or membership functionality
Scheduled publishing
REST API integrations
TenWrite connection and publishing

A WordPress security update should not normally change your posts or disconnect integrations. Testing still helps catch an unrelated theme, plugin, or caching issue before visitors encounter it.

What If You Cannot Update Immediately?

Updating WordPress is the proper fix.

As an emergency temporary measure, Searchlight Cyber recommends blocking anonymous access to the affected REST API batch endpoint:

/wp-json/batch/v1

You should also block the alternative query-string form:

?rest_route=/batch/v1

These paths can be blocked through a web application firewall, CDN firewall, reverse proxy, or web-server configuration.

However, this is only a temporary measure. Blocking parts of the REST API may interfere with legitimate website functionality, plugins, editors, or external integrations. Remove the temporary restriction after WordPress has been updated and tested.

Do not delay the real update merely because a firewall rule has been added.

What If the Website Was Already Compromised?

Installing the patch closes the known vulnerability. It does not automatically remove malicious files, accounts, scheduled tasks, or backdoors that an attacker may already have created.

If your site ran an affected version after the vulnerability became public, or you notice unusual behaviour, treat the website as potentially compromised.

Warning signs can include:

An administrator account you do not recognise
New or modified plugins
Unexpected files inside wp-content/uploads
Search results showing spam pages
Redirects that only appear for some visitors
Unexplained scheduled tasks
Sudden increases in outgoing email
Modified .htaccess, index.php, theme, or plugin files
Security alerts from your host, CDN, or search engine
Unusual requests to the WordPress batch REST API in access logs

Recommended response

First, document what you observed and when. Preserve server, CDN, WAF, authentication, and WordPress logs where possible.

Then:

Update WordPress to a patched version.
Review every administrator and privileged user.
Reset WordPress administrator passwords.
Rotate hosting, SSH, SFTP, database, and control-panel credentials.
Revoke and recreate WordPress Application Passwords.
Replace the WordPress security keys and salts in wp-config.php to terminate existing sessions.
Scan the site and server for malicious files.
Review plugins, themes, must-use plugins, uploads, cron jobs, and server configuration.
Restore from a verified clean backup when appropriate.
Ask your hosting provider or a WordPress security professional to investigate if the scope is unclear.

WordPress’s hacked-site documentation recommends documenting the incident, scanning the website, checking with the host, resetting all access points, replacing security keys, inspecting modified files, and updating the installation after cleanup.

Administrators with WP-CLI can also compare WordPress core files against official checksums:

wp core verify-checksums

This identifies modified or unexpected WordPress core files. It does not inspect every plugin, theme, upload, database record, or server-level file, so a successful checksum verification is useful but not proof that the entire site is clean.

What TenWrite Users Should Do

TenWrite publishes to self-hosted WordPress using WordPress Application Passwords and connects to WordPress.com using OAuth. It does not require a separate WordPress publishing plugin.

The wp2shell patch must therefore be installed on the WordPress website itself. Updating TenWrite or republishing a post cannot patch an outdated WordPress installation.

For a normal update:

Update WordPress.
Confirm that the site loads correctly.
Open TenWrite and run a test export or update a draft.
Confirm that images, metadata, and post content arrive correctly.

Your existing TenWrite connection should normally continue working after a routine WordPress core update.

If you believe the site was compromised, revoke its existing Application Passwords along with the other credentials being rotated. After the website has been cleaned, reconnect it to TenWrite and perform a test export before resuming automated publishing.

Teams and agencies should repeat this check for every connected self-hosted WordPress site. Updating one website does not protect another installation hosted elsewhere.

How to Reduce the Risk of the Next WordPress Vulnerability

No WordPress website can be guaranteed never to have another vulnerability. The goal is to reduce the time between a security release and installation of the patch.

A practical maintenance process should include:

Automatic WordPress core security updates
Notifications when an automatic update fails
Regular, tested off-site backups
Updates for active plugins and themes
Removal of unused plugins and themes
Two-factor authentication for administrators
Unique credentials stored in a password manager
Restricted administrator access
File-change and login monitoring
A CDN or host-level web application firewall
A list of every WordPress site your team manages
A documented incident-response and recovery process

WordPress’s security documentation identifies keeping WordPress, plugins, and themes updated as the most important basic security measure. It also recommends strong passwords, two-factor authentication, backups, restricted file permissions, HTTPS, and limiting unnecessary access.

For teams managing several publishing destinations, site inventory matters as much as the update mechanism. You cannot patch a forgotten staging site, old campaign website, or client installation that nobody remembers is still online.

Frequently Asked Questions

Is wp2shell a plugin vulnerability?

No. The two vulnerabilities are in WordPress core. A default installation without third-party plugins can be affected if it runs a vulnerable WordPress 6.9 or 7.0 release.

Does an attacker need a WordPress account?

No. Searchlight Cyber described the complete RCE chain as pre-authentication and exploitable by an anonymous user on a stock WordPress installation.

Which CVEs are involved?

The attack chain involves:

CVE-2026-63030: REST API batch-route confusion
CVE-2026-60137: SQL injection involving WP_Query

On WordPress 6.9 and newer affected releases, the two issues can be combined to achieve remote code execution.

Is WordPress 6.8 affected by the RCE?

WordPress 6.8 is affected by CVE-2026-60137, the SQL injection vulnerability, but not the complete wp2shell RCE chain described for WordPress 6.9 and 7.0. WordPress 6.8 users should still update to version 6.8.6 or newer immediately.

Are older WordPress versions safe?

Versions before WordPress 6.8 are not affected by these two specific vulnerabilities according to the release advisory. That does not make an old WordPress release safe. Older versions may contain other publicly known vulnerabilities and may no longer receive security maintenance. WordPress recommends running the latest supported version.

Will automatic updates protect my site?

WordPress enabled forced automatic updates for affected versions because of the severity of the release. However, updates can fail because of disabled background updates, file permissions, hosting restrictions, disk-space problems, or site configuration. Verify the installed version directly rather than assuming the update completed.

Does installing WordPress 7.0.2 remove malware?

No. The update fixes the vulnerable WordPress code. If an attacker accessed the site before the update, any accounts, files, scheduled tasks, or backdoors they created must be investigated and removed separately.

Do I need to disconnect TenWrite before updating?

A routine WordPress core security update should not require you to disconnect TenWrite. Update WordPress, test the website, and then run a test export.

Revoke and recreate the WordPress Application Password used by TenWrite only when you suspect compromise or are rotating credentials as part of an incident response.

Update First, Investigate Second

The immediate action is straightforward: check your WordPress version and install the patched release.

If you use WordPress 7.0, update to 7.0.2 or newer. If you remain on the 6.9 branch, install 6.9.5 or newer. WordPress 6.8 users should install at least 6.8.6.

After updating, confirm that the website and its publishing integrations still work. If the site may have been exposed, do not stop at patching—review access, rotate credentials, inspect files and logs, and involve your hosting provider or a security professional where necessary.

Security updates are less disruptive than recovering a compromised website. Make WordPress core updates part of the publishing workflow, not an occasional maintenance task.