In July 2026, two linked flaws in WordPress itself let anonymous attackers take control of standard WordPress sites with no plugins. The sites left exposed were the ones that couldn't take updates. Here's what that means for your business.
In July 2026, an anonymous attacker could take over a brand-new WordPress site. No plugins, no unusual settings, no stolen password. The researchers who found the problem said the attack "has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins."
The pair of flaws became known as wp2shell. Within days, attackers were using it to plant backdoors on real websites, and the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its catalogue of vulnerabilities known to be exploited.
wp2shell is unusual because it didn't affect old software. It affected the newest versions of WordPress. That makes it a clear test of a question every business with a website should be able to answer: when a critical fix is released, how quickly does it reach your site?
What wp2shell is, in plain terms
WordPress is the software behind a very large share of business websites, from company brochures to online shops. wp2shell was two separate weaknesses in WordPress itself that became dangerous when used together.
- The first (CVE-2026-63030) was in a feature that lets an application send several requests to a WordPress site in one go. A mix-up in how WordPress handled those bundled requests gave anonymous visitors a route into parts of the site they should never have reached. NVD, the US government's vulnerability database, lists it at 9.8 out of 10 for severity.
- The second (CVE-2026-60137) was a weakness that could let an attacker slip their own commands into the site's database, a type of flaw known as SQL injection. On its own, it only mattered when a plugin or theme passed visitor input to the affected part of WordPress.
Chained together, the two let an attacker who wasn't logged in run their own code on the server. According to WordPress, the full chain affected WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1. Older versions were not exposed to it.
WordPress released fixes on 17 July 2026 and, because of the severity, used its automatic update system to push them to affected sites.
What could go wrong for your business
With wp2shell, the possible outcomes were not theoretical. Wiz Research reported on 20 July that it had seen "multiple actors" successfully exploiting the chain against self-hosted WordPress sites. According to Wiz, attackers:
- uploaded malicious plugins to keep a hidden way back into the site;
- collected administrator usernames and email addresses;
- tried to read the file that holds the site's database password; and
- planted webshells, small hidden tools that let an attacker control the server remotely, including one disguised as a plugin.
For a business, that kind of access can mean exposed customer and business data, a site that has to be taken offline and rebuilt, the cost of investigation and recovery, and a difficult conversation with customers. A backdoor can also outlast the original flaw: a site that was updated after being compromised may still have the attacker's hidden access in place.
CISA added both flaws to its catalogue on 21 July 2026. At the time of writing, it lists their use in ransomware as "Unknown", so there is no confirmed link to ransomware.
Could your website be next?
he original wp2shell flaws have been fixed, but the lesson applies to the next serious flaw, whatever it is.
Attackers often use automated tools to scan large numbers of websites for known weaknesses. wp2shell showed this clearly: Wiz found that a particular label sent by the attack tools was a reliable sign of an attack, which suggests ready-made tools were doing much of the work, rather than people choosing targets one by one. A small business site was as easy to find as a large one. What mattered was whether the site was online and still running an affected version.
The good news is how fast the fix worked where it was allowed to arrive. Wiz measured it in its own data: when its research was published, 25% of organisations using WordPress were exposing a vulnerable server to the internet. Within 24 hours, that was 10%.
That still left a group of sites exposed. Wiz doesn't say why they lagged, but WordPress's automatic fixes only reach sites where automatic updates are switched on. If yours were switched off, a critical fix could sit unused while attackers scanned for exactly that gap.
None of this means every site is vulnerable or that an attack is inevitable. But never having had an incident is not the same as being protected.
Why legacy PHP applications deserve attention
If wp2shell affected new versions, why does it matter for older sites? Because the fix was the easy part.
WordPress lets site owners switch off automatic updates entirely, and its own documentation calls disabling security updates "strongly discouraged". People do it anyway, usually for an understandable reason: an update once broke a plugin, someone edited a theme directly, or the site runs on an old PHP version and nobody wants to touch it. That is what a legacy system looks like from the inside. It works, it's fragile, and every change feels like a risk, so changes stop, including security fixes.
Plugins are a second warning sign. The database flaw in wp2shell needed nothing more than a plugin or theme passing visitor input to WordPress. Older plugins that are no longer maintained are a likely place for that to happen.
wp2shell also wasn't the year's only critical WordPress flaw. In September, WordPress fixed another (CVE-2026-87902) that, under certain conditions, could let an unauthenticated attacker run code. One route to that relied on a leftover component from an old PHP add-on system, and WordPress said a common default hosting control-panel setup was affected when PHP older than 8.5 was in use. CISA added it to its exploited catalogue on 25 September. Old components left behind on ageing servers can turn a limited flaw into a full compromise.
None of this means modern platforms are immune. Node.js applications have serious vulnerabilities too. What matters is whether your team can apply a security fix the day it is released, with confidence that nothing else will break.
What this means for your organisation
The useful question after wp2shell isn't "were we hit?", though that is worth confirming. It is "how would we cope with the next one?"
Can your team say which WordPress and PHP versions each site runs? Are automatic security updates on, and if not, who switched them off and why? Which plugins does the site depend on, and are they still maintained? And if a site was running an affected version in July, has anyone checked that it wasn't compromised before the fix arrived?
If the honest answer is that nobody trusts the site to survive an update, that is the real risk to address. It is much better to understand that through a planned review than through an incident.
Recommended next step
Take our free Legacy PHP Risk Assessment to understand how quickly your sites would receive the next critical fix, and what is standing in the way. It can help you see where your WordPress and PHP versions, update settings and plugins leave you exposed, and where modernisation would reduce the burden.
Then talk to our team about what you find. For some sites, a leaner, well-maintained WordPress setup on current PHP is the right answer. For others, a gradual move to a modern stack such as Node.js, with automated testing that makes applying security fixes routine, may suit the application and your goals better. No platform is secure on its own. What protects you is a setup your team can keep current with confidence.
Free Legacy PHP Risk Assessment
Do you know how quickly your sites would receive the next critical WordPress fix? We'll review your WordPress and PHP versions, update settings, plugins and hosting setup, and tell you plainly where you're exposed and what your options are.
