wp2shell WordPress Vulnerability: Check, Patch, and Recover

If your WordPress site is running an affected version, do not leave this update for the weekend.

wp2shell is the name given to a serious WordPress core vulnerability chain disclosed in July 2026. It can allow an unauthenticated attacker to move from having no account at all to executing code on a vulnerable WordPress website.

This is not another case of an abandoned plugin creating a security hole. The vulnerable code is in WordPress core, which means a clean WordPress installation can be exposed even when it has no third-party plugins or custom theme installed.

The good news is that patched WordPress releases are already available. The most important action is straightforward: check your version and update immediately.

This guide explains what wp2shell is, which WordPress versions are affected, how to patch safely, what to check after updating, and what to do if you suspect the site was compromised before the fix was installed.

What Is wp2shell?

wp2shell is a name used for an attack chain involving two WordPress core security flaws:

• A route-handling problem in the WordPress REST API batch system.
• An SQL injection issue involving a parameter used by WP_Query.

Individually, these issues are serious. When chained together on affected WordPress versions, they can lead to remote code execution.

Remote code execution means an attacker may be able to make the server run code they control. Depending on the attack and server environment, that can lead to:

• Unauthorized administrator accounts.
• Malicious plugin installation.
• PHP webshells.
• Database theft or modification.
• Spam pages and redirects.
• Payment-page tampering.
• Credential theft.
• Malware that survives a normal WordPress update.

The attack does not require the visitor to log in first. That is why this patch deserves immediate attention.

Which WordPress Versions Are Affected?

Even if your site appears to work normally, update it. A compromised site does not always show an obvious warning, redirect, or error message.

How to Check Your WordPress Version

Check from the WordPress Dashboard

Log in to WordPress and open:

Dashboard → Updates

You can also look in the lower-right corner of many WordPress administration screens, where the installed version is normally displayed.

Check with WP-CLI

If you have SSH and WP-CLI access, run:

wp core version

The command should return the installed version, such as:

7.0.1

If the result is an affected version, update immediately.

Ask Your Hosting Provider

If you cannot access the WordPress dashboard or server, ask your hosting provider to confirm the installed core version and apply the security release.

Do not rely on a page-source generator tag or a public version checker alone. Security plugins and hosting configurations may hide or alter publicly visible version information.

How to Patch wp2shell Safely

For a routine feature release, testing on staging first is the ideal workflow. A critical, actively exploited security issue changes the priority.

Take a fresh backup, perform a quick compatibility check, and install the security release without unnecessary delay.

Step 1: Create an Emergency Backup

Back up:

• The WordPress database.
• The wp-content directory.
• wp-config.php.
• Custom plugins and themes.
• Server configuration relevant to the site.

Store at least one copy away from the same hosting account. Read Best WordPress Backup Plugin: Full Comparison for long-term backup planning.

The backup is a recovery point, not a reason to postpone the patch for several days.

Step 2: Update from the Dashboard

Open:

Dashboard → Updates → Update Now

Wait for WordPress to complete the process. Do not close the page while the update is actively installing unless the process clearly stops responding.

Step 3: Update with WP-CLI

From the WordPress installation directory, run:

wp core update

Then confirm the installed version:

wp core version

Step 4: Clear Every Cache Layer

After updating, clear:

• WordPress page cache.
• Server cache.
• Redis or Memcached object cache.
• CDN cache.
• Browser cache when testing.

This helps prevent old cached admin or frontend files from creating confusing post-update behavior.

Step 5: Test the Site

Check:

• Homepage.
• Login page.
• Important forms.
• Admin dashboard.
• Post and page editing.
• Search.
• WooCommerce cart and checkout if applicable.
• Payment gateways and order emails.

For a broader update workflow, read How to Safely Update WordPress Without Breaking Your Site.

Updating Closes the Vulnerability—But Does It Remove Malware?

No. Updating WordPress closes the known security hole, but it does not guarantee that files, accounts, or database content added before the update are removed.

Think of the update as locking the door. If someone entered before the lock was changed, you still need to check the building.

A site that spent time online on an affected version should receive at least a basic compromise review after patching.

How to Check for Possible wp2shell Compromise

1. Review Administrator Accounts

Open:

Users → All Users

Filter by Administrator and review every account.

Look for:

• Administrators you do not recognize.
• Recently created accounts with unusual names.
• Accounts using temporary-looking email addresses.
• Legitimate users who unexpectedly received administrator access.

With WP-CLI, use:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Do not delete an account until you preserve relevant evidence and confirm it is unauthorized.

