Your brochure site does not need a database

On 20 July, attackers started chaining two WordPress bugs together. The first,

CVE-2026-63030, is a logic flaw in the Batch REST API. The second, CVE-2026-60137, is an SQL injection. Alone, each is bad. Chained, they became wp2shell: pre-authentication remote code execution. No password, no login, no user clicking anything. Just a request.

Over 400 million sites were running affected versions (6.9.0 through 6.9.4, and 7.0.0 through 7.0.1). One widely cited analysis put the number genuinely at risk around 90 million. Patchstack, Hexastrike and WatchTowr all confirmed exploitation in the wild within three days of disclosure. WordPress patched it and pushed forced updates, which is the right response and was handled well.

I want to talk about the part that has been bothering me since, and it is not "WordPress is insecure."

The detail everyone skipped

This was in core. Not a plugin.

That matters more than it sounds. The standing advice for a decade has been: keep your plugin count down, audit what you install, do not run abandoned code. It is good advice. I have given it. And it would have done nothing here. You could have been running a stock install with zero plugins, updated last month, and still been a target.

The second detail is that it was pre-auth. Most vulnerabilities need something from
you first. A logged-in subscriber account, an admin who clicks a link, a form you left
open. This needed nothing. If the site was reachable, it was in scope.

So the two things most owners believe protect them, being careful about plugins and not having many users, were both irrelevant.

The question this leaves

Here is what I keep coming back to. A very large share of those 400 million installs are sites that do not change. A restaurant with a menu and an address. A photographer with twelve images. A consultancy with four pages and a contact form. A local charity.

Every one of those sites, right now, is executing code on every single request. A PHP runtime boots. A database is queried. A router resolves. A theme renders. All to produce markup that was identical yesterday and will be identical tomorrow.

That is a lot of moving machinery to display a phone number.

And every piece of that machinery is attack surface. Not because anyone wrote bad code, but because executing anything is categorically riskier than executing nothing. A pre-auth RCE needs something to run against. If the public surface of your site is a directory of files that a web server hands over unmodified, there is no request handler to confuse, no query to inject into, no API to reach.

To be fair to WordPress

The dynamic model buys you real things, and I do not want to be glib about it. Comments. Search. Membership. Ecommerce. A hundred thousand plugins. A CMS your client can actually use without calling you. Live content that changes per visitor.

If you need those, you need a runtime, and WordPress is a mature and well-maintained way to have one. The people who fixed wp2shell did so quickly and pushed updates aggressively.
That is a healthy project.

The question is not whether WordPress is good. It is whether your site is using any of what the runtime is for. For a great many sites, the honest answer is no, and they are carrying the risk anyway out of habit.

What static actually costs you

I should be straight about the trade, because "just go static" gets said too easily.

You lose anything that has to happen per-request on your own server. Comments need a service or a rebuild. Search needs a client-side index or a third party. Forms need somewhere to POST. Anything personalised is out, or moves to the browser.

For a lot of sites that is a genuinely bad trade. For a brochure site it costs you close
to nothing, because you were not using any of it.

The other thing static gives you is boring in the best way. There is nothing to patch at 2am. No plugin update that breaks the theme. Your site does not go down because a database fell over. It is files. Files are very hard to break.

Disclosure, and what I would actually do

I build a static hosting platform, so I am obviously not neutral here. Take the
recommendation with that in mind. But the argument stands on its own and predates my interest in it: a site that never changes should not be running code on every request.

Practically, if you own a WordPress site:

• Update it. Today, if you have not. This is patched and the exploit is public.
• Then ask what the runtime is doing for you. List the things on your site that
  actually change or respond. If the list is empty, you are paying a security cost for
  capability you are not using.
• If the list is not empty, stay put. Keep it updated, keep plugins minimal, and get automatic updates on. A well-run WordPress site is fine.

The uncomfortable thing about wp2shell is not that WordPress had a bad month. Software has bad months. It is that 90 million sites were exposed to a class of attack that a meaningful fraction of them had no reason to be exposed to at all, because they were never using the thing that created the exposure.

Files do not get RCEs.

Sources: TechCrunch,
Rapid7 on CVE-2026-63030,
Dark Reading.