WP2Shell WordPress Vulnerability: What to Check

A serious WordPress security vulnerability known as WP2Shell has placed many recently updated WordPress websites at risk.

The vulnerability affects WordPress itself rather than a particular plugin or theme. On affected versions, an attacker may be able to exploit a normal WordPress installation without logging in first.

WordPress has released security updates to close the vulnerability. Website owners should update immediately, but installing the update is only the first step.

If a website was exposed before it was patched, updating WordPress does not prove that the site was not already accessed or changed.

Read below and if you need help

Contact me today

What is the WP2Shell vulnerability?

WP2Shell is the name given to a chain of two WordPress core vulnerabilities:

CVE-2026-60137
CVE-2026-63030

Together, the vulnerabilities can allow what security professionals call pre-authentication remote code execution.

In plain English, this means an attacker may be able to run malicious code on an affected WordPress website without needing a username or password.

This is particularly serious because the weakness is in WordPress core. A website does not need to have a specific vulnerable plugin or theme installed to be exposed.

The vulnerability was publicly disclosed on 17 July 2026. WordPress released emergency security updates and enabled forced automatic updates for affected installations because of the severity of the issue.

Which WordPress versions are affected?

The complete WP2Shell remote code execution chain affects:

WordPress 6.9.0 to 6.9.4
WordPress 7.0.0 to 7.0.1

The fixed versions are:

WordPress 6.9.5
WordPress 7.0.2

WordPress 6.8.0 to 6.8.5 is affected by the related SQL injection vulnerability, although it is not affected by the complete WP2Shell remote code execution chain. The fix for the 6.8 branch is WordPress 6.8.6.

Versions of WordPress released before 6.8 are not affected by these two particular vulnerabilities. This does not mean that an older WordPress installation is safe generally, as older versions may contain other known security problems.

How do I check my WordPress version?

Dashboard → Updates

The installed WordPress version may also be shown on the main Dashboard screen.

Depending on the branch your website uses, it should be running at least:

6.8.6
6.9.5
7.0.2

Do not assume that the automatic update completed successfully. Updates can fail because of file permissions, hosting restrictions, interrupted processes or changes previously made to WordPress files.

Check the installed version directly.

You should also confirm that the public website still works correctly after the update. Test important pages, contact forms, menus and any other functions used by customers.

Is updating WordPress enough?

Updating WordPress closes the known vulnerability, but it cannot tell you what happened before the update was installed.

A website that is now running a fixed version may previously have been publicly accessible while running a vulnerable version.

That does not mean every affected website was compromised. It does mean that website owners should not treat the version update as proof that the installation is clean.

Security researchers have reported active exploitation of WP2Shell. Observed activity has included attackers uploading malicious plugins, accessing WordPress administration areas and placing persistent webshells on compromised servers.

A webshell is a malicious file that gives an attacker continued access to the website or hosting account. Once installed, it may continue working even after WordPress has been updated.

Signs that a website may have been compromised

WP2Shell exploitation may not cause an immediate visible problem. A website can continue appearing normal while an attacker retains access in the background.

The following warning signs should be investigated.

Unknown WordPress administrators

Review every account with the Administrator role.

An unfamiliar administrator account is a serious warning sign. Check when the account was created, which email address it uses and whether anyone responsible for the website recognises it.

Do not simply delete a suspicious account and assume the problem has been resolved. The account may be only one part of a wider compromise.

Unrecognised plugins

Check the complete list of installed plugins, including inactive plugins.

Look for:

Plugins nobody remembers installing
Plugins added around the time the vulnerability was disclosed
Unusual or misleading plugin names
Plugins containing only one or two PHP files
Previously deleted plugins that have returned

Attackers have been observed using malicious plugins to establish persistent access after exploiting WP2Shell.

Unexpected file changes

WordPress core files, themes, plugins and the uploads directory should be checked for unexplained PHP files or recent modifications.

A changed file is not automatically malicious. WordPress updates, plugin updates and legitimate website work also modify files.

The important question is whether each change can be explained.

Comparing WordPress core files against the official release can help identify alterations. Plugin and theme files may also need to be compared with known clean copies.

Suspicious server requests

