Should you migrate away from WordPress? Wp2shell aftermath

In July 2026 the wp2shell vulnerability exposed a large number of WordPress websites to a relatively simple hack and takeover. It is a good opportunity to open the conversation about whether it is still viable to run a WordPress website, and what the alternatives really are.

What actually happened

On 17 July 2026, Searchlight Cyber researcher Adam Kues disclosed wp2shell, a chain of two vulnerabilities that together give an unauthenticated attacker remote code execution on a WordPress site. Remote code execution is the worst category there is. It means running their code on your server, which in practice means anything they like.

The chain is:

• CVE-2026-63030 (CVSS 9.8), a route confusion weakness in the REST API batch endpoint /wp-json/batch/v1, introduced in WordPress 6.9.
• CVE-2026-60137 (CVSS 5.9), SQL injection via the author__not_in parameter of WP_Query, present since WordPress 6.8.

Neither is catastrophic alone. Chained on WordPress 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1, they are. Fixes shipped in 6.9.5 and 7.0.2, and WordPress.org pushed forced automatic updates to affected installs. Both CVEs were added to CISA’s Known Exploited Vulnerabilities catalog on 21 July, which confirms attackers were using them in the wild.

If you do nothing else after reading this, check your WordPress version. If you are below 6.9.5, or on 7.0.0 or 7.0.1, you are running a version with a public exploit against it.

Why so much of the web runs on WordPress, and why that is now the problem

The openness of the WordPress platform, and the enormous library of third party plugins that grew around it, is what made it so popular in the first place. You could build almost anything, with almost any integration. A lot of sites are on WordPress simply because at the time it was the easiest and most flexible open option available.

That same openness is slowly becoming its largest vulnerability. Every plugin is code from someone else running on your server. Every abandoned one is an opened door. In my experience, on an unmaintained WordPress website, it is not a matter of if a vulnerability turns up through an outdated plugin or a misconfiguration. It is a matter of when.

A small correction to the video. I framed the risk around plugins, which is where the overwhelming majority of the incidents I get called about start. wp2shell was not one of those. It was in the core.

What to do now if you are running a WordPress website?

There used to be a time when you could take your chances. Skip maintenance, run the odds, and often get away with it because nobody was specifically interested in your site.

That is over. Attackers have become more automated and equipped with AI. Mass scanning means the window between “vulnerability disclosed” and “your site is being probed” is now hours, not weeks.

The damage is not always the dramatic kind. Some hacks are invasive and obvious, stealing credentials or user data, defacing the homepage. Others are deliberately quiet: spam pages injected to farm someone else’s SEO, your contact form turned into a mail relay, your visitors redirected on mobile only so you never see it yourself. I have written up the patterns I see most often if you want to know what to look for.

The one result that costs real money is Google flagging the domain. Organic traffic goes to roughly zero overnight, and getting the warning removed takes time. If customer data was exposed, you are also into GDPR notification territory.

I know this all sounds scary, but there is a reason I push on it. Leaving an unmaintained WordPress site online only motivates more hackers and is fueling the fire that everyone else is trying to put out.

So here are the options I would propose to keep your website protected:

Option 1: rebuild with AI

You have probably heard by now that AI is pretty good at making websites. It is. But do not expect it to be a one prompt thing.

I have reviewed a lot of websites built with AI, and it usually takes a good amount of effort to get something that genuinely works for your specific use case rather than something very generic that looks plausible until you actually look into it.

Also, a site that Claude or ChatGPT generated and you exported and put online does not solve the same problem WordPress solves. WordPress is not just a way to have pages. It is publishing, collaboration, several people editing without stepping on each other, integrations with the other tools your business runs on, and a pile of processes made easier. A static export of an AI conversation gives you none of that. If the reason you are on WordPress is the CMS, replacing it with generated HTML is a downgrade dressed as a modernisation.

It is a quick fix for simple projects, but if the only reason you are considering a rebuild is security, AI is not the fastest way to solve that problem.

Option 2: keep WordPress, maintain it properly

If what you currently have is working for you and your main concern is security, there is some good news.

A well maintained WordPress website, where somebody is watching and applying security patches as they come out, ideally with an extra layer of protection in front of it, is in a fundamentally different position from an unmaintained one. And the wp2shell vulnerability was a great demonstration of that:

The firewalls got there first. Cloudflare’s managed WAF rules covering both CVEs went live at 17:03 UTC on 17 July, the day of disclosure, for every plan including free, as long as your traffic is actually proxied through Cloudflare. Wordfence shipped a firewall rule to its paid tiers the same day. Patchstack pushed protections alongside them. The CVEs were not added to CISA’s Known Exploited Vulnerabilities catalog until 21 July.

For four days, sites sitting behind one of those firewalls were being shielded from an unauthenticated remote code execution attack on WordPress core, in many cases before their owners knew there was anything to worry about. That is what the protection layer is actually for – covering the window between a vulnerability becoming public and you getting round to patching, which is exactly the window where mass exploitation happens.

What “properly maintained” means in practice:

• Core and plugin patches applied promptly, not quarterly. For wp2shell the useful window was measured in hours.
• A protection layer in front of the site. I use Patchstack with Cloudflare. Patchstack ships virtual patches for known vulnerabilities. Cloudflare’s WAF filters a lot of automated probing before it ever reaches your server. Worth knowing that the Cloudflare bundled with your hosting is not the same thing as your own account, and that the rules only help if your traffic is genuinely proxied through it.
• A staging copy, so updates get tested before they touch the live site.
• Backups you have actually restored from. An untested backup is a hope.
• Someone whose job it is to notice. Tooling raises alerts. Alerts need a human.

