WordPress wp2shell: why a default CMS can be a security risk

Introduction

On 17 July 2026 WordPress published emergency patches for a vulnerability chain nicknamed wp2shell. Not an obscure plugin. Not a misconfigured host. A combination of flaws in core itself that lets an attacker execute code on a default install without logging in. Searchlight Cyber estimates that more than 500 million websites run WordPress, and within hours of disclosure public proof-of-concepts were circulating. Security firms soon reported early signs of active exploitation.

For business owners the core question is not how the exploit works technically. The question is: what does this mean for the site where your leads arrive, your customers log in, or your content lives? And when is "just update" enough, versus when is a default CMS structurally the wrong foundation? This article lays out the facts, without exploit details, and explains how we as a software agency look at it.

What is wp2shell in plain language?

wp2shell is not a single bug but a chain of two weaknesses. CVE-2026-60137 is an SQL injection in the author__not_in parameter of the internal WP_Query class. Unsanitised input reaches the database query. That flaw exists in WordPress from version 6.8. CVE-2026-63030 is route confusion in the REST API batch endpoint /wp-json/batch/v1, introduced in WordPress 6.9. That confusion lets an attacker reach the SQL injection without authenticating and turn it into code execution.

The RCE chain was discovered by Adam Kues of Assetnote / Searchlight Cyber and reported through WordPress's HackerOne program. The SQL injection is credited to researchers TF1T, dtro and haongo. Searchlight initially withheld technical details and launched wp2shell.com as a testing tool for administrators. We publish no how-to and no PoC here: this article is meant to help decision makers, not attackers.

WordPress itself wrote in the security announcement that sites should update immediately, and enabled forced automatic updates for affected supported installs. That is rare. It underlines how seriously maintainers rated this chain. The technical advisory for CVE-2026-63030 is on GitHub Security Advisories.

Am I vulnerable? Affected versions and what to do today

Check your version via Dashboard → Updates, or via your site's generator meta tag. Compare with this list, based on WordPress advisories and summaries from Tenable, Rapid7 and BleepingComputer among others:

WordPress older than 6.8: not affected by this chain. Versions 6.8.0 to 6.8.5: SQL injection only (CVE-2026-60137), fixed in 6.8.6. Versions 6.9.0 to 6.9.4: full pre-auth RCE, fixed in 6.9.5. Versions 7.0.0 to 7.0.1: full pre-auth RCE, fixed in 7.0.2. 7.1 beta through beta1: full RCE, fixed in 7.1 beta2.

The only real fix is updating. If you cannot update immediately, temporarily block /wp-json/batch/v1 (and ?rest_route=/batch/v1) at the firewall or WAF, or restrict anonymous REST API access. Cloudflare rolled out WAF rules across all plans, including free, for sites proxied through its network. That reduces exposure but does not replace the update. Assume scanners are already running: public exploits are online and active abuse has been reported.

Why this is worse for businesses than "another WordPress bug"

"WAF protections reduce exposure while customers update, but they are not a substitute for patching."

— Cloudflare on temporary mitigations around wp2shell, July 2026

WordPress has taken criticism for years over plugins and outdated themes. Pre-auth remote code execution in core itself is rare. That is exactly why the industry reacted so sharply. watchTowr CEO Benjamin Harris told BleepingComputer that the fact this sits in core, not a niche plugin, is why everyone is scrambling to patch.

For an SME that translates into concrete risk. A successful attack means code execution on the web server: access to the database, customer data, email integrations, payment connectors and often the rest of the hosting environment. If your site is a client portal, quoting tool or webshop, that is not a "website problem" but a business continuity problem. Recovery takes days; reputation damage lasts longer.

Many organisations also treat WordPress as a finished product: an agency built it once, updates are half-enabled, plugins were never inventoried, and nobody owns security. A core flaw exposes that governance gap. Not only the code is vulnerable; the operating process is too.

The structural issue: attack surface of an all-in-one CMS

