How to check and fix wp2shell in WordPress (CVE-2026-60137 and CVE-2026-63030)

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.

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. The other is a REST API batch-route confusion issue tracked as CVE-2026-63030. 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. 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 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 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 →

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. 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
• GitHub Advisory: CVE-2026-60137
• GitHub Advisory: CVE-2026-63030
• Japan IPA security alert for wp2shell
• NHS England cyber alert: exploitation of the wp2shell chain
• SecurityWeek: wp2shell exploitation reporting
• Bitdefender technical advisory
• WooCommerce: Store API vulnerability advisory

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