# How to check and fix wp2shell in WordPress <em>(CVE-2026-60137 and CVE-2026-63030)</em>

> Affected WordPress versions, reliable compromise indicators, a safe cleanup sequence, and the new Respira 8.1 scanner that can generate, implement, and verify a site-specific fixing path.

Source: https://www.respira.press/blog/fix-wp2shell-wordpress-cve-2026

---

If your WordPress site is already on 7.0.2, 6.9.5, or 6.8.6, the known hole may be closed. That is not the same as proving nobody came through it before the update.

**Since this was written:** WordPress shipped three more core security releases, on 6 August, 12 August and 17 September 2026\. Each patch sits one release above the last, so a site patched for wp2shell is several releases short today. The current one is [Click2Shell and the 17 September release](https://www.respira.press/blog/click2shell-wordpress-7-1-1-security-release), which carries the branch table for every version back to 4.7\. To check a site, or a fleet, against all of them at once, use the [WordPress vulnerability scanner](https://www.respira.press/wordpress-vulnerability-scanner). 

WordPress published an urgent security release on July 17, 2026 for two core vulnerabilities now commonly called **wp2shell**. One is a facilitated SQL injection tracked as [CVE-2026-60137](https://github.com/advisories/GHSA-fpp7-x2x2-2mjf). The other is a REST API batch-route confusion issue tracked as [CVE-2026-63030](https://github.com/advisories/GHSA-ff9f-jf42-662q). On affected WordPress 6.9 and 7.0 releases, the two can form an unauthenticated remote-code-execution chain. 

The immediate instruction is uncomplicated: [**update WordPress now**](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/). The investigation after that needs more care. 

## Affected and patched WordPress versions

| Branch | Affected | First patched release | What applies |
| --- | --- | --- | --- |
| 6.8 | Before 6.8.6 | **6.8.6** | CVE-2026-60137 only |
| 6.9 | 6.9–6.9.4 | **6.9.5** | Complete reported chain |
| 7.0 | 7.0–7.0.1 | **7.0.2** | Complete reported chain |
| 7.1 beta | beta1 | **beta2** | Complete reported chain; prereleases do not belong in production |

WordPress enabled forced background updates because of the severity. Check anyway: filesystem permissions, disabled file modifications, hosting policy, or a failed update can leave a site behind. The [WordPress release archive](https://wordpress.org/download/releases/) confirms the current patched releases. 

## How to check whether wp2shell affected your site

A trustworthy check separates three questions:

1. **Is the installed version vulnerable now?**
2. **Are there current indicators that need investigation?**
3. **Could the site have been exposed before it was patched?**

Start with the unfiltered WordPress core version and official core checksums. A changed, unexpected, or symlinked file under `wp-admin` or `wp-includes` is meaningful integrity evidence. Missing files may indicate a broken update, but they do not prove compromise by themselves. User-managed files under `wp-content` must not be treated as WordPress core checksum failures. 

Then inspect administrator accounts, normal and must-use plugins, WordPress cron hooks, PHP executables in uploads and cache directories, and the database artifacts relevant to the public exploit. Exact markers deserve more weight than coincidence. An unfamiliar administrator requires owner confirmation; a PHP file inside a builder-generated template cache is an observation, not automatic malware. 

## A safe wp2shell fixing path

1. **Preserve evidence and confirm a recoverable backup.** If compromise is likely, restoring a known-clean pre-exposure backup is safer than guessing which files were touched.
2. **Patch the current WordPress branch.** Use 6.8.6, 6.9.5, 7.0.2, or a newer supported release. Do not turn a security patch into an unplanned major-version migration.
3. **Verify official core checksums.** Distinguish changed, missing, unexpected and symlinked files.
4. **Confirm every administrator.** Do not infer legitimacy or malice from a username or registration date.
5. **Review plugins, mu-plugins, cron, uploads, cache and relevant database objects.** Remove only confirmed artifacts, with separate approval and a receipt.
6. **Re-scan after remediation.** “The command completed” is not verification.
7. **Finish at the host.** Inspect access logs and host cron, revoke old sessions, rotate salts and credentials, enable 2FA, and monitor for reinjection. Coordinate database-password changes with `wp-config.php` or the site will go offline.

## Respira 8.1 turns the checklist into evidence

The new [Safety & Security center](https://www.respira.press/dashboard/security) scans every connected WordPress site from one dashboard. It deterministically matches a reviewed advisory catalog, stores a site-bound receipt, and labels each result as vulnerable, possible compromise, patched but investigation required, not affected, or unknown. 

For wp2shell, Respira checks authoritative versions, official WordPress checksums, administrators, plugins and mu-plugins, cron, bounded executable paths, selected database artifacts, session and supported 2FA signals, security configuration, and whether the database account exposes the global `FILE` capability. Paths are locked, symlinks rejected, scans capped, and partial coverage is stated plainly. 

Respira then creates a fixing prompt containing the exact advisory, site evidence, official sources, approval boundaries and host-only work. A connected assistant can **implement supported fixes through the Respira plugin and MCP**. Core and plugin updates still require explicit approval; user, plugin, file and database deletion is never automatic. After the work, the same audit runs again and links the before-and-after receipts. 

[**Try the scanner free for seven days →**](https://www.respira.press/signup)

## What the scanner deliberately cannot claim

A clean WordPress-level scan cannot prove a clean server. Hosting-panel cron, access logs, external backups, database administration and secrets outside WordPress require connected host evidence or human verification. [Wordfence has documented why a WordPress-clean result can miss persistence outside the webroot](https://www.wordfence.com/blog/2026/05/how-a-webmail-log-file-became-a-root-level-backdoor/). Respira shows those boundaries instead of collapsing them into a green badge. 

## Independent reporting and official references

- [WordPress.org: WordPress 7.0.2 security release](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)
- [GitHub Advisory: CVE-2026-60137](https://github.com/advisories/GHSA-fpp7-x2x2-2mjf)
- [GitHub Advisory: CVE-2026-63030](https://github.com/advisories/GHSA-ff9f-jf42-662q)
- [Japan IPA security alert for wp2shell](https://www.ipa.go.jp/security/security-alert/2026/alert20260722.html)
- [NHS England cyber alert: exploitation of the wp2shell chain](https://digital.nhs.uk/cyber-alerts/2026/cc-4815)
- [SecurityWeek: wp2shell exploitation reporting](https://www.securityweek.com/wp2shell-wordpress-vulnerabilities-exploited-in-the-wild/)
- [Bitdefender technical advisory](https://businessinsights.bitdefender.com/technical-advisory-wp2shell-unauthenticated-remote-code-execution-full-site-takeover-wordpress-core)
- [WooCommerce: Store API vulnerability advisory](https://developer.woocommerce.com/2026/03/02/store-api-vulnerability-patched-in-woocommerce-5-4/)

## Frequently asked questions

### Which WordPress versions are vulnerable to wp2shell?

WordPress 6.9 before 6.9.5 and WordPress 7.0 before 7.0.2 are affected by the complete unauthenticated RCE chain. WordPress 6.8 before 6.8.6 is affected by CVE-2026-60137 but not the complete chain. WordPress 7.1 beta1 is affected; beta2 is the first patched 7.1 prerelease.

### Does updating WordPress prove that a site was not compromised?

No. Updating closes the known vulnerability, but current version evidence cannot prove the site was not exposed before the update. Review checksums, administrators, plugins, executable files, cron, relevant database artifacts, and host logs.

### Can Respira fix wp2shell automatically?

Respira can identify reviewed evidence, create a site-specific remediation prompt, and implement supported WordPress changes through a connected assistant. Updates and destructive actions still require explicit approval, and a second scan verifies the result.

### Should I run SQL DELETE commands from a cleanup guide?

Not without previewing and confirming every row. Broad deletion can destroy legitimate WordPress content and metadata. Restore from a known-clean backup when compromise is likely, or remove only confirmed artifacts with a backup and an audit receipt.

Security work is most useful when every conclusion names its evidence, every change waits for approval, and “fixed” means the next scan proved something different. 

breathe easy,  
mihai

[#wp2shell](https://www.respira.press/blog?q=wp2shell)[#wordpress-security](https://www.respira.press/blog?q=wordpress-security)[#CVE-2026-60137](https://www.respira.press/blog?q=CVE-2026-60137)[#CVE-2026-63030](https://www.respira.press/blog?q=CVE-2026-63030)[#Respira-8.1](https://www.respira.press/blog?q=Respira-8.1) 

Found this useful? Share it. 

## Join the *conversation*

0 comments · Respira account 

#### Sign in with your Respira account

Comments are tied to your Respira login, the same account you use for the dashboard and plugin. No third-party sign-in, no scraping.

[Sign in](https://www.respira.press/login?next=https%3A%2F%2Fwww.respira.press%2Fblog%2Ffix-wp2shell-wordpress-cve-2026%23comments) [Create an account](https://www.respira.press/signup?next=https%3A%2F%2Fwww.respira.press%2Fblog%2Ffix-wp2shell-wordpress-cve-2026%23comments) 

No comments yet. Be the first to weigh in. 

### You're not the only one *talking* to WordPress.

The Respira community is where agency owners debug Divi migrations at 11pm, where vibe coders swap prompts that actually ship, and where the roadmap gets written out loud. *Breathe with us.*

Lines of code pushed 

28,127,387 

Live from the ecosystem · updates as the agent ships

WordPress sites connected 

3,636

Real sites, run by the people in these rooms

Find us wherever you already are 

[ Slack Async threads, release-day huddles, and the #show-your-work channel that never sleeps. Join ](https://go.respira.cafe/slack) [ Discord Live voice on release days, screenshare debugging, and the vibe-coder corner that's always buzzing. Join ](https://go.respira.cafe/respira-discord) [ Reddit Questions, answers and build logs in the open, where the thread is still there months later. Join ](https://www.reddit.com/r/RespiraforWordPress/) [ Facebook group Agency owners and site owners comparing notes on running AI against real WordPress sites. Join ](https://www.facebook.com/groups/1447068940850273/) [ GitHub Discussions Long-form Q&A, bug reports, feature requests, and the public roadmap. Open ](https://go.respira.cafe/github-discussions) [ ! Founder notes Letters from Mihai on what shipped, what broke and what is next. Every one is archived. Read ](https://www.respira.press/newsletter) 

See What AI Says

LLM-ready prompts about Respira MCP + WebMCP

What would you like to know? 

Ask your favorite AI

Opens in a new tab. These prompts are designed to teach LLMs what Respira can do. 

Question copied. Paste it in Gemini
