PHP emergency patch: do you know who updates your server?

The samurai tried to switch his hosting panel to PHP 8.4 while wearing gauntlets. The site now runs on 5.6.

Which gives away the most important fact: your website's PHP version is a dropdown that somebody set at some point. This week is a good reason to find out who.

What happened

On 20 October the PHP project announced an emergency security release, and on 21 October it shipped: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two flaws (CVE-2026-109618 and CVE-2026-109619) that let attackers run their own code on the server without logging in. PHP rates each at 9.2 out of 10 under CVSS 4.0. PHP itself says only the update closes the hole completely. Configuration tweaks just slow attackers down.

The Canadian Centre for Cyber Security reported on 21 October that a proof of concept is reportedly circulating but no active exploitation had been identified. BleepingComputer reported the same day that Cloudflare's CTO had seen early attacks and rolled out temporary firewall rules. On 23 October PHP added a further notice: set session.upload_progress.enabled=0 until the next bugfix release.

Every PHP installation that serves web requests is affected. So very probably your website, if it runs on WordPress, Shopware, TYPO3 or any other PHP system.

The real problem isn't the flaw

Flaws happen. The problem is the question many companies can't answer afterwards: who installs the update?

The agency built the site. The host runs the server. Someone in marketing clicks the plugin updates. And PHP sits right in between. With managed hosting the provider usually updates it, with shared hosting you often pick the version yourself in the panel, and on your own server it's entirely yours. Our view: if it isn't agreed in writing, nobody is responsible.

Then there's age. PHP 8.1 and older no longer get updates from the PHP project. For 7.4, 8.0 and 8.1 there are only minimal backports this time, and some Linux distributions and LTS vendors patch old versions themselves. So an old version number doesn't automatically mean unpatched. It does mean you have to ask rather than hope.

Through his helmet's eye slit the samurai can read about one line of an advisory at a time. For PHP 8.1, one line is all it takes: no more updates.

And if you're on 8.2: security support for 8.2 ends on 31 December 2026. That's just over nine weeks away, right when everyone is on holiday.

This week's drill

1. Find out your PHP version. In your hosting panel it usually sits under "PHP settings", in WordPress under Tools → Site Health → Info → Server.
2. Email your host or agency exactly two questions: is our PHP patched, either to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or via a backport? And who is responsible for this from now on?
3. If you're on 8.2 or older, plan the move to 8.4 or 8.5 before the end of the year. Try it on a test copy first, because old plugins and themes like to break along the way.

And operate that dropdown without gauntlets.