wp2shell is an incident. The pattern behind it is structural. A traditional CMS bundles content management, themes, plugins, REST API, user management and often e-commerce into one publicly reachable surface. Every plugin you add for "just a form" or "just SEO" grows that surface. Most historical Known Exploited Vulnerabilities around WordPress sit in plugins, not core. That WordPress was hit in core this time sharpens the lesson: even without plugins, a default install on an affected version was enough.

Compare that with how we design business software. A headless CMS keeps content behind an API; the public frontend is a separate application with a smaller, controlled surface. A custom portal or dashboard only gets the endpoints you need, with authentication, rate limiting and audit logging from day one. That is not magic and not a guarantee against every zero-day, but it is a fundamentally different risk profile than "everything the ecosystem allows is open by default".

In our projects we see the difference most clearly with clients who once started a marketing site on WordPress and slowly turned it into a mini-ERP: customer login, document uploads, status views, Exact Online integrations. At that point WordPress is no longer "cheap and fast". It is an application platform without application-engineering discipline. Our article on WordPress versus headless CMS covers that trade-off from performance, maintenance and security angles.

When WordPress is still fine, and when you should reconsider

We are not WordPress haters. For a content-driven marketing site, a news blog or a brochure with little sensitive data, WordPress can still be a pragmatic choice, provided you leave auto-updates on, select plugins strictly, test backups and assign someone to monthly checks. Ghost is a more focused alternative if you mainly publish; see our comparison of Ghost versus WordPress.

Do reconsider if one or more of these signals apply. You store personal data or documents behind login. You connect accounting, CRM or payments. You have more than a handful of plugins whose origin you no longer know. Updates are postponed because "something might break". Or every new feature becomes a plugin or custom PHP hack instead of a deliberate product decision. In those situations patching today is mandatory, but insufficient over time.

The migration path we recommend most often is phased: first secure the site (patch, WAF, inventory), then design the content model in a headless or custom stack, build the frontend as a modern web application, migrate content and keep old URLs with 301 redirects. That way you do not lose SEO positions and the business stays online during the move. An overview of common options is in our list of WordPress alternatives.

Practical checklist for the next 48 hours

Start with an inventory: which WordPress sites do you run, on which hosting, at which version, with which plugins? Note whether auto-updates are on and whether someone actually maintains the site. Then update core to 6.8.6, 6.9.5 or 7.0.2 (or newer on your branch) and verify the version after the update. Do not settle for "it should have happened automatically".

Next, run a backup test: can you actually restore the site? Remove or deactivate plugins you no longer use. Where possible put a WAF in front, or confirm that Cloudflare or your host has the wp2shell rules active. Finally, document who owns security updates for the next twelve months. Without an owner, the next core flaw arrives as a surprise again.

If during that inventory you realise the site has long since become an application, schedule an architecture conversation in parallel. Patching fixes the incident; architecture prevents the next incident from having the same impact. That conversation can be short: which data lives there, who logs in, which integrations exist, and what is the damage if the site is offline for a week?

How we bake security into custom software

At MG Software in Haarlem we do not build "a website plus plugins", but applications: client portals, dashboards, integrations and internal tools. Security sits in the design: least privilege, separated environments, dependency updates via CI, no open admin interfaces without MFA, and no generic batch endpoints nobody deliberately enabled.

That sounds heavier than WordPress, and for a simple landing page it is. For software that carries business processes, it is cheaper than a recovery project after a core RCE. We also help clients who stay on WordPress: update policy, plugin audit, WAF configuration and an exit plan for when the site grows into an application. The conversation always starts with what the site actually does for your revenue and which data lives on it, not with which CMS hype is popular this week.

Conclusion

wp2shell is a wake-up call, not a reason to panic if you patch today. It is a reason to look honestly at whether your WordPress install still fits the role the site plays in your company. A brochure site with tight operations is different from an unmaintained half-portal on an outdated core.

Want to talk through patch priority, a plugin audit or a migration to headless or custom software? Get in touch. The calculator gives you a direction for the investment of a web application or portal within two minutes.