I Left WordPress Two Weeks Before PHP2Shell. Talk About Timing.

Two weeks after moving my neglected WordPress blog to emDash, critical PHP vulnerabilities threw the internet into emergency patching mode. Sometimes good architecture and good luck go hand in hand.

Well, that was some spectacular timing.

On October 7, I wrote about finally moving this blog off an old, neglected WordPress installation and onto emDash, hosted on Cloudflare Workers with D1 and R2.

Two weeks later, on October 21, PHP released emergency patches for two critical vulnerabilities that could allow remote code execution on affected servers. By October 22, reports of exploitation attempts and websites being taken offline were everywhere.

I didn't see any of that coming. I just got lucky.

The WordPress server I didn't want to touch

As I mentioned in Goodbye WordPress, Hello emDash, my old WordPress site had been running in a Docker container on an aging Intel NUC. It was outdated, rarely touched, and essentially locked down behind a restrictive WAF in read-only mode.

It wasn't exactly a thriving publishing platform. It was technical debt with a domain name.

I knew keeping an unpatched web stack around wasn't a great idea. But there was always something more interesting to work on than updating WordPress, PHP, plugins, and whatever else might break along the way. The WAF reduced some exposure; it didn't replace patching.

And then PHP2Shell happened

On October 21, 2026, PHP published fixes for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that, under certain conditions, could allow unauthenticated remote code execution. The fixes landed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

This wasn't a bad WordPress plugin or an unfortunate configuration choice. The vulnerabilities were in PHP itself, below the CMS layer. No WordPress security plugin can fix the underlying PHP runtime.

By the next day, the internet was having a very bad week: government advisories, scanning and exploitation attempts, emergency patching, and organizations temporarily taking services offline.

For technical details, see the PHP Foundation's explanation and CERT-EU's advisory.

To be clear, I haven't verified that my old server was running a specifically affected PHP version or that it was exploitable. But it was exactly the sort of forgotten, hard-to-maintain internet-facing stack I didn't want to own during a crisis.

I didn't just change CMSs

What makes me happy about the migration is that I didn't simply replace WordPress with another PHP application.

This blog now runs on Cloudflare Workers, D1, and R2. That doesn't make it invulnerable—dependencies, access permissions, Cloudflare services, and my own configuration still matter—but my old PHP runtime, WordPress plugins, and self-hosted web container are no longer part of this blog's attack surface.

And there's much less infrastructure to babysit. I can focus on writing instead of treating a personal blog like one more production server.

The emDash MCP integration is a nice bonus: I can draft and update articles through ChatGPT, then review them before publishing. That's a significant improvement over a CMS I barely wanted to log into.

Luck is nice. Less technical debt is better.

It's tempting to call this a brilliant preemptive security decision. I'd love to pretend I had a crystal ball. The truth is simpler: I was tired of maintaining WordPress.

What I *did* get right was recognizing that a service I didn't want to patch had no business remaining part of my internet-facing infrastructure.

I'm not celebrating everyone else's emergency. A lot of administrators are having a miserable week. I'm simply relieved that, for once, one of my infrastructure migrations happened before the fire drill instead of during it.

Sometimes good architecture and good luck show up together.

No comments yet