WordPress wp2shell: SMB Website Patch Verification

If you run a WordPress website, there is a good chance you have already heard that "WordPress pushed an automatic fix" for the vulnerability the security community is calling wp2shell — and a good chance you assumed that meant your site was handled. That assumption is exactly the trap. WordPress.org did take the unusual step of force-pushing this patch through the auto-update system, but auto-updates fail silently for all sorts of ordinary reasons, and this is not a bug you want to be wrong about. It is a pre-authentication remote code execution chain that lets an anonymous attacker take over a stock WordPress install with no plugins and no login, and it is being actively exploited in the wild with public exploit code available.

On July 17, 2026, WordPress shipped emergency security releases across every supported branch to close the chain, tracked as CVE-2026-63030 and CVE-2026-60137. Four days later, on July 21, CISA added both to its Known Exploited Vulnerabilities catalog — the government's confirmation that attackers are using it right now. This article is a verification playbook for SMB leaders and website owners: how to confirm your core version actually updated (instead of assuming), check whether you were probed, preserve evidence if you find something, clean up correctly, and know when to bring in help. If your site is business-critical, this is also the kind of oversight that comes standard with professionally managed hosting.

One anonymous request to the REST API is all wp2shell needs — no login, no plugins, no user interaction.

What wp2shell Actually Does

The nickname "wp2shell" — WordPress to shell — describes the outcome plainly: an attacker turns a normal-looking web request into a command shell on your server. What makes it serious is that it works against a completely stock installation. There is no vulnerable plugin to blame, no risky configuration you enabled, and no user who has to click anything. If your version is affected and reachable from the internet, you are exposed.

Technically, wp2shell is a chain of two flaws that are far more dangerous together than apart:

The flaw was discovered by Adam Kues of Assetnote (the research arm of Searchlight Cyber) and responsibly disclosed through WordPress's HackerOne program. Since disclosure, full technical write-ups and multiple public proof-of-concept exploits have been released — which is precisely why the window between "patch available" and "mass exploitation" collapsed to days [Rapid7 / VulnCheck].

The chain: a batch-endpoint request bypasses permission checks, becomes a SQL injection, and ends as a planted shell.

Why "The Auto-Update Handled It" Is a Dangerous Assumption

WordPress force-pushing the patch was the right call, and it protected millions of sites automatically. But treating that as a guarantee for your site is a mistake, because background updates quietly fail to apply in a surprising number of real-world setups:

• Auto-updates were disabled — many hosts, security plugins, or wp-config.php settings turn off core auto-updates, sometimes without the owner realizing it.
• File-permission or ownership issues prevent the updater from writing new core files, so the update silently rolls back.
• Managed or "locked" hosting where the host controls core versions on its own schedule, which may lag the emergency release.
• Customized or version-pinned installs — sites held on a specific version for plugin or theme compatibility.
• Staging and clones — the production site updated, but a forgotten staging copy on the same server did not, and it is just as exploitable.

The only way to know is to look. Verification takes two minutes and removes all doubt.

Step 1: Verify Your WordPress Core Version

Check the exact version your site is running against the patched releases. You can confirm it several ways — use whichever you have access to:

• Admin dashboard: Log in and go to Dashboard → Updates, or read the version number in the lower-right corner of any admin page.
• WP-CLI (if you have server access): run wp core version for an unambiguous answer.
• External checker: the researchers published a safe exposure checker at wp2shell.com that tests your site from the outside.

# WP-CLI — the fastest authoritative check
wp core version

# You are protected if it reports 7.0.2, 6.9.5, or 6.8.6 (or newer)

Match your result against the branch table below. Note the important nuance: the 6.8 branch was only vulnerable to the SQL-injection half of the chain, so it received a fix (6.8.6) but never faced the full remote-code-execution risk that 6.9 and 7.0 did.

Step 2: Review WAF and Access Logs for Exploitation

Patching stops future attacks; it tells you nothing about the past. Because this chain has a distinctive entry point, your web server access logs and any web application firewall (WAF) logs are the best place to check whether someone already tried. The signature to hunt for is traffic to the batch endpoint and unusual REST API activity.

# Nginx / Apache — look for hits on the batch endpoint
grep "wp-json/batch/v1" /var/log/nginx/access.log
grep "wp-json/batch/v1" /var/log/apache2/access.log

# Widen to suspicious REST activity and the injected parameter
grep -Ei "wp-json|author__not_in" /var/log/nginx/access.log

When you review the results, treat these as red flags worth running down:

• POST requests to /wp-json/batch/v1, especially in bursts or from unfamiliar IP addresses — legitimate small sites rarely use this endpoint.
• REST requests containing author__not_in or other query-like parameters with encoded characters or SQL fragments.
• Requests to newly appeared PHP files in wp-content/uploads, wp-content/plugins, or the web root — a hallmark of a dropped webshell.
• Unexpected outbound connections from the web server, or admin logins and new users you cannot account for.

A properly tuned managed firewall or WAF can both block this pattern going forward and give you the log trail to investigate, and continuous network monitoring is what surfaces the outbound-callback half that a quiet webshell reveals.

Step 3: Preserve Evidence Before You Clean Up

A hands-on-keyboard attacker who reached command execution rarely stops at one file. Before remediating, capture the evidence that lets you scope the incident: the suspicious files and their timestamps, the web server access and error logs covering the relevant window, a copy of the database (attackers frequently add hidden administrator users), and a list of recently modified files. If you can, take the site offline or into maintenance mode while you investigate rather than leaving a potentially compromised site serving visitors.

# List PHP files changed in the last 30 days under wp-content
find wp-content/ -name "*.php" -mtime -30 -print

# Review the WordPress admin user list for accounts you don't recognize
wp user list --role=administrator

Step 4: Validate Plugins, Themes, and Users After Patching

Updating core closes the door, but anything an attacker installed while the door was open stays behind. Once you are on a patched version, verify the rest of the site is in the state you expect:

If the site handles customer data, payments, or logins, treat any confirmed compromise as a potential data exposure event with notification obligations — not just a cleanup task. That is a conversation to have with a cybersecurity consulting team, not something to quietly patch over.

When to Call Managed Hosting or Incident Response

Not every situation calls for outside help — but several clearly do. Bring in a managed host or incident-response partner if any of the following are true: you found a webshell or unknown admin user; you cannot get the core update to apply; your logs show successful (not just attempted) exploitation; the site handles sensitive data; or you simply do not have the time or in-house expertise to work through the steps above with confidence. The cost of an expert confirming you are clean is trivial next to the cost of a compromised site quietly serving malware or leaking data for weeks.

This entire episode is also a case for not running a business-critical WordPress site unmanaged in the first place. Professional website management and managed hosting mean that when the next core RCE lands, patch verification, log review, and evidence handling happen automatically — you get an email that it was handled, not a scramble to figure out whether you were exposed.

Sources

• WordPress.org — "WordPress 7.0.2 Release" (July 17, 2026)
• Rapid7 — "CVE-2026-63030 (wp2shell): A Critical RCE Vulnerability in WordPress Core"
• VulnCheck — "WP2Shell Vulnerabilities: CVE-2026-60137 and CVE-2026-63030"
• Aikido — "Unauthenticated RCE in WordPress core (wp2shell)"
• Help Net Security — "Two new high severity WordPress vulnerabilities, patch immediately!"