Wordpress WP2Shell WordPress Exploit Heads Up!

WordPress folks update your WordPress blogs ASAP as this WP2Shell security vulnerability can takeover your entire WordPress site!

Last updated: 31 July 2026

Immediate action required: Check every WordPress installation and update vulnerable sites to WordPress 6.8.6, 6.9.5, 7.0.2, or a newer patched release. Updating WordPress core is the primary fix.

On 17 July 2026, the WordPress Security Team released updates addressing two WordPress core vulnerabilities that can be chained into a critical pre-authentication site takeover commonly called WP2Shell.

Against affected WordPress 6.9 and 7.0 installations, an unauthenticated attacker may be able to:

• Bypass expected REST API request validation
• Reach a vulnerable WordPress database query
• Create a new WordPress administrator account
• Log in using the attacker-created administrator
• Upload a malicious plugin or theme
• Execute PHP code with the privileges of the site's PHP-FPM user

The full chain does not require a vulnerable third-party plugin or theme, an existing WordPress account, or user interaction.

Affected and patched WordPress versions

Code (Text):

WordPress branch   Vulnerable versions   Patched version   Exposure
----------------   -------------------   ---------------   ---------------------------
6.8                6.8.0 to 6.8.5       6.8.6             SQL injection vulnerability
6.9                6.9.0 to 6.9.4       6.9.5             Full WP2Shell chain
7.0                7.0.0 to 7.0.1       7.0.2             Full WP2Shell chain

WordPress versions earlier than 6.8 do not contain these particular vulnerabilities.

However, that does not make an old and unsupported WordPress branch safe. Older installations can contain unrelated vulnerabilities and should still be upgraded to a currently supported release.

Important distinction: WordPress 6.8.0 through 6.8.5 contains CVE-2026-60137, but it does not contain the REST batch-route confusion introduced in WordPress 6.9. The complete unauthenticated administrator-creation and RCE chain therefore affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1.

WordPress enabled forced automatic security updates because of the severity. Administrators should still verify that every installation updated successfully. Automatic updates can fail because of file permissions, disabled background updates, disk-space problems, version-control configurations, or other site-specific issues.

Official announcement:

WordPress 7.0.2 security release

The two vulnerabilities

CVE-2026-60137: WP_Query SQL injection

CVE-2026-60137 affects the handling of the following parameter in WP_Query:

Code:

author__not_in

WordPress did not properly sanitise certain non-array values passed to this parameter before constructing the database query.

The vulnerable code was introduced in WordPress 6.8 and is present in:

• WordPress 6.8.0 through 6.8.5
• WordPress 6.9.0 through 6.9.4
• WordPress 7.0.0 through 7.0.1

The injection occurs within a database SELECT query. It does not directly give the attacker a straightforward SQL INSERT capable of adding a WordPress user.

The complete exploit instead combines the SQL injection with WordPress application behaviour and the second vulnerability.

Advisory:

GHSA-fpp7-x2x2-2mjf and CVE-2026-60137

CVE-2026-63030: REST API batch-route confusion

CVE-2026-63030 affects the WordPress REST API batch processor, normally reached through routes such as:

Code:

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

The batch endpoint accepts multiple REST API subrequests inside one outer request.

Under specific error conditions, the arrays used to validate and later dispatch those subrequests can become misaligned. A subrequest can therefore be validated against one REST route but executed using a different route's callback.

This creates a route and validation confusion condition.

An attacker can use this confusion to pass malicious values to the vulnerable WP_Query operation without the validation and sanitisation that the intended REST route would normally apply.

CVE-2026-63030 affects:

• WordPress 6.9.0 through 6.9.4
• WordPress 7.0.0 through 7.0.1

Advisory:

GHSA-ff9f-jf42-662q and CVE-2026-63030

Spoiler: Technical overview of the WP2Shell chain

The SQL injection exists inside a SELECT context and is effectively read-only. The attacker does not simply inject an SQL statement that writes a new administrator directly into the WordPress database.

Instead, the published chain abuses several interacting WordPress behaviours, including:

• The REST API batch processor
• WP_Query and the author__not_in parameter
• Fabricated WP_Post data
• WordPress's per-request object cache
• oEmbed cache records
• Customizer changesets
• Post-parent cycle handling
• WordPress actions and REST request processing

At a high level, the attacker:

1. Sends a specially structured request to the REST API batch endpoint.
2. Uses the batch-route confusion to bypass the schema that would normally reject the malicious parameter type.
3. Reaches the vulnerable WP_Query author__not_in handling.
4. Uses the SQL injection to make WordPress construct attacker-controlled post-like objects.
5. Places those objects into WordPress's request-level object cache.
6. Causes other WordPress components to process the fabricated objects as legitimate oEmbed or customizer data.
7. Abuses this application state to have a privileged REST operation processed with administrator authority.
8. Creates a new administrator account.
9. Logs in using that account.
10. Uploads a plugin or theme containing PHP code.

The result is control over the WordPress site and code execution with access to whatever files, database credentials, API keys, sockets, and other resources are available to the site's PHP-FPM user.

The disclosed full RCE technique depends on WordPress's normal per-request object caching behaviour and has been described as applying when a persistent object cache is not active.

Centmin Mod users running Redis object caching must still update. Redis should not be treated as a reliable mitigation because:

• CVE-2026-60137 still exists in the affected WordPress version.
• The Redis object-cache plugin may be disabled or disconnected.
• Different sites on the same server may have different object-cache configurations.
• Plugins or themes may expose the affected WP_Query parameter through other paths.
• Public exploit techniques can evolve.

Technical research:

Searchlight Cyber WP2Shell technical analysis

Active exploitation and attack volume

This is not a theoretical vulnerability.

Patchstack reported that the WordPress fix appeared in the public source repository approximately 1.5 hours before WordPress 7.0.2 was tagged for release.

The first exploitation attempts reached Patchstack sensors approximately 90 minutes after WordPress 7.0.2 was released, about three hours after the fix became publicly visible in the source code.

In the following days, Patchstack blocked:

• More than 65,000 exploitation attempts
• Requests from more than 1,500 unique source IP addresses
• Attempts directed at sites running vulnerable WordPress versions

Patchstack reported that approximately 97 percent of its blocked attempts targeted the REST batch endpoint.

Patchstack analysis:

Ninety minutes: watching attackers weaponize the WordPress core RCE

Wordfence reported on 29 July 2026 that its premium firewall rule had blocked more than 11 million WP2Shell exploit attempts.

Wordfence observed:

• Initial probing on 17 July 2026
• Large-scale exploitation activity beginning on 18 July 2026
• Attackers chaining the vulnerabilities to create administrator accounts
• Attempts to create an administrator named wpenginebot

These figures represent blocked requests, not 11 million confirmed compromises.

Wordfence also reported that its incident-response teams had not observed a matching surge in compromised-site cases. Forced WordPress updates and coordinated WAF deployment probably reduced the number of installations that remained exploitable.

Wordfence analysis:

WP2Shell technical analysis and real attack data

CISA added both CVE-2026-60137 and CVE-2026-63030 to its Known Exploited Vulnerabilities catalogue on 21 July 2026. This confirms evidence of active exploitation.

CISA KEV searches:

CISA KEV entry for CVE-2026-60137

CISA KEV entry for CVE-2026-63030

What Centmin Mod users should do now

1. Locate every WordPress installation

Centmin Mod WordPress sites will normally be under:

Code:

/home/nginx/domains/DOMAIN/public

Locate WordPress configuration files:

Code (Text):

find /home/nginx/domains \
   -type f \
   -path '*/public/wp-config.php' \
   -print

Do not assume there is only one WordPress installation on the server. Check staging sites, old copies, development subdomains, disabled virtual hosts, and installations placed below additional directories.

2. Check every installed WordPress version

The following Bash loop displays the WordPress version for each installation found under the standard Centmin Mod directory structure:

Code (Text):

while IFS= read -r config; do
   path=${config%/wp-config.php}

   printf '%-70s ' "$path"

   wp \
       --path="$path" \
       core version \
       --allow-root 2>/dev/null ||
       echo "WP-CLI check failed"
done < <(
   find /home/nginx/domains \
       -type f \
       -path '*/public/wp-config.php'
)

Review every result.

Vulnerable versions include:

Code (Text):

6.8.0  6.8.1  6.8.2  6.8.3  6.8.4  6.8.5
6.9.0  6.9.1  6.9.2  6.9.3  6.9.4
7.0.0  7.0.1

3. Update and verify WordPress core

Replace yourdomain.com with the appropriate domain:

Code (Text):

cd /home/nginx/domains/yourdomain.com/public

wp core version --allow-root
wp core update --allow-root
wp core update-db --allow-root
wp core verify-checksums --allow-root