If you want the specifics of what a decent setup looks like now, that is here.

Option 3: static WordPress

If you want an extra layer of security and your website is not very dynamic, if it is mostly a marketing and content driven hub that does not really justify a monthly spend on security and patching, there is an option that is not particularly well known but is very practical.

Static WordPress. You keep your existing WordPress website, but you keep it out of reach of the internet. It runs somewhere private, locally or on a staging server, and you write and edit in the admin you already know. Then you publish a static copy of the front end, plain HTML, CSS, images and JavaScript, to a fast loading server. That copy is what visitors get. I run my own business site this way, using the Simply Static plugin for the export.

You solve security, and at the same time you get a very performant website that can run on cheaper hosting than a full blown WordPress site.

What this actually buys you:

• There is no WordPress on the public internet. No /wp-login.php, no /wp-json/batch/v1, no PHP, no database. wp2shell was an attack against a running WordPress install. There was nothing on my public site for it to attack. Not patched quickly. Not present.
• It is fast. Flat files from a CDN. No PHP execution, no database queries. This is the ceiling for performance, not a compromise towards it.
• Hosting gets cheap. Static files run happily on Cloudflare Pages, Netlify or similar, often free at small scale.
• Far less to maintain. Plugin updates on a machine nobody can reach are a much smaller deal.

The catch

A static file cannot run code, and that cuts both ways. Anything that has to do something at the moment a visitor interacts with it needs rethinking:

• Logins, member areas, gated content. No, that won’t work.
• WooCommerce, bookings, live availability, anything transactional. Also no.
• You need discipline. Edit, export, deploy. If your team publishes several times a day and will not tolerate a build step, this will annoy them.

Checking whether you qualify is easy, and I skipped past this in the video. Simply Static has a compatibility test tool that will tell you whether your site is a candidate.

You can do this yourself, with a professional, or somewhere in between using the Simply Static platform. The full how to is its own video, which is coming.

Option 4: move to a SaaS platform

I skipped this one entirely in the video, but it may be the right choice for many. Squarespace, Wix and Webflow all take the security question off your desk. You do not patch anything. The platform’s security team handles it and you will likely never hear about it.

Roughly who each one suits:

• Squarespace. Small marketing and brochure sites where design consistency matters and requirements are modest. Best defaults of the three, hardest to make look bad, least flexible when you want something specific.
• Wix. Small businesses wanting to build it themselves, with the widest app market of the three and genuinely capable AI assisted setup now. You will hit a ceiling if your needs get structural.
• Webflow. The one I would point a marketing team or agency at. Real control over markup, responsive behaviour and its CMS collections, without running a server. Steepest learning curve, highest cost, and it expects someone who thinks like a designer and developer.

The catches of SaaS platforms:

• You are renting, and the rent goes up. Cheap at one site on a small plan, less so once you are on a business tier, plus per app subscriptions, plus ecommerce fees.
• Getting out is much harder than getting in. WordPress content exports to a portable format. SaaS platforms export something considerably less useful, often a CSV of text with images and layout left behind. Assume a future migration means rebuilding, and price that in now.
• You inherit the platform’s technical ceiling. Custom integrations, unusual data structures, a specific checkout flow, anything needing server side logic. You get what the platform offers. Third party embeds are the escape hatch, and they cost you page speed.
• You are renting the SEO foundations too. All three are fine at the basics now, but when you need control over something specific, redirect handling at scale, structured data beyond the templates, page speed under a heavy embed load, you are limited to what is exposed.
• Your data lives on someone else’s infrastructure, mostly American. For a marketing site with a contact form, usually a non issue with the right processing agreement in place. If you handle anything sensitive, or you have data residency requirements, read the DPA before you commit rather than after.
• Migrating is a project, not a weekend. Content moves by hand. Every URL needs a redirect or you lose the rankings you have built. Plugin functionality has no equivalent and needs redesigning around what the platform can do.

WordPress means you own an asset and owe it maintenance. SaaS means you rent a service and owe it rent.

Working out which one is yours

To sum it up, if you are running a WordPress website and you are concerned about security:

• Mostly content, few dynamic features, forms you are happy to hand to a service. Go static, if your setup allows it. Best security to cost ratio available, and you keep the editor you know.
• Really leveraging the WordPress ecosystem, running dynamic plugins like WooCommerce or a booking system. Get a maintenance plan that works for you. This is not optional on this path.
• Small site, no appetite for owning any of this, and you will accept the lock in. A SaaS platform, with your eyes open about export, upsells, limitations and cost.
• Already exploring a redesign or restructure anyway. Start with AI and see where it takes you. If nothing else you will have a better idea of what you need.

What I would do this week

Whichever direction you eventually pick:

1. Check your WordPress version. Below 6.9.5, or on 7.0.0 or 7.0.1, update now.
2. Confirm the update actually applied. Forced updates helped a lot of sites, but not ones where auto updates were disabled or the filesystem is read only. If you are weighing this up more generally, I have written about whether to enable WordPress auto-updates.
3. Check whether you were actually behind a firewall during the window. If you are on Cloudflare, confirm your DNS records are proxied rather than DNS only. An unproxied Cloudflare account gave you nothing here.
4. If you were running a vulnerable version while a public exploit was available, assume probing. Look for admin users you do not recognise, recently modified PHP files, and scheduled tasks you did not create.
5. Then have the strategic conversation. Not before. Patch first, decide second.

Not sure which one fits?

That is genuinely the useful question, and it depends on things I cannot guess from here: what your site does, who edits it, and what you would be giving up.

If you want a straight answer for your specific site, get in touch and tell me what it has to do. I will tell you which of these four I would pick and why, including when the answer is “what you have got is fine, just look after it.”