Is my WordPress site safe?

Two people have asked me the same question in the past fortnight. Both run WordPress sites, both had read something alarming, and both wanted to know the same thing: am I in trouble? Neither of them wanted a sales pitch, so this is not one. Here is what actually happened, what to do today if you run WordPress, and the less comfortable question the whole episode raises - which is not really about WordPress at all.

What happened, plainly

On 17th July 2026, WordPress shipped emergency updates for a pair of flaws that researchers nicknamed wp2shell. It is not one bug but two, and they matter because of what they do when combined:

• CVE-2026-63030 - a confusion in how WordPress core's batch REST endpoint validates a request and then dispatches it. Validation and execution happened in separate passes, and an attacker could make the two disagree.
• CVE-2026-60137 - a SQL injection reachable through a query parameter, which lets an attacker put their own instructions into a database query.

Chained together, they let somebody with no account and no password reach in from the outside, forge an administrator for themselves, and run code on the server. In practical terms that is the whole site: the pages, the content, the enquiries, the database, and whatever else shares that hosting.

Credit where it belongs on the disclosure. The chain was found by Adam Kues of Searchlight Cyber's Assetnote team and reported responsibly through WordPress's bug bounty programme rather than sold or dumped publicly. WordPress patched it and switched on forced automatic updates because of the severity. That is the process working.

Why this one was different

WordPress vulnerabilities are announced constantly, and the overwhelming majority of them live in plugins - somebody's booking form, somebody's slider, somebody's SEO tool. You can usually shrug those off if you do not run the plugin in question.

This one was in core: the base WordPress application itself. Three things followed from that.

• No login was needed. Not a subscriber account, not a stolen password. Anonymous.
• No plugins were needed. A clean, stock WordPress install with nothing added was exploitable. There was no "well, I keep it minimal" defence.
• The surface was enormous. The endpoint involved has shipped in WordPress since version 5.6, which means the door existed on a very large share of the web.

Wordfence described it as the first critical unauthenticated WordPress core remote code execution flaw in close to a decade. And the window to act was brutally short: probing of that endpoint and SQL injection attempts were being observed the same evening the patch shipped, proof-of-concept exploit code circulated within days, and by 21st July both flaws were in CISA's Known Exploited Vulnerabilities catalogue - the formal confirmation that they were being used against real sites. Wiz reported that around 60% of organisations running WordPress had at least one vulnerable instance when the flaws were announced. Attackers were seen creating well over a hundred backdoor administrator accounts, then using them to install fake plugins and pull down further tools.

Note what that timeline means. The fix and the attack arrived on the same day. "We update monthly" was not fast enough.

If you run WordPress, do this today

None of this needs an agency. It needs twenty minutes.

• Take a backup first. Before you change anything.
• Check your version. In the dashboard, Updates shows it. Then update to the patched release for your branch:

• on 7.0.0 or 7.0.1 - update to 7.0.2 or newer;
• on 6.9.0 to 6.9.4 - update to 6.9.5 or newer;
• on 6.8.0 to 6.8.5 - update to 6.8.6 or newer. This branch was not exposed to the full takeover chain, but it does carry the SQL injection half, so it still needs patching. This is the bit most summaries leave out, and it is exactly the version range a lot of business sites sit on.

Then, separately: patching is not the same as cleaning up. An update closes the door. It does not remove anyone who walked through it while it was open. If your site was unpatched at any point after 17th July, look for administrator accounts you do not recognise, plugins you did not install, and files modified in the last fortnight - and do that whether or not you have now updated.

If you cannot confidently tell whether your site is clean, that is a "pay somebody competent for an hour" problem, not a "hope for the best" problem. You can check whether anything else you run has a known issue in the Wordfence vulnerability database, and confirm the current patched release on the WordPress version page.

The real lesson: whose job is it to patch?

The interesting question is not "is WordPress insecure". Every piece of software carries flaws, and the ones with the most eyes on them get the most found. The useful question is the one almost nobody asks when commissioning a website:

On the day a critical flaw is announced in the software my site runs on, who applies the fix, how quickly, and how will I know it has been done?

