If you run a PHP site, check the runtime behind it. October’s security fixes deserve a slot ahead of the usual maintenance jobs.

Original editorial illustration. The issue sits in PHP itself, underneath the application.

There’s always another update waiting. A plugin needs attention, a container image is getting old, and the server still seems to be working. It’s easy to push one more maintenance job into next week.

This PHP release is worth interrupting that routine for. On 21 October, the PHP team released fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both can allow remote code execution without an attacker logging in. The affected software is the PHP runtime, so updating your website’s own code doesn’t settle the question. [1]

What actually went wrong?

The first flaw concerns what happens when PHP runs out of memory. A request can be interrupted while some internal data is only partly initialised. During cleanup, PHP may then use that unfinished data as though it were valid. Under exploitable conditions, that can lead to an attacker running code as the web worker account. [2]

The second flaw involves information left behind between requests. A worker can retain a reference to memory that belonged to an earlier request, even after that memory has been freed. A later request handled by the same worker can end up using the stale reference. The PHP advisory describes how this can also lead to remote code execution. [3]

Those descriptions sound fairly obscure. The practical concern is easier to understand: a server can be doing ordinary web-server work and still expose a dangerous bug below the application layer.

Does using PHP-FPM make you safe?

No. PHP’s warning covers installations serving web requests through PHP-FPM, Apache’s mod_php, CGI, FrankenPHP and LiteSpeed. The team considers mod_php the highest-risk setup, with a demonstrated attack that can trigger before application code starts running. [1]

That doesn’t mean every setup is equally easy to exploit. The technical advisories draw distinctions between server interfaces, configuration and reachable behaviour. It does mean “we use FPM” is a poor reason to skip the update. [2] [3]

There’s another reason to get on with it. Canada’s Cyber Centre reported that both CVEs were added to CISA’s Known Exploited Vulnerabilities catalogue on 26 October. Its updated alert also notes reporting of exploitation in the wild. This has moved beyond a hypothetical attack discussed in an advisory. [4]

Which versions contain the fixes?

These are the upstream releases that fixed the two 21 October vulnerabilities. Install these or a later supported release in the relevant branch. [1]

PHP branchFirst fixed release8.28.2.358.38.3.368.48.4.278.58.5.12

Distribution packages need a little care here. Vendors may backport fixes, so check their security notices and package revisions. Older branches need a supported upgrade or confirmed vendor fix. [4]

Updating the host is only part of the job when applications ship their own PHP runtime.

The easy thing to miss after patching

Make sure you’ve checked the PHP instance serving the website. A terminal’s php -v output is a useful starting point, but a machine can have multiple PHP installations. A hosting panel, FPM pool or container may be using a different one.

After updating, restart or redeploy the affected services and verify the running version through your deployment tools or a private diagnostic. Avoid leaving a public phpinfo() page behind. For managed hosting, ask the provider to confirm that the web-serving runtime has received the fixes.

The UK’s NCSC also recommends identifying PHP across the infrastructure, prioritising internet-facing systems and watching for updates to products that bundle it. If you cannot patch or mitigate promptly, its guidance includes considering taking the affected system offline. [5]

One follow-up advisory deserves a mention

On 23 October, PHP disclosed a separate issue, CVE-2026-115560, involving an unusual combination of session configuration and application behaviour. It wasn’t fixed by the 21 October releases. PHP recommends session.upload_progress.enabled=0 pending a fix. Applications that never change the session serialisation handler at runtime aren’t exposed to this vector. Review the separate advisory too. [4] [1]

Once the update is done, take a look at what happened before it. Unexpected files, processes or outbound connections deserve investigation. Patching closes a vulnerability; it doesn’t remove anything an attacker may already have installed. [5]

The useful next step is small: find out which PHP runtime your public site is using, and confirm its patch status. That’s a better answer than “the website still loads”.

Sources: [1] PHP announcements · [2] OOM advisory · [3] Stale-state advisory · [4] Canadian Cyber Centre · [5] UK NCSC.