The site should be running at least:

• WordPress 6.8.6 on the 6.8 branch
• WordPress 6.9.5 on the 6.9 branch
• WordPress 7.0.2 on the 7.0 branch

A newer supported WordPress release containing the fixes is also acceptable.

A WAF, Redis object caching, restricted wp-admin access, disabled plugin installation, HTTP authentication, or an Nginx rule must not be treated as a replacement for updating WordPress core.

A successful update does not prove that the site was not compromised before the update. Continue with the account, plugin, file, and log checks below.

4. Verify WordPress core checksums

From the WordPress document root:

Code (Text):

wp core verify-checksums --allow-root

A successful result should report that the WordPress installation verifies against its checksums.

Investigate any modified, missing, or unexpected core files. Do not blindly delete a reported file without determining whether it is a legitimate local modification or evidence of compromise.

5. Review administrator accounts

List current WordPress administrators:

Code (Text):

wp user list \
   --role=administrator \
   --fields=ID,user_login,user_email,user_registered \
   --format=table \
   --allow-root

Investigate:

• Administrators you do not recognise
• Administrators created on or after 17 July 2026
• Unexpected changes to existing administrator email addresses
• Administrator accounts whose normal owner cannot explain their creation

One administrator account observed in active attacks was:

Code (Text):

Username: wpenginebot
Email:    wpenginebot@wpengine.com

The absence of this account does not prove that a site is clean. Attackers can select any username and email address and may delete the account after installing another persistence mechanism.

6. Review installed plugins

List installed plugins:

Code (Text):

wp plugin list \
   --fields=name,status,version,update \
   --format=table \
   --allow-root

Verify checksums for plugins distributed through WordPress.org:

Code (Text):

wp plugin verify-checksums \
   --all \
   --strict \
   --allow-root

Premium plugins, custom plugins, and plugins removed from the WordPress.org repository may not have public checksums. A checksum warning therefore requires investigation but is not automatically proof of compromise.

Look for:

• A recently installed plugin that no administrator recognises
• An unfamiliar plugin with an innocent-looking name
• A plugin directory containing unexpected PHP files
• An inactive plugin that appeared recently
• Unexpected changes to an existing trusted plugin

7. Review recently changed files

Run these commands from the WordPress document root.

Find PHP files created or modified under uploads and must-use plugins since the disclosure date:

Code (Text):

find wp-content/uploads wp-content/mu-plugins \
   -type f \
   -name '*.php' \
   -newermt '2026-07-17 00:00:00' \
   -ls 2>/dev/null

Review recently modified plugin PHP files:

Code (Text):

find wp-content/plugins \
   -type f \
   -name '*.php' \
   -newermt '2026-07-17 00:00:00' \
   -ls 2>/dev/null

Review recently modified theme PHP files:

Code (Text):

find wp-content/themes \
   -type f \
   -name '*.php' \
   -newermt '2026-07-17 00:00:00' \
   -ls 2>/dev/null

Review recently changed PHP files across the entire WordPress installation:

Code (Text):

find . \
   -type f \
   -name '*.php' \
   -newermt '2026-07-17 00:00:00' \
   -ls

Legitimate WordPress, plugin, and theme updates will also change files after 17 July.

Do not delete files solely because of their modification timestamp. Compare suspicious files with clean packages from trusted sources.

Pay particular attention to:

• PHP files under wp-content/uploads
• Unexpected files under wp-content/mu-plugins
• Randomly named PHP files
• Files containing long encoded or obfuscated strings
• Unexpected modifications to wp-config.php
• Unexpected changes to active theme files
• New PHP files in cache or temporary directories

Must-use plugins under wp-content/mu-plugins are especially important because they load automatically and do not appear in the normal WordPress Plugins screen.

8. Review WordPress scheduled events

List WordPress cron events:

Code (Text):

wp cron event list \
   --fields=hook,next_run_gmt,next_run_relative,recurrence \
   --format=table \
   --allow-root

Investigate unfamiliar scheduled hooks, especially those introduced recently or running unusually frequently.

Also review system cron locations and the crontab belonging to the site's operating-system user where applicable.

9. Search Centmin Mod Nginx access logs

The following search checks the usual Centmin Mod virtual-host access logs, including compressed rotations:

Code (Text):