For a great many WordPress sites the honest answer is: the owner, and nobody has ever agreed a timescale. The site was built, handed over, and the security of it quietly became the responsibility of whoever happens to log in - which is often nobody, until something breaks. Both people who asked me about this had exactly that arrangement without realising they had it.

Two structural things make that arrangement risky, and neither is a criticism of WordPress's code.

The first is sameness at scale. WordPress runs a vast share of the web, and every install answers to the same URL paths. That is wonderfully efficient for building sites and equally efficient for attacking them: one core flaw turns into millions of identical targets, and an attacker does not hunt, they scan. The same property that makes a platform easy to hire for makes it worth industrialising an attack against.

The second is inherited code. Every plugin and theme you add is somebody else's software running with full access to your site and its database. You are not just trusting WordPress; you are trusting the security practice of every author whose work you installed, plus whoever maintains it next year, plus whoever buys the plugin when they get bored of it. Nobody chose that risk deliberately. It accumulates.

How we harden OliveCore

We build on our own platform, OliveCore. We own and control the application code and deliberately keep a small, known set of dependencies. There is no plugin marketplace, no page builder, and no theme downloaded from a directory - so there is no stack of third-party code executing on client sites that we did not write, review and choose to carry.

That is the structural part. The practical part is what we actually do with it, and we audit it rather than assert it. Some of what that means in plain terms:

• Public forms are treated as hostile by default. Every submission goes through a token check, a hidden-field trap, a minimum time-on-page, hard length limits on every field, a cap on the size of the request itself, and per-address rate limiting. That is one enquiry form's worth of defence applied everywhere, not a plugin's default settings.
• The admin side is locked by one rule, not page by page. Sign-in is required across the whole CMS as a default, and the handful of pages that are deliberately reachable without it each re-check who is asking. Nothing is protected only because somebody remembered to protect it.
• Author-supplied text never becomes code. Content that people type into the CMS is not allowed to reach the places where a string could turn into an instruction; the values we do interpolate into page styling are numbers, bounded in server code before they get anywhere near a browser.
• One codebase, one deployment. Because every client runs the same platform, a security fix is something we apply and push out. It is not a notification sitting in a dashboard waiting for a busy client to notice it.

That last point is the one that actually answers the question in the section above, and it is the reason we are comfortable being asked it. You can read more about how the platform is built and what it does at olivecore.net - fair warning, that site is a work in progress - or on our OliveCore page. There is a fuller account of how we build and monitor for this on our security page.

What we are not claiming

This is the part that usually gets left out of an agency blog post, so here it is.

We are not claiming OliveCore cannot have a vulnerability. Any non-trivial software can, ours included. Anyone who tells you their platform is unhackable is selling, and you should mark them down for it. What we claim is a smaller surface, a dependency list we can name, and a clear owner for the fix.

We are not claiming obscurity as a security feature. A platform that is not deployed on millions of sites is a less attractive target for industrialised scanning, and that is a genuine practical difference - but it is a consequence of scale, not a control we designed. Anybody who leans on it as their main argument is leaning on nothing.

And WordPress deserves credit here, not a kicking. The flaw was reported responsibly, patched quickly, and pushed out with forced automatic updates that will have saved a very large number of sites from owners who never read the announcement. WordPress in the hands of somebody competent who watches for this and acts within hours is a perfectly reasonable place to be. The failure mode is not WordPress. It is unmanaged WordPress - and that describes an uncomfortable number of the sites quietly running British small businesses right now.

We are equally willing to concede where WordPress wins. It is more portable than a builder platform, and we say so in our own post on whether you actually own your website.

The question worth asking

If you take one thing from this, do not make it "WordPress is dangerous". Make it a question you put to whoever looks after your site - us, your current agency, or the developer you have not spoken to since 2021:

When a critical vulnerability is announced for the software my website runs on, who applies the fix, how fast, and how will I know?

There are only three possible answers. Someone names themselves and a timescale, which is what you want. Or the answer is "you do" - which is fine, as long as you now know it and have decided who that actually is. Or nobody has an answer at all, and you have just found the real problem, which was never one CVE in the first place.

If you are in Norfolk and want a straight read on where your site stands - even if you have no intention of moving it - ask us. Both of the people who prompted this post got an honest answer and no invoice.