The PHP project's own advisory is titled "update now". That's about as blunt as software announcements get, so it's worth taking at face value.

What's actually been fixed

There are two bugs, CVE-2026-109618 and CVE-2026-109619. CERT-EU, the EU's cyber security team for its institutions, scores both at 9.2 out of 10. In plain English:

  • The first is about what happens when a request runs out of memory at the wrong moment. PHP can be left holding half-built internal data that it then treats as valid.
  • The second is about leftover state. Data from one request can survive after its memory has been freed, and a later request handled by the same worker can trip over it.

Both can lead to remote code execution. That's the worst kind of bug: someone on the internet gets to run whatever they like on your box.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older on those branches is affected.

Who needs to worry

The short answer is anyone serving web pages with PHP. The advisory lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It says the risk is highest for mod_php, where a demonstrated exploit works with no login and fires before any of your application code runs.

That last bit matters. It means your own code being tidy and well written doesn't save you. The problem sits underneath it.

So that's WordPress sites, WooCommerce shops, Magento stores, Laravel and CodeIgniter apps, the internal admin system someone built in 2015 and nobody's touched since. CERT-EU also points out that commercial and open-source products that bundle PHP may be affected, so it's not only things you'd think of as "a PHP site".

If you're on Shopify, your storefront itself isn't running on your PHP. But it's worth asking whether any custom app, stock sync, feed or middleware sitting alongside it is.

CERT-EU says initial proofs of concept "have begun to circulate". In other words, the clock is running.

What to do this week

1. Find out what you're running. Make a list of every server, site and app that uses PHP, and the exact version on each. Be careful here: the version you get from typing php -v on the command line isn't always the one serving your website. Check what the web server is actually using.

2. Update to the fixed version. The PHP project says Linux distributions and long-term support vendors were given the patches in advance, so updated packages should be available from your usual source. If you're on shared or managed hosting, ask your host directly whether they've applied it. Don't assume.

3. Restart properly. PHP-FPM and Apache workers keep running the old code until they're restarted. Patching the package and walking away isn't the same as being patched.

4. Check it worked. Confirm the new version number from the web side, not just the command line. Then click round the site and make sure nothing has fallen over.

If you're on an old version of PHP

This is the awkward one. PHP 8.1 and older no longer get updates from the PHP project. Given how serious these bugs are, the PHP security team has published minimal source backports for 7.4, 8.0 and 8.1. Those are aimed at people who build PHP from source, though, and plenty of small businesses don't.

Some distributions and LTS vendors also provide backported fixes, so check with yours. Otherwise the advice from both PHP and CERT-EU is to upgrade to a supported version.

It's also worth knowing that PHP 8.2 reaches end of life on 31 December 2026. If you're patching 8.2 today, you've got about ten weeks before you're in the same boat as 8.1. Upgrading PHP isn't always a five minute job on older code, so it's better planned now than rushed in January.

If you can't update straight away

The PHP project lists some configuration changes that reduce exposure. These include turning off session upload progress, lowering the maximum POST size, changing how the memory limit is set, and on PHP 8.5 switching off fatal error backtraces. Each one needs every worker restarting.

I'd stress that they're not a fix. The release notes put it plainly:

There are no complete mitigations, updating is the only safe choice.

CERT-EU goes a step further. Where patching isn't immediately possible, it suggests organisations consider taking internet-facing apps off the public network until a fix is in and verified. That's a big call for a business that takes orders online, but it tells you how seriously the people whose job this is are treating it.

If you do apply the stopgaps, put a date in the diary for the real update and stick to it.

The bigger lesson

Nobody plans to run an unpatched server. It happens because the developer who set it up has moved on, or the hosting login is in someone's old email, or everyone assumed someone else was doing it. Weeks like this one are when that gap shows.

The fix is boring, and that's the point. Know what you're running. Have someone responsible for keeping it up to date. Plan version upgrades before the deadline rather than after it. None of it is clever, but it's the difference between a calm afternoon of patching and a very bad week.

Need a hand?

If you're not sure what version your sites are on, or you know they're on something old and you're not sure where to start, we can help. We look after Linux servers for small businesses, including patching and moving systems off unsupported software. For inherited PHP apps, our legacy code audit tells you what you've got and whether to stabilise, upgrade or rebuild. And if you'd rather someone just kept on top of it every month, that's what our support and maintenance plans are for.

Drop us a line and we'll have a look.

Cheers, Rob