Web Fix On
Your WordPress, Our Priority – 24/7 Maintenance
Wp2shell Explained: The WordPress Attack Hitting Millions of Sites in 2026 (And How to Check If You’re Exposed)
The Short Version, Because Some of You Are Panicking
On July 17, 2026, the WordPress security team shipped an emergency patch for a flaw that lets a complete stranger on the internet run code on your website. No password. No plugin. No clicking a shady link. Just a request sent to your site.
It’s called wp2shell. If your site is running WordPress 6.9.0 through 6.9.4, or 7.0.0 through 7.0.1, you were exposed. Go check your version right now — Dashboard, then Updates. You need to be on 6.9.5, 7.0.2, or 6.8.6 at minimum.
Back? Good. Now let’s talk about what actually happened, and the part most articles skip: patching does not tell you whether you were already hit.
What Is wp2shell?
wp2shell is a critical pre-authentication remote code execution vulnerability in WordPress core, disclosed on July 17, 2026. It chains two separate bugs — CVE-2026-63030 and CVE-2026-60137 — to let an unauthenticated attacker take full control of a WordPress site. It works on a default installation with zero plugins installed.
That last sentence is the part that makes this different from every other WordPress security scare you’ve read about.
Most WordPress hacks trace back to something you did or didn’t do. An outdated plugin. A weak admin password. A theme you bought from a sketchy marketplace in 2019 and never updated. There’s usually a lesson, and usually it stings a little.
wp2shell has no lesson. The bug lived in WordPress core itself. A bare install — no plugins, no custom code, nothing but WordPress out of the box — was exploitable. If you were running an affected version, you were vulnerable, full stop.
The flaw was found by researcher Adam Kues at Searchlight Cyber, who used AI tooling during the discovery process. Make of that what you will. The robots found the hole, and other robots immediately started climbing through it.
How the Attack Actually Works (In Plain English)
Two bugs, chained together. Neither one is catastrophic alone. Together they hand over the keys.
Bug one: CVE-2026-63030, the route confusion.
WordPress 6.9 added a REST API batch endpoint at /wp-json/batch/v1. The idea is reasonable — instead of sending five separate API requests, an app can bundle them into one call. Faster, less overhead, everyone wins.
The problem is that the batch handler validates the bundled requests in one pass and executes them in another. When those two passes get out of sync, a request can end up being handled by the wrong route entirely — one where the normal permission checks don’t apply the way they should.
Think of it like a nightclub where the bouncer checks everyone’s ID at the door, then a separate staff member walks a different group inside. If the two lists don’t match, somebody who was never checked ends up standing at the bar.
Bug two: CVE-2026-60137, the SQL injection.
There’s an SQL injection flaw in the author__not_in parameter of WP_Query. On its own, it requires an authenticated user, which limits the damage considerably.
But chain it behind bug one, and suddenly it’s reachable by anyone. An attacker can pull data straight out of your MySQL database—including administrator password hashes, which can then be cracked offline at leisure.
The result: an anonymous HTTP request turns into full code execution on your server. Attackers have been using it to drop PHP webshells, upload fake plugins that expose a remote command endpoint, and create backdoor administrator accounts.
One more technical detail worth knowing, because it explains why some sites got hit and neighboring ones didn’t: Cloudflare reported that the vulnerable code path is reachable when a persistent object cache is not in use. Sites running Redis or Memcached object caching may have been shielded by accident. Congratulations on your performance optimization, it apparently doubled as a security control.
Which WordPress Versions Are Affected?
Here’s the version breakdown. Find your row, take the action in the third column.
| Your WordPress version | Exposure | What you need to do |
|---|---|---|
| 7.0.0 – 7.0.1 | Full RCE chain | Update to 7.0.2 or later immediately |
| 6.9.0 – 6.9.4 | Full RCE chain | Update to 6.9.5 or later immediately |
| 6.8.0 – 6.8.5 | SQL injection component only | Update to 6.8.6 or later |
| 6.9.5 / 7.0.2 / 6.8.6 or newer | Patched | Verify the update actually applied, then check for compromise |
| Older than 6.8 | Not exposed to this chain | You have bigger problems. Please update. |
WordPress enabled forced automatic updates given the severity, which was the right call. But — and security teams have been repeating this for good reason — do not assume the forced update landed. Auto-updates fail for plenty of boring reasons: file permission issues, disabled update constants in wp-config.php, managed hosts that override core update behavior, disk space, a broken cron.
Check every site you own. Individually. Yes, all of them.
The Timeline: Why This One Moved So Fast
The speed here is the story. Most vulnerabilities give you a grace period between disclosure and exploitation. This one gave almost none.
| Date | What happened |
|---|---|
| July 17, 2026 | WordPress ships emergency releases 6.8.6, 6.9.5, and 7.0.2 |
| July 17–18 | Public proof-of-concept exploit code appears on GitHub within hours |
| July 18–20 | Multiple security firms confirm in-the-wild exploitation |
| July 21 | Both CVEs added to CISA’s Known Exploited Vulnerabilities catalog |
| Ongoing | Activity escalates from targeted probing to internet-wide scanning |
Security researchers tracked exploitation beginning with credential exfiltration using the public exploit code, with full remote code execution following once more technical detail was published. Over a hundred backdoor administrator accounts were reportedly created across compromised sites.
A live patch-rate dashboard tracking a sample of roughly 124,000 sites showed around 81.6% patched. Which sounds encouraging until you do the math on the remaining 18%.
How to Check If Your Site Was Compromised
Patching closes the door. It does not remove anyone who already walked through it. If your site was on a vulnerable version and reachable from the internet during that exposure window, you need to check for compromise — not just confirm the update.
Here’s what to look for.
1. Unexpected administrator accounts
Go to Users → All Users and filter by Administrator. Look at the registration dates. Accounts created between July 17 and whenever you patched deserve real scrutiny.
Proof-of-concept exploit code used a w2s_ prefix on the accounts it created, so that’s an easy thing to search for. Don’t rely on it though — that prefix is a default that any competent attacker changes in about four seconds.
Also worth knowing: some attackers create an admin account, use it, then delete it. That leaves traces — orphaned user metadata in the database and gaps in the user ID sequence. If your user IDs jump from 4 to 9 and you only ever created four users, something happened.
2. Unknown plugins and stray PHP files
Look in wp-content/plugins/ for directories you don’t recognize. Attackers have been uploading malicious plugins that expose a REST endpoint for remote command execution, sometimes disguised as legitimate tools.
Then look wider. PHP files at randomized paths inside wp-content/ subdirectories — anything not belonging to an installed plugin or theme — are a red flag. Webshells have been found outside the plugin directory too, including in cache folders, which is exactly the kind of place nobody thinks to look.
3. Server access logs
This is the highest-fidelity check, and the one most site owners skip because logs are intimidating. They shouldn’t be.
Search your access logs for requests to /wp-json/batch/v1 or ?rest_route=/batch/v1. HTTP 207 (Multi-Status) responses from the batch endpoint are a strong indicator of exploitation attempts, particularly alongside unusual triple-slash path patterns.
Stock proof-of-concept code also sent user-agent strings containing wp2shell or rezwp2shell. Easy to search for, easy for attackers to change — treat a hit as confirmation, but treat a miss as nothing.
Also check for author__not_in or author_exclude parameters carrying non-integer values with SQL keywords in them. WordPress normalizes a few different spellings of that parameter, so search variations.
4. The obvious symptoms
Redirects to sites you don’t recognize. Spam content in your search results that you never wrote. Google Search Console security warnings. Your host suspending the account. Injected code in your pages. Sudden unexplained slowdowns.
If you’re seeing these, you’re past the checking stage.
Free tools that help
Searchlight Cyber — the team that found the flaw — runs a free external checker at wp2shell.com that probes a live site. There’s also a Compromise Scanner plugin in the WordPress.org repository built specifically to detect the artifacts this chain leaves behind.
Use both. Understand their limits. An external checker reads what your site tells the outside world, which version strings can hide or spoof. And a clean scan means no known artifacts were found — a careful attacker cleans up after themselves. Reassuring, not conclusive.
If You Find Evidence of Compromise, Do Not Just Delete the File
This is the single most common mistake we see people make, and it’s an expensive one.
Someone finds a suspicious PHP file, deletes it, feels relieved, and moves on. Two weeks later the site is reinfected and they can’t work out how.
Here’s why: successful exploitation of wp2shell means an attacker had code execution on your server. Not on your WordPress install — on your server. They may have dropped multiple backdoors, modified core files, planted a scheduled task, or stolen your database credentials and salts straight out of wp-config.php.
Deleting one webshell removes one symptom.
The actual recovery sequence:
- Take the site offline. Maintenance mode or a holding page. Stop the bleeding and stop serving malware to visitors.
- Assume full compromise. Don’t negotiate with yourself about how bad it probably is.
- Rotate every secret. Database password, all the authentication salts in
wp-config.php, API keys, every admin password, hosting panel credentials, SFTP keys. All of them. - Restore from a known-clean backup taken before the exposure window opened.
- Then patch, before the site goes back online. Restoring a clean backup onto an unpatched install just resets the clock.
- Verify after. Re-run the compromise checks on the restored site.
If you don’t have a clean pre-incident backup, or you’re not confident about any step above, that’s the point to bring in help rather than experiment. Bad malware cleanup is worse than none — it hides the problem without solving it.
Manual Cleanup vs. Professional Recovery
Both paths are legitimate. They just suit different situations.
| Doing it yourself | Professional cleanup | |
|---|---|---|
| Cost | Free, plus your time | Paid service |
| Time to resolution | Hours to days, depending on experience | Typically same-day |
| Server-level check | Usually limited to what you can see in the file manager | Full filesystem, logs, cron, and database review |
| Risk of missing a backdoor | Moderate to high — they’re designed to be hidden | Lower, with systematic hunting |
| Best for | Simple sites, recent clean backup, comfortable with SFTP and logs | Business sites, eCommerce, no clean backup, repeat infections |
If your site takes payments, stores customer data, or generates revenue, the math usually favors getting it handled properly. A WooCommerce store with a webshell on it isn’t a technical inconvenience, it’s a data breach with legal implications in most of the markets we work in.
The Bigger Pattern: This Is the Third One This Year
wp2shell didn’t happen in isolation. It’s the third significant WordPress security event of 2026.
In April, a supply-chain attack led to more than 25 plugins being pulled from the WordPress.org repository in a single day, after attackers gained the ability to push malicious updates to plugins with existing user bases. In June, three separate supply-chain incidents landed in one week — including a CDN key compromise that let attackers tamper with JavaScript served to over a million sites without touching the installed plugin code at all.
And now a core vulnerability that needed no plugins whatsoever.
There’s a pattern here, and it’s uncomfortable: the advice everyone has been giving for a decade — keep everything updated — is now the floor rather than the ceiling. In several of these incidents, the update was the attack. Sites that updated promptly got compromised because they updated promptly.
That doesn’t mean stop updating. It means updating alone stopped being a security strategy somewhere around 2025. What actually holds up now is layered: a firewall that can block a malicious request before it reaches PHP, file integrity monitoring that tells you when something changes on disk, backups you’ve actually tested restoring, a minimal plugin footprint, and someone who notices anomalies within hours instead of when a customer emails about a redirect.
Most site owners don’t have that. That’s not a character flaw — it’s a full-time job, and you probably already have one of those.
What to Do This Week
Short list. Do these in order.
- Check the core version on every WordPress site you manage. Dashboard → Updates. Confirm 6.9.5, 7.0.2, or 6.8.6 minimum.
- Don’t trust the auto-update. Verify visually, per site.
- Review your administrator accounts and their registration dates.
- Scan
wp-content/for unfamiliar plugin directories and stray PHP files. - Pull your access logs and search for batch endpoint requests during the exposure window.
- If you can’t patch immediately, block
/wp-json/batch/v1and?rest_route=/batch/v1at your firewall as a temporary measure. This is a stopgap, not a fix. - Test that your backups actually restore. A backup you’ve never restored is a hypothesis, not a safety net.
If step 3, 4, or 5 turns up something you can’t explain, stop and get the site properly assessed before you start deleting things.
Where WebFixOn Fits
We handle WordPress maintenance, security hardening, and malware recovery for businesses across the US, UK, Canada, and Australia. If you’ve checked your site and found something you can’t explain — or you’d rather have someone check properly than hope for the best — that’s the work we do.
For an active compromise, we’ll take the site offline, hunt for every backdoor rather than the obvious one, rotate your credentials, restore clean, patch, and verify before it goes back up. For sites that came through this fine, ongoing maintenance means the next core CVE gets patched and verified within hours instead of whenever someone notices.
wp2shell is patched. The next one isn’t announced yet.