Where suitable server or firewall logs are available, look for requests involving:

/wp-json/batch/v1
?rest_route=/batch/v1

The presence of a request does not prove that an attack succeeded. Security scanners, monitoring systems and unsuccessful probes may also access an endpoint.

However, unusual requests to the WordPress batch API around the period of exposure should form part of the investigation. Researchers have identified successful exploitation and scanning activity involving these routes.

Unexpected redirects or spam pages

A compromised website may redirect visitors to unfamiliar websites or begin displaying unwanted advertisements, pharmaceutical content, gambling pages or other spam.

Strange pages may also appear in Google even when they are not visible through the website’s normal navigation.

These are common signs of a wider WordPress compromise, although they are not unique to WP2Shell.

Browser or search-engine warnings

Google, web browsers, hosting companies and security services may display warnings when malicious files or suspicious behaviour are detected.

Treat these warnings seriously. Removing the visible warning without finding and correcting the underlying cause can allow the problem to return.

Unexplained hosting activity

Other possible warning signs include:

Unusual increases in server usage
Unexpected outgoing email
Files returning after they are deleted
New scheduled tasks
Changes to .htaccess or configuration files
Website backups becoming unexpectedly large
Hosting abuse notifications

None of these signs proves WP2Shell was used, but each one justifies further investigation.

Can an online scanner confirm that my website is safe?

An external scanner may help identify whether a website is currently exposing a vulnerable WordPress version or displaying known signs of malware.

It cannot usually inspect every file, administrator account, database record, server log or hidden persistence mechanism.

A result saying that the website is no longer vulnerable normally means that the tested vulnerability appears to have been patched. It does not necessarily prove that the website was never compromised.

A proper review may require access to:

The WordPress administration area
Website files
The database
Hosting logs
Firewall records
Previous backups
The website’s update history

No single automated scan should be treated as a complete forensic investigation.

What should I do if my website used an affected version?

First, confirm that WordPress has been updated to a fixed release.

Next, establish approximately when the update happened and how long the website may have been running an affected version.

The website should then be reviewed for unexpected changes, including:

Administrator accounts
Installed and recently changed plugins
WordPress core integrity
Theme and plugin files
PHP files in unusual locations
Relevant server and firewall logs
Recent database changes
Scheduled tasks and configuration changes

Preserve useful evidence before deleting suspicious files or accounts. Immediate deletion can remove information that helps identify what happened and whether another access method remains.

If compromise is confirmed, the response may also require:

Removing malicious files and code
Replacing altered WordPress files with clean copies
Removing unauthorised users and plugins
Changing administrator and hosting passwords
Resetting WordPress security keys
Reviewing database users and hosting access
Restoring from a verified clean backup where appropriate
Updating all remaining software
Monitoring the website for further changes

The exact response depends on what is found. Restoring a backup is not always enough if the backup already contains the infection or the original security weakness remains open.

Should I block the WordPress REST API?

Blocking anonymous access to the affected batch API was suggested as a temporary emergency measure for websites that could not update immediately.

It should not replace the official WordPress update.

Broadly disabling the REST API can also interfere with legitimate WordPress features, plugins and integrations. Changes of this type should therefore be tested carefully and removed when they are no longer required.

The permanent fix is to install the appropriate patched WordPress release.

What if my website appears to be working normally?

A normal-looking website is reassuring, but it does not rule out compromise.

Attackers often try to avoid obvious damage because hidden access is more valuable when the website owner does not know it exists.

The decision to investigate should be based on the version history and period of exposure, not only on whether the homepage still loads.

At minimum, confirm the current WordPress version and review administrator accounts and installed plugins. Websites known to have been publicly accessible on WordPress 6.9.0–6.9.4 or 7.0.0–7.0.1 should receive a more detailed review.

The important difference between patched and clean

A patched website is running software that closes the known vulnerability.

A clean website has also been checked for unauthorised changes, malicious files and continued attacker access.

After a serious vulnerability such as WP2Shell, website owners need to understand that these are not automatically the same thing.

Updating WordPress is essential. Checking what may have happened before the update provides the additional confidence that the website is safe to continue using.

Need Help.