*Authorized guest post by aaronott*
If you’re reading this, you read this site, so this is aimed at you, not my friend who runs it, though I did get authorization to post this. I got into their blog on 19 July. Here’s why that’s a story about your blog too.
I didn’t do anything clever. I got in through wp2shell, the WordPress pre-auth bug that had a patch sitting there for two days before I used it. The site wasn’t some abandoned install on a five-year-old version. It was reasonably current. The fix was just two days old and hadn’t been applied yet.
That’s the whole lesson, and it’s the most common one in this business.
On 17 July, WordPress shipped 7.0.2 and 6.9.5 to close wp2shell: a REST API batch-endpoint route confusion (CVE-2026-63030) chained to a `WP_Query` SQL injection (CVE-2026-60137). Together they hand an unauthenticated attacker a blind SQL injection through a single public endpoint, and on a lot of ordinary hosts, a path to running code.
When a fix ships, the clock starts for everyone at the same moment. Attackers diff the patch, build a working exploit, and start scanning within hours. wp2shell went from patch to public proof-of-concept in about a day. I was in on day two. Nobody caught by this gets outsmarted, they just find out too late.
The one thing you actually control is how fast you hear about the fix. Two things cover that:
Subscribe. For WordPress, watch the [WordPress.org news feed](https://wordpress.org/news/), where every core security release gets announced (it has an RSS feed you can drop into a reader), plus a CVE alert scoped to the plugins and themes you actually run. You should find the security feed for your stack, if there isn’t one, choose another stack. That’s enough for most single-site setups.
Have a fast way to act. You don’t need an incident-response binder if it’s just you and one blog. You need four things: have a good set of backups that run daily, turn on automatic security updates so criticals often land before you’re even awake, know how to update by hand for when they don’t, and know one stopgap you can throw up if you can’t patch right away (for wp2shell, blocking the batch endpoint at your host or WAF bought time). That’s it. The point isn’t process, it’s beating the scanners to your box.
Now here is my jab:
Look at what got compromised here: a whole content-management system, a REST API, a database, and a PHP runtime, all standing in front of what is basically some pages of text someone wrote for people to read.
If that describes your blog too, it’s worth asking whether you need the machinery. A static site is Markdown in, HTML out, served as flat files. No database to inject into, no endpoint to confuse, no login to brute-force. Hugo, Eleventy, Zola, Astro: pick one, `git push`, go to bed. The bug I used has nowhere to live in that world, because there’s no SQL for the injection to reach.
You don’t need a content management system. You need content, and a way to manage it. Those turn out to be very different amounts of attack surface.
So: subscribe, turn on auto-updates, and if you’re running a whole CMS to serve flat HTML, give static a look. It only took two days.
Hack the planet. Just patch yours first.
*aaronott*
