On Tuesday the PHP team warned that a security release was coming. On Wednesday afternoon it landed, and it's a bad one.

Two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both rated 9.2 out of 10. Both allow remote code execution without logging in. CERT-EU, the EU's own security team, has told organisations to patch immediately or pull internet-facing PHP apps offline until they can.

I've spent this morning reading the advisory properly. Here's what it means if you run a PHP site, what to do today, and why none of the sites I host on HD CMS needed a single change.

What actually happened

The first flaw lives in how PHP handles running out of memory. PHP enforces its memory limit by aborting the request mid-flight. If that abort lands while PHP is half way through parsing something, a file upload form for example, the cleanup code can try to free memory that was never set up properly. That memory can still hold data an attacker sent earlier. That's the door in.

The second flaw is about leftover state. After certain errors, a bit of internal state from one request can outlive the memory behind it. The next request on the same worker can pick it up before PHP resets things.

The part that should worry you: the published exploit needs one unauthenticated request, and it fires before any of your application code runs. Your WordPress security plugin, your Magento hardening, your carefully written validation, none of it gets a chance to run.

Every way of serving PHP is in scope. PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed. The PHP team rates mod_php as the riskiest. Proofs of concept are already circulating.

If you run PHP, do this today

1. Find every PHP install you're responsible for. Not just the main site. The old staging box, the forgotten microsite, the admin tool someone set up in 2019. Run php -v on each.
2. Patch to a fixed version. That's 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On managed hosting, check your host's status page or ask them directly when they're rolling it out.
3. If you're on PHP 8.1 or older, you have a bigger problem. Those versions are end of life. Some vendors have backports, and the PHP team published minimal source patches for 7.4, 8.0 and 8.1, but the real fix is an upgrade.
4. Can't patch today? Reduce exposure. The advisory lists temporary settings, such as turning off session.upload_progress and tightening post_max_size. They narrow the attack paths. They don't close them.
5. Then check nothing already got in. New admin users, unfamiliar files in upload folders, odd cron jobs.

If that list made your stomach drop, I can do it for you. Patching, checking for compromise, and putting the mitigations in place while the upgrade is planned. Get in touch and I'll look at it today.

Why my HD CMS clients didn't need to do anything

This morning I didn't patch a single HD CMS site. Not because I was quick. Because there was nothing to patch.

HD CMS is a headless setup. The front end is Nuxt, built and served from Vercel. Content lives in Supabase, which is Postgres with a properly locked-down API in front of it. There's no PHP interpreter sitting on a server waiting for requests. There's no long-running worker holding state from the last visitor. There's no upload parser written in C from the early 2000s.

That's not luck. It's the point of the architecture.

A traditional PHP site is one big box. The public pages, the admin area, the database connection and the file uploads all run in the same process, on the same server, open to the internet. When the language runtime underneath has a hole, everything on that box is exposed at once.

A headless build splits those apart. Public pages are mostly static files on a CDN. The admin lives somewhere else. The database only answers requests it has rules for. A flaw in one layer doesn't hand over the keys to all of them.

None of this makes a site unhackable. Nothing does. Node has had its own bad weeks and so has every other runtime. The difference is how much of your stack is sitting on the open internet, and how much of it is yours to keep patched.

PHP isn't the villain

I want to be fair here. PHP runs a huge share of the web and the core team handled this well. They warned people a day ahead, gave Linux distributions the patches early, and shipped fixes for every supported branch at once. I've built plenty on PHP, including years of Magento work, and I'll keep supporting clients who run it.

But look at the pattern. Patchstack logged 11,334 new vulnerabilities in the WordPress ecosystem alone in 2025, up 42% on the year before. For the ones attackers went after hardest, the median time from disclosure to first exploit was five hours. Five hours. If your plan for security is "the developer updates things when they get round to it", that plan stopped working a while ago.

Every PHP site needs someone watching it. Core, plugins, extensions, the PHP version itself, the server. That's a permanent cost, and weeks like this one are when you pay it.

Is it time to move?

If you've got a brochure site, a small shop or a booking system running on PHP, it's a fair question to ask this week.

Moving doesn't have to mean a six-month rebuild. Most small business sites are content, a few forms, maybe products or bookings. HD CMS starts from £20 a month, which covers hosting and updates, and if you're on WordPress I'll convert your site for free. The content comes across, the URLs stay the same so you keep your rankings, and you stop being the person who has to read CVE advisories over breakfast.

If you're on a bigger PHP platform like Magento, moving is a bigger job, and patching comes first. But it's worth starting the conversation now rather than after the next one.

Need a hand?

Whether you need this patch done today or you want to talk about getting off PHP for good, get in touch. I'll tell you honestly which one makes sense for your site.