2. Verify WordPress Core Checksums

WP-CLI can compare core files against the official WordPress release:

wp core verify-checksums

An unexpected core-file mismatch deserves investigation. Configuration files, uploaded files, plugins, and themes are not fully covered by this core check.

3. Verify WordPress.org Plugin Checksums

For plugins distributed through WordPress.org, run:

wp plugin verify-checksums --all --strict

Premium, custom, or modified plugins may not have official WordPress.org checksums. A warning for those plugins is not automatically proof of malware.

4. Review Recently Modified PHP Files

From the WordPress root, a server administrator can list recently modified PHP files:

find wp-content -type f -name "*.php" -mtime -14 -print

Review the results against your update, deployment, and plugin-install history.

Pay attention to:

• Unknown PHP files inside uploads.
• Unexpected plugin folders.
• Files with random-looking names.
• Recently modified theme files without a known deployment.
• PHP files pretending to be image, cache, or backup files.

A recent modification is not automatically malicious. Plugin and theme updates legitimately modify many files.

5. Review Active Plugins and Must-Use Plugins

Check:

Plugins → Installed Plugins

Also inspect the wp-content/mu-plugins directory. Must-use plugins may not appear in the normal plugin list in the same way as regular plugins.

Look for anything you, your developer, or your hosting provider did not install.

6. Check Security and Server Logs

Review available logs from the period when the site was vulnerable:

• Web-server access logs.
• Web-server error logs.
• PHP error logs.
• Hosting control-panel logs.
• WordPress security-plugin logs.
• Cloudflare or WAF events.
• SFTP and SSH access logs.

Some attacks place important details inside request bodies that may not appear fully in standard access logs. Logs remain useful, but an absence of an obvious request is not conclusive proof that the site was untouched.

7. Use a Focused Scanner Carefully

A read-only wp2shell compromise scanner is available through the WordPress plugin directory. It can look for known database and plugin-file artifacts associated with public attack activity.

Use it as one part of an investigation—not as the final verdict.

A result showing no indicators means the scanner did not find the artifacts it knows how to detect. It does not prove that no attacker ever accessed the site.

Signs That Need Immediate Investigation

Escalate the incident if you find:

• An unknown administrator account.
• Core checksum failures that you cannot explain.
• Unknown PHP files in wp-content or uploads.
• An unfamiliar plugin or must-use plugin.
• Unexpected redirects.
• Spam pages appearing in search results.
• Modified payment or checkout behavior.
• New scheduled tasks or cron jobs.
• Unexplained outbound network activity.
• Hosting alerts about malware, spam, or high CPU use.

Do not assume that deleting one suspicious file completes the cleanup. Attackers commonly add more than one persistence method.

What to Do If You Suspect the Site Was Hacked

1. Preserve Evidence

Before deleting files or accounts, save:

• A full filesystem copy.
• A database export.
• Server and access logs.
• A list of active users and plugins.
• Dates and screenshots of suspicious findings.

This evidence can help an investigator understand what happened and whether sensitive information was accessed.

2. Place the Site in a Controlled State

For a serious compromise, you may need to temporarily restrict public access, place the store in maintenance mode, or route traffic to a clean static page.

For ecommerce sites, balance customer impact against the risk of allowing altered checkout code to remain live.

3. Restore from a Known-Clean Backup

Use a backup created before the suspected compromise—not simply the newest available backup.

After restoration:

• Update WordPress core immediately.
• Update all plugins and themes.
• Remove software that is no longer used.
• Verify core and plugin checksums.
• Scan the restored database and files.

Be careful when restoring WooCommerce databases. An older restore may remove recent orders, customers, refunds, and stock changes.

4. Replace WordPress Core Files

If core-file integrity is uncertain, replace WordPress core with a clean official copy while preserving wp-content and your configuration.

With WP-CLI, an experienced administrator can use:

wp core download --skip-content --force

Run checksum verification again afterward.

5. Reinstall Plugins and Themes from Trusted Sources

Do not keep a plugin simply because it appears to work. Replace WordPress.org plugins with clean copies and obtain premium plugins directly from their vendors.

Custom themes and plugins require a comparison against a trusted repository or development copy.

6. Rotate Every Important Credential

Change:

• All WordPress administrator passwords.
• Hosting control-panel password.
• SFTP and FTP credentials.
• SSH passwords and keys where necessary.
• Database password.
• Cloudflare or CDN credentials.
• SMTP credentials.
• Payment and third-party API keys where exposure is possible.

