What we did about October's PHP vulnerabilities.

On 21 October, PHP released fixes for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both let an attacker who isn’t logged in run their own code on a web server running PHP, and both were rated 9.2 out of 10.

The first is triggered by running PHP out of memory partway through a request, which an attacker can do with a carefully built upload. The second lets one request leave memory behind that the next request on the same PHP worker then uses. It works through session upload progress, a PHP feature that’s turned on by default.

The NCSC published an alert the same day. It said to update PHP straight away, and where that, or the temporary mitigations, couldn’t be done quickly, to consider taking the site offline until it could be. That told us how serious this was expected to be.

Within a couple of hours

When the advisories came out, most of the fixed PHP builds weren’t available to install yet. The Ubuntu packages and Docker images we install from followed later. So we started with configuration.

Once we had read the advisories and seen the published proofs of concept, we changed the PHP configuration on every server we have access to. We turned off session upload progress and tightened the limits on request input, which closed the routes the known exploits use. The changes were in place within a couple of hours of the release.

That evening

By the end of the day, we had deployed the updated versions of PHP to all of our own sites and to every client project we look after under a maintenance agreement. We also scanned the logs on every PHP server for signs that anyone had tried the attack. We found none.

The following days

Some clients run older websites that aren’t covered by a maintenance agreement with us. They ask us now and then to add a feature or fix something, so we still had access to their servers, but some of those servers ran an operating system that no longer gets PHP updates. Over the next few days, we contacted each of them and helped them update PHP on their existing server, or move the site to a new server that could take the fix.

If you have a PHP site that nobody is looking after, check which version of PHP it runs. PHP only made new releases for 8.2 and later. Older versions depend on whoever packages PHP for your server, and some servers will never get the fix. If yours can’t be updated, the NCSC’s advice applies: mitigate it, or take it offline until you can.

If you’d like us to look after your servers and applications, read about our maintenance and security work or get in touch.