Why wp2shell could not touch a single website we build

In July 2026, a flaw inside WordPress’s own code let a stranger take over a standard WordPress site without a password. It became known as wp2shell. It’s worth saying plainly: wp2shell could not be used against any site we build. It attacks WordPress, and there is no WordPress on our sites. The story is still worth telling, because it shows what a flaw in WordPress itself can do, even to owners who did everything right, with few add-ons and a reputable theme.

What wp2shell actually was

wp2shell is the nickname for two flaws in WordPress’s core software: CVE-2026-63030, a serious fault in how WordPress handles a batch of requests at once, and CVE-2026-60137, a database search issue known as SQL injection. On their own, each was bad. Chained together, they let an attacker take full control of a standard WordPress site, with no password, no add-on and no click needed from anyone.

The full takeover chain affected WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1. The database flaw on its own reached back further, to 6.8.0 to 6.8.5, though without the takeover route. Anything before 6.8 wasn’t affected. WordPress fixed both flaws together in an emergency release on 17 July 2026, in versions 7.0.2, 6.9.5 and 6.8.6, and turned on forced automatic updates so sites got the fix even if the owner did nothing. You can read the official release notes for the full detail.

Within days, working exploit code was public and attackers moved fast. The Hacker News reported tens of thousands of exploitation attempts, along with rogue administrator accounts, a disguised web shell and attempts to install remote access software on compromised sites. The US government’s cyber security agency, CISA, added the pair to its Known Exploited Vulnerabilities catalogue on 21 July 2026, official confirmation that attacks were under way.

Why it was such a big deal

WordPress runs around four in ten websites, so a flaw in its own code reaches a very large number of sites at once. Wiz, a security research firm, found that among the organisations it monitors, 60% had at least one vulnerable WordPress site when the flaw became public, and 25% had one directly reachable from the internet. Those figures are Wiz’s own customer base, not every WordPress site in the world, but they give a sense of scale. Within 24 hours, as owners raced to patch, they fell to roughly half and a tenth.

Most WordPress security advice focuses on add-ons, and normally that’s the right advice: Patchstack’s 2026 report on WordPress security found 91% of new vulnerabilities in 2025 sat in add-ons, not WordPress itself. wp2shell was the exception. It sat in WordPress’s own code, so no amount of careful add-on choices or a clean, reputable theme kept a site safe until the fix landed. That’s what made it worth writing about.

Why our websites weren’t affected

wp2shell could not be used against any site we build. It attacks flaws inside WordPress’s own code, in the database queries and the request handling that WordPress uses to run a site. Our sites don’t run WordPress. There’s no database on the live pages and no login area, because we build ready-made pages and serve them from fast hosting rather than assembling them from a system each time someone visits.

Jamstack.org explains the idea well: take the servers and databases off the live site, and there are fewer systems for anyone to break into in the first place. OWASP’s own guidance makes the same point in general terms: the fewer places there are to get in, the less there is to attack. This is simply how we build every site, described on our fast, secure hosting page. wp2shell needed WordPress running on the server to attack. Our sites don’t have it, so the attack had nothing to reach.

What can still go wrong

wp2shell is one specific attack, and it’s not one our sites face. A few other, more general things are worth knowing about, whatever kind of website you have.

The domain and hosting accounts behind any website are worth protecting properly: turn on two-factor authentication, lock the domain at your registrar and keep the contact details on the account accurate, which is what the NCSC recommends for domain registrars. Any third-party script added to a site later, such as a booking widget, a chat tool or a tracking snippet, runs with the same trust as the rest of the page, so it’s worth knowing what’s been added and why, a point OWASP makes about third-party code more generally. Ordinary phishing emails or a weak, reused password can undo any amount of careful building too.

For clients on our ongoing care plan, hosting, backups and monitoring are part of what we look after, so that side of things doesn’t fall to you. You can see how that fits alongside one-off builds on our pricing page.

If your site runs on WordPress

If you run WordPress yourself, three checks are worth making. First, confirm your site is on 7.0.2, 6.9.5 or 6.8.6 or later, the versions with the fix, using the version details in WordPress’s own release notes. Second, leave automatic updates switched on. It’s what the NCSC recommends for small organisations as standard practice, and it’s how WordPress pushed this fix out. Third, keep an eye on your add-ons separately. Patchstack’s 2026 report found the median time to first exploit for a new WordPress vulnerability was just 5 hours in 2025. None of that needs technical knowledge.

Get in touch

We’re a small studio based in Ruthin, working across North Wales, and we build every site this way as standard. If you’d like to know more about how a site with no WordPress, no database and no login area works day to day, read why we think a boring website is usually the right one, or get in touch and we’ll walk you through it.