Do this from a clean device. Changing a password from an infected administrator computer can expose the replacement credential.

7. Replace WordPress Security Salts

Changing the security salts invalidates existing WordPress login sessions and forces users to authenticate again.

Use the FyrePress Fresh Security Salts Generator, then replace the existing salt constants inside wp-config.php.

8. Review Customer and Legal Impact

If the compromised website stores personal information, orders, customer accounts, payment-related data, or confidential records, speak with an appropriate security and legal professional.

Depending on the data, business location, and customer locations, notification or reporting duties may apply.

Can a Security Plugin Block wp2shell?

A firewall or security plugin may reduce exposure, detect suspicious activity, or block known attack patterns. It should not be treated as a replacement for the WordPress core update.

Security rules can be bypassed, disabled, or configured incorrectly. The permanent fix is to install a patched WordPress release.

Emergency filtering of the affected REST API batch behavior may be useful when a core update is temporarily impossible, but it can interfere with legitimate WordPress or plugin features. Use it only as a temporary bridge until the update is completed.

Does Disabling the REST API Fix wp2shell?

Restricting anonymous REST API access may reduce the immediate attack path, but disabling the entire REST API can break:

• The block editor.
• WooCommerce features.
• Mobile applications.
• Headless WordPress frontends.
• Plugin integrations.
• External publishing systems.

Do not make a broad permanent change when a patched WordPress release is already available.

Why Automatic Security Updates Matter

WordPress can install many maintenance and security releases automatically. For a vulnerability this serious, the WordPress team also enabled forced updates for affected versions through the automatic update system.

Still, do not assume every site updated successfully.

Automatic updates can fail because of:

• Incorrect file permissions.
• Disabled background updates.
• Version-control deployment policies.
• Read-only containers.
• Hosting restrictions.
• Low disk space.
• A failed previous update.

Check the installed version manually, even if automatic updates are enabled.

wp2shell Protection Checklist

• Confirm the installed WordPress version.
• Update affected 6.8 sites to 6.8.6 or later.
• Update affected 6.9 sites to 6.9.5 or later.
• Update affected 7.0 sites to 7.0.2 or later.
• Update WordPress 7.1 Beta 1 to Beta 2 or later.
• Take an offsite backup.
• Verify core checksums.
• Review administrator accounts.
• Review recently changed PHP files.
• Inspect active and must-use plugins.
• Check logs and security alerts.
• Rotate credentials if compromise is suspected.
• Replace WordPress salts after a confirmed compromise.
• Enable reliable automatic security updates.
• Continue monitoring after cleanup.

Strengthen WordPress After Patching

Once the urgent update and compromise review are complete, improve the site’s wider security baseline.

Priorities include:

• Remove unused themes and plugins.
• Enable two-factor authentication for administrators.
• Use unique administrator accounts.
• Restrict file editing where appropriate.
• Maintain tested offsite backups.
• Protect configuration and backup files.
• Monitor administrator creation and file changes.
• Use a web application firewall as an additional layer.
• Keep WordPress, plugins, themes, PHP, and server software updated.

Use the FyrePress Security Headers Generator for browser-facing security headers and read the WordPress Security Hardening Checklist for 2026 for the broader hardening workflow.

Common Mistakes to Avoid

• Assuming the site is safe because it has no plugins.
• Waiting for the next major WordPress release instead of installing the security patch.
• Trusting an automatic update without checking the installed version.
• Updating core but skipping the compromise review.
• Deleting one suspicious administrator and assuming the incident is over.
• Running only one scanner and treating a clean result as proof.
• Restoring the newest backup without confirming it predates the compromise.
• Changing WordPress passwords but forgetting hosting, SSH, database, and API credentials.
• Blocking the entire REST API permanently instead of applying the official fix.
• Publishing or testing exploit code against a production website.

Final Verdict

wp2shell is one of those WordPress security issues where the correct first step is not complicated: update WordPress now.

The full remote-code-execution chain affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. The related SQL injection also affects WordPress 6.8.0 through 6.8.5. Patched releases are already available.

Installing the update closes the known vulnerability, but sites that were publicly accessible on affected versions should also receive a compromise review. Check administrators, verify checksums, inspect modified files, review logs, and investigate anything you cannot explain.

If you find evidence of unauthorized access, do not patch one file and move on. Preserve evidence, restore trusted software, rotate credentials, invalidate sessions, and involve a security professional when customer or business data may be affected.

There is no benefit in waiting. Back up the site, install the patched WordPress release, and verify that the update completed successfully.