zgrep -hEi \
'/wp-json/batch/v1|rest_route[^[:space:]]*batch(/|%2[fF])v1|author(_|\.|%5[fF]|[+ ])exclude|/wp/v2/(users|plugins)' \
/home/nginx/domains/*/log/access.log* 2>/dev/null

High-signal request indicators include:

• /wp-json/batch/v1
• ?rest_route=/batch/v1
• /index.php?rest_route=/batch/v1
• /wp/?rest_route=/batch/v1
• /blog/?rest_route=/batch/v1
• /wp-json?rest_route=/batch/v1
• A non-integer author_exclude value
• Variations such as author.exclude or author exclude
• Nested requests to /wp/v2/users
• A user-creation request assigning the administrator role
• Nested requests to /wp/v2/plugins

A log match proves that a suspicious request reached Nginx, but it does not by itself prove successful exploitation. Conversely, the absence of a match does not prove that the site was not attacked or compromised.

Important Nginx logging and mitigation limitation

Standard Nginx access logs record the request URI and query string but normally do not record the full POST request body.

Patchstack found that WordPress can accept the batch route in a form-encoded POST body sent to the site root:

Code (Text):

POST /
Content-Type: application/x-www-form-urlencoded

rest_route=/batch/v1

In that request form, the visible URL contains neither:

Code:

/wp-json/batch/v1

nor:

Code:

?rest_route=/batch/v1

This has several consequences:

• A standard Nginx access log may show only POST /.
• The malicious batch route may exist only in the unlogged request body.
• Blocking only the /wp-json/batch/v1 path is incomplete.
• Checking only the rest_route query-string argument is incomplete.
• URL-only WAF rules can be bypassed.
• Log searches based only on the request URI cannot provide complete assurance.

Patchstack reported observing body-based bypass attempts in live exploitation beginning around 17:00 UTC on 21 July 2026.

Do not publish or rely on a simple Nginx URL block as a complete WP2Shell fix. Updating WordPress core is necessary. Effective virtual patching must inspect the request body or disable unauthenticated batch API access within WordPress or an application-aware WAF.

Cloudflare WAF protection

Cloudflare deployed managed WAF rules for both vulnerabilities at 17:03 UTC on 17 July 2026.

Cloudflare states that protection applies to Free, Pro, Business, and Enterprise plans when the site's traffic is proxied through Cloudflare and processed by the relevant Cloudflare WAF ruleset.

The rules are:

Code (Text):

CVE-2026-60137
Description: Wordpress - SQL Injection - CVE:CVE-2026-60137

Managed Ruleset ID:
1c060d3a371549219ee290d7ed933fcc

Free Ruleset ID:
db003b39b7774859a8d588ce33697a1a


CVE-2026-63030
Description: Wordpress - Remote Code Execution - CVE:CVE-2026-63030

Managed Ruleset ID:
7dfb2bd4708d4b88b9911dc0550664b6

Free Ruleset ID:
ebd3f2df15c74ddcbf6220c9b5ec246a

The default action is Block.

Cloudflare Pro, Business, and Enterprise users should verify:

• The Cloudflare Managed Ruleset is enabled.
• The two rules have not been overridden to Log.
• The rules have not been disabled.
• No custom Skip rule bypasses the managed rules.
• Security Events show whether either rule has matched requests.

Cloudflare Free users receive the corresponding Free Managed Rules.

Cloudflare protection applies only to requests that pass through Cloudflare.

If the origin server accepts direct connections from the Internet, an attacker who discovers the origin IP address may bypass Cloudflare and connect directly to Nginx.

Cloudflare advisory:

Cloudflare WAF protects WordPress applications from the two vulnerabilities

Cloudflare and other WAF protections reduce exposure during the patching window. They are defence in depth, not replacements for the WordPress update.

Wordfence protection timing

Wordfence Premium, Wordfence Care, and Wordfence Response users received a firewall rule for WP2Shell on 17 July 2026.

As of this post's 30 July 2026 update, Wordfence Free users are scheduled to receive the same rule on:

Code:

16 August 2026

This is Wordfence's normal 30-day delayed firewall-rule release.

Wordfence Free users should not assume that installing the plugin currently provides the same WP2Shell virtual patch available to paid users.

All Wordfence users should update WordPress core regardless of firewall tier.

Observed indicators

Spoiler: Observed usernames, email addresses and source IP addresses

Wordfence observed attempts to create the following administrator:

Code (Text):

Username: wpenginebot
Email:    wpenginebot@wpengine.com

Wordfence's most active source addresses at the time of its 29 July report included:

Code (Text):

103.215.74.26
103.215.75.66
103.215.75.19
103.168.67.253
51.195.39.149
103.168.66.101
51.195.39.150
140.174.186.101
45.148.10.18
45.148.10.247

Patchstack separately observed full administrator-creation attempts from:

Code (Text):

129.121.77.134
91.202.233.61
125.164.233.50

These are historical indicators, not a complete block list.

Attackers can:

• Change IP addresses
• Use compromised servers
• Use residential proxies
• Choose different usernames and email addresses
• Remove the administrator account after establishing persistence
• Obfuscate request parameters

Do not use the absence of these exact indicators as proof that a site is clean.

If compromise is suspected

Because successful exploitation can create an administrator account and lead to arbitrary PHP execution, treat credible evidence of exploitation as a possible complete WordPress-site compromise.

Recommended response:

1. Restrict public access to the affected site.
2. Do not immediately destroy logs or suspicious files.
3. Preserve Nginx access and error logs.
4. Preserve PHP-FPM, system, audit, firewall, and WordPress security logs.
5. Take a filesystem snapshot or forensic copy.
6. Export or snapshot the WordPress database.
7. Record current processes, network connections, users, cron jobs, and file timestamps.
8. Identify and disable unknown WordPress administrator accounts.
9. Replace WordPress core with a verified clean copy.
10. Reinstall plugins and themes from trusted packages.
11. Inspect wp-content/uploads, plugins, mu-plugins, themes, and cache directories for backdoors.
12. Review system cron jobs and WordPress scheduled events.
13. Rotate all WordPress administrator passwords.
14. Regenerate the WordPress authentication salts in wp-config.php.
15. Rotate the WordPress database password.
16. Rotate API keys, SMTP credentials, cloud credentials, payment credentials, and other secrets readable by PHP.
17. Review other sites accessible to the same PHP-FPM or operating-system user.
18. Continue monitoring after restoration.

Simply updating WordPress does not remove an administrator account, malicious plugin, webshell, cron job, or other persistence installed before the update.

Where practical, restoration from a known-clean backup followed by immediate updating and credential rotation can be safer than attempting to clean a heavily compromised installation in place.

Summary

WP2Shell is especially serious because the complete chain affects WordPress core and does not depend on a vulnerable third-party plugin or theme.

The key points are:

• CVE-2026-60137 affects WordPress 6.8.0 through 6.8.5, 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1.
• CVE-2026-63030 affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1.
• The two flaws can be chained on affected WordPress 6.9 and 7.0 installations.
• The full chain can create an administrator and lead to PHP code execution.
• Live exploitation started approximately 90 minutes after release of the patch.
• CISA has added both vulnerabilities to its Known Exploited Vulnerabilities catalogue.
• URL-only Nginx and WAF rules can miss body-based routing variants.
• WordPress core must be updated even when Redis, Cloudflare, or Wordfence is present.

Patch WordPress core first. Use Redis, Cloudflare, Wordfence, Nginx restrictions, and other security controls only as additional layers of defence.

References

• WordPress 7.0.2 security release
• WordPress advisory for CVE-2026-60137
• WordPress advisory for CVE-2026-63030
• Searchlight Cyber initial WP2Shell advisory
• Searchlight Cyber technical analysis
• Patchstack exploitation and WAF-bypass analysis
• Wordfence attack data and indicators
• Cloudflare WAF rules and guidance
• NVD entry for CVE-2026-60137
• NVD entry for CVE-2026-63030
• CISA KEV search for CVE-2026-60137
• CISA KEV search for CVE-2026-63030
• Elastic Security Labs WP2Shell detection guidance
• Bitdefender WP2Shell technical advisory

---

 

Quick Centmin Mod checklist

• Check: Locate every wp-config.php under /home/nginx/domains.
• Verify: Record the WordPress version for every installation.
• Patch: Update to 6.8.6, 6.9.5, 7.0.2, or newer.
• Validate: Run WordPress core checksum verification.
• Users: Review all administrator accounts.
• Plugins: Review installed plugins and verify available checksums.
• Files: Investigate recently modified PHP files.
• Persistence: Check mu-plugins, WordPress cron, and system cron.
• Logs: Search for batch routes, author_exclude, user creation, and plugin operations.
• Cloudflare: Confirm the relevant WAF rules are blocking.
• Origin: Ensure attackers cannot bypass Cloudflare by reaching the origin directly.
• Respond: Treat evidence of successful exploitation as a possible complete compromise.