Summer 2026 was brutal for WordPress security: an unauthenticated remote code execution chain in core (wp2shell), a supply chain hack across seven plugins, a run of critical vulnerabilities. What I take away from it as a site maintainer, and the plan I apply.
I maintain WordPress and WooCommerce sites for my clients, and this summer I spent far more time than usual watching vulnerability feeds and pushing emergency patches. When a core flaw becomes mass exploitable within hours, you sometimes have to work on a live shop the same evening, while it is still taking orders. Here is what happened, checked source by source, and what I take from it.
wp2shell, WordPress core caught out
On 17 July 2026, WordPress shipped a security release fixing two separate flaws. On their own, neither yields code execution. Chained, they give an unauthenticated RCE on a bare WordPress, no plugins, no valid account, no user interaction. The chain was named wp2shell.
- CVE-2026-63030, a route confusion in the REST API batch processor (
/wp-json/batch/v1), which makes a request dispatch under the wrong handler and therefore slip past authentication checks. - CVE-2026-60137, a SQL injection in the
author__not_inparameter of the posts endpoint, interpolated straight into raw SQL when supplied as a scalar string.
The SQL injection is read only, but it is enough to forge data that WordPress itself then acts on: posts and a customizer changeset that end up creating an administrator account. From there the attacker logs in and uploads a plugin acting as a webshell, which closes the loop on full server takeover (Patchstack).
Affected versions are 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1 for the full chain, with the 6.8 branch hit by the SQL injection only. Fixes shipped in 6.8.6, 6.9.5 and 7.0.2, and WordPress took the unusual step of force pushing the automatic update to eligible installs (Tenable, Rapid7).
Patchstack saw the first real exploitation attempts around 90 minutes after 7.0.2 was released, three hours after the fix was committed: just enough time for someone to read the public diff, turn it into a scanner, and point it at everything. Within days, more than 65,000 blocked attempts from over 1,500 distinct source IPs, spread across a very decentralised set of networks. Several vendors confirmed active exploitation within three days of disclosure, and both CVEs landed in CISA's KEV catalogue on 21 July (SecurityWeek, The Hacker News).
A point clients rarely get right the first time: updating does not clean up. If the site was hit before the patch, the forged administrator account and the webshell are still there. You have to check administrator accounts, recently added plugins, unexpected PHP files in wp-content/uploads and above all wp-content/mu-plugins, which loads automatically without ever showing up on the Plugins screen.
# Administrator accounts, including any a filter might be hiding
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# PHP files where there should never be any
find wp-content/uploads -name '*.php' -mtime -90
ls -la wp-content/mu-plugins/
Two aftershocks in core, during August
wp2shell was not an isolated incident. On 6 August, version 7.0.3 fixed twelve vulnerabilities, including CVE-2026-64638, nicknamed XSS2Shell: a pre authentication reflected XSS on the login screen, triggered by a single failed login attempt, which can be chained all the way to PHP code execution when a logged in administrator is targeted. The fix was backported to maintained branches (Patchstack).
On 12 August, 7.0.4 fixed CVE-2026-65640 (CVSS 8.8), code execution through an image upload on servers that wire ImageMagick to Ghostscript. The mechanism takes two lines to describe: ImageMagick identifies a file by its contents, where WordPress trusted the extension in the name. A file named .png containing PostScript passed the upload check, reached Ghostscript, and was run there as a program. It needs an Author level account or above, which limits reach, but the faulty code had been sitting there since version 4.7, close to ten years (SecurityWeek).
Part of this pace comes from AI assisted research, which now produces complete exploitation chains within days, while patching cadences on the hosting and agency side have not moved.
The BdThemes supply chain attack, the blind spot
In early August, Wordfence was alerted to a compromise affecting seven plugins from the BdThemes vendor: Element Pack, Prime Slider, Pixel Gallery, Ultimate Post Kit, Ultimate Store Kit, Live Copy Paste and Smart Admin Assistant, more than 350,000 active installs combined. WordPress.org closed the listings on 7 and 8 August (The Hacker News, BleepingComputer).
What makes this attack interesting is that the plugin source code was never modified. Not a single file in the official repository moved. The attackers obtained write access to a DigitalOcean Spaces bucket hosting a static promotional JSON feed, the one the internal Biggopti component fetches to display banners in the admin. An escaping flaw introduced in March 2026 on the display_id parameter let them inject JavaScript into the API response. The script then ran in the browser of a logged in administrator, with their privileges.
The payload did the whole job: contacting a command and control server, creating administrator accounts hidden from user lists through query manipulation, installing a fake plugin that dropped a PHP webshell, and planting a magic login backdoor for unauthenticated access (Infosecurity Magazine).
The awkward part, for anyone watching a fleet, is that every usual check came back green: the plugin is legitimate, it comes from the official repository, its files have the right fingerprint, its version is current. The malicious code arrived at runtime, from a remote service the plugin called. As soon as a plugin pulls third party content into the admin, the attack surface spills beyond the code you installed, which is a fairly concrete reason to keep the plugin count low.
The plugin pile up
In parallel, the summer produced an unusually dense list of critical flaws exploitable without authentication. Here are the ones I followed closely, all patched by now.
| Component | CVE | Nature | CVSS | Vulnerable versions | Fixed in |
|---|---|---|---|---|---|
| GiveWP | CVE-2026-82222 | PHP object injection leading to unauthenticated RCE | 10.0 | ≤ 4.16.7.1 | 4.16.7.2 (27 August) |
| TranslatePress | CVE-2026-19632 | Admin password reset key exposed to any visitor | 9.8 | ≤ 3.3.1 | 3.3.2 |
| Avada + Fusion Builder | CVE-2026-18431 | Arbitrary file write leading to RCE | 9.8 | Avada ≤ 7.16, Fusion Builder ≤ 3.16 | 7.16.1 and 3.16.1 |
| Pods | CVE-2026-19598 | Authorization bypass, privilege escalation | 9.8 | ≤ 3.3.9 | 3.3.10 |
| Forminator | CVE-2026-15748 | Unauthenticated arbitrary file upload | 9.8 | ≤ 1.56.1 | 1.56.2 (31 July) |
Two deserve a word. GiveWP is the only 10.0 on the list: a gadget chain exploitable on a default install, with a single published donation form and one active payment gateway, no authentication and no administrator action required (Patchstack, Security Affairs).
TranslatePress, used on more than 400,000 sites, exposed the administrator password reset key in plain text to any visitor, through an AJAX action reachable without logging in. It required automatic string saving to be enabled, which is the default configuration (The Hacker News). Forminator, over 600,000 installs with roughly 300,000 sites potentially exposed according to SecurityWeek, allowed PHP files to be dropped through any form combining a file upload field and a select field.
What the summer changes for maintenance
The number worth keeping is those 90 minutes between the 7.0.2 fix being published and the first attacks observed against real sites. The countdown does not start when researchers find the flaw, but when the fix becomes public and anyone can read the diff.
This acceleration is not specific to WordPress. VulnCheck reports that close to one exploited vulnerability in four (23.4 %) is attacked before or on the day of public disclosure, and that the median delay between CVE publication and confirmed exploitation fell from 120 days in 2025 to 80 days over the first half of 2026 (VulnCheck). For high impact, mass target flaws like WordPress core, that delay is counted in hours.
Manual monthly updates therefore no longer protect against this kind of flaw. A monthly cadence leaves an average two week window open on something that starts being exploited an hour and a half after the patch ships.
The plan I apply
Here is the order I work through a site or a fleet, starting with what pays off most.
- Take inventory, and keep it current. Core version, plugin and theme list with versions, administrator accounts, per site. Without an inventory you cannot answer the only question that matters when a CVE lands: am I affected, and on which sites. That answer should take seconds, not a morning of manual logins.
- Leave core automatic updates on. That is exactly what saved a large share of sites on wp2shell. The regression risk is real but far smaller than the risk of an unauthenticated RCE.
- Update fast, but with a net. Fast updates are only sustainable if rollback is immediate: a snapshot before the operation, automatic restore on a fatal error. That is what lets you say yes the same day instead of deferring to "the next window".
- Shrink the surface. Every plugin is a dependency whose flaws you inherit, and sometimes, as with BdThemes, whose remote feed you inherit too. An unused but installed plugin is still exploitable. Delete it, do not just deactivate it.
- Run a WAF and rely on virtual patching. Between disclosure and the vendor fix, or between the fix and your update window, an application firewall rule is often the only protection available. That is what absorbed a share of the 65,000 wp2shell attempts.
- Apply least privilege and audit accounts. No administrator role for an editor, two factor authentication on privileged accounts, and a regular review: several of this summer's attacks create administrators, sometimes hidden from the user list.
- Test your backups. Until you have actually restored one, you do not know whether it works. And a backup that already contains the webshell is useless, hence the importance of retention depth.
- Monitor vulnerabilities continuously. Get the information on disclosure day, not in the monthly report.
What this pushed me to build
That last point cost me the most time this summer, because doing it by hand across several sites does not scale. I ended up writing it: wp-dashboard, my open source tool to monitor a fleet of WordPress sites, which centralises the inventory, cross references installed versions with vulnerability intelligence and applies updates with automatic rollback. It is the best way I found to answer "which sites are affected" in a couple of minutes.
The rest is ordinary maintenance work done seriously, which is usually enough to avoid the three days of cleanup afterwards. On the performance side of the same work, see also WooCommerce performance optimization.
Is your site running something older than 7.0.4, or can you not say which plugins are installed across your fleet? Let's talk, I take the inventory and bring it back up to date.