wp2shell and 7.1.4: Two Exploited WordPress Core Bugs

Yes: two WordPress core bugs have been exploited in the wild in 2026, and the fix for both is simply being on a current release. wp2shell (July) let an attacker with no account run code on a site; CVE-2026-119977 (October) did the same during a core upgrade. Update to WordPress 7.1.4, then look in /wp-content/mu-plugins/ for files you did not put there.

Key Takeaways

• wp2shell is two chained flaws, CVE-2026-63030 and CVE-2026-60137. Together they let an unauthenticated attacker run code on WordPress 6.9.0 through 7.0.1 (NVD). WordPress 6.8 is affected only by the SQL injection half (WordPress.org).
• Fixed in 6.8.6, 6.9.5 and 7.0.2. WordPress.org enabled forced updates through the auto-update system because of the severity (WordPress.org).
• CISA added both CVEs to its Known Exploited Vulnerabilities catalogue on 21 July (CISA KEV).
• WordPress 7.1.4 (28 October) fixes a second exploited core bug, CVE-2026-119977, in versions 4.7 to 7.1.3 (NVD).
• A separate backdoor family that hides in the mu-plugins folder was reported by Sucuri in October (The Hacker News).

What actually happened with wp2shell?

WordPress 7.0.2 fixed two bugs that were not catastrophic alone. One is a REST API batch-endpoint route confusion (CVE-2026-63030); the other is an SQL injection through the author__not_in parameter of WP_Query (CVE-2026-60137). NVD describes the combination as allowing SQL injection and remote code execution, scored CVSS 9.8, critical (NVD, CVE-2026-63030). Researchers called the chain wp2shell because it hands an attacker a shell on your server, with no login and no password guessing.

The patch shipped on 17 July 2026. Wordfence saw the first exploit-shaped probing the same day, at 23:29 UTC (Wordfence).

Was my site actually at risk, or is this being overblown?

It was real. Four days after the patch, CISA added both CVEs to its Known Exploited Vulnerabilities catalogue, a list that only includes bugs confirmed to be used against real targets (CISA KEV). WordPress.org also enabled forced updates for affected versions instead of waiting for owners to click (WordPress.org).

One correction to how this was first reported: the full chain needs 6.9.0 to 7.0.1. WordPress 6.8 only has the SQL injection, and versions before 6.8 are not affected (WordPress.org). Either way, a site on 6.8.5 or older 6.8 releases still needed 6.8.6.

Is wp2shell the only thing to worry about from July 2026?

No. Core got the headline, but plugins kept shipping patches. Wordfence’s report for 13 to 19 July counted 93 vulnerabilities disclosed in WordPress plugins that week, BuddyPress among them (Wordfence Intelligence). The following week’s report listed 268 across plugins and themes, including Yoast SEO (Wordfence Intelligence). Most sites run a dozen or more plugins, so a pending patch somewhere is likely.

What’s the mu-plugins backdoor about?

Must-use plugins in /wp-content/mu-plugins/ load automatically and do not appear on the normal Plugins screen, which makes the folder a good hiding place. Sucuri’s researcher described a malware family named “SC” that installs itself as a must-use plugin, hides from the plugins screen and update checks, and creates a hidden administrator account (The Hacker News, 1 October 2026). This was a separate campaign from wp2shell, so we do not claim a link between them.

Update, November 2026

WordPress 7.1.4 fixed a second exploited core bug. The 28 October release is a security release and recommends updating immediately (WordPress.org). Among its fixes is a weakness in the upgrade process. NVD records it as CVE-2026-119977: unauthenticated remote code execution in versions 4.7 through 7.1.3, caused by predictable, web-accessible staging paths used during full-package core upgrades, scored CVSS 8.1 (NVD). CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November (CISA KEV).

Two details matter. The code runs “during the upgrade window”, so the risk is tied to the moment a site is mid-upgrade. And the WordPress.org post itself lists no CVE or CVSS score; those come from NVD, so check your version number rather than waiting for a notice.

What to do: be on 7.1.4 or the backported release for your branch.

What should you check on your site right now?

Three things, in order of urgency:

• Confirm your WordPress version. You need 7.1.4 or the matching backport. For wp2shell alone, 6.8.6, 6.9.5 or 7.0.2 was the minimum. Check Dashboard > Updates in wp-admin.
• Update every plugin with a pending update. Plugin patches ship every week.
• Open the mu-plugins folder and actually look. Via FTP or your host’s file manager, go to /wp-content/mu-plugins/ and check for anything you don’t recognise. Also check the Users screen for administrators you did not create.

None of this means WordPress is a broken platform. It means attackers treat WordPress core like a job, and a site nobody is watching stays exposed by default.

How TalkToWP helps

TalkToWP reads the WordPress version, pending updates, administrator accounts and core file integrity (against WordPress.org checksums) on every site, so a site stuck on a vulnerable release or carrying an unknown admin shows up in one ranked list. We also keep a running list of exploited WordPress vulnerabilities on the noticeboard. TalkToWP is not a firewall and does not clean malware. Scan your site free.

Frequently Asked Questions

How do I know if my WordPress site is patched against wp2shell?

Check your version in wp-admin under Dashboard > Updates, or Tools > Site Health > Info. You are past this specific chain on 6.8.6, 6.9.5, 7.0.2 or later, but you should be on 7.1.4 or the backport for your branch because of CVE-2026-119977.

Does a security plugin like Wordfence protect me from wp2shell?

It reduces risk but is not a substitute for the core patch. A web application firewall can block some exploit attempts, but the flaw is in WordPress core, so updating is the actual fix.

What if auto-updates are turned off on my site?

WordPress.org’s forced update for the July bug may not have reached you. Log in and check your version today rather than assuming the patch applied itself.

How do I check the mu-plugins folder for a backdoor?

Connect via FTP or your host’s file manager and open /wp-content/mu-plugins/. Look for files you don’t recognise. If anything looks unfamiliar, don’t delete it first; ask your host or developer to look at it, because some malware rebuilds itself.

My site wasn’t affected. Is there still a lesson here?

Yes. Two core bugs were exploited within four months. Most site owners find out about a problem from a customer or a host suspension notice. Continuous checking catches a version that has fallen behind without anyone having to remember to look.