PHP’s October 2026 emergency fixes: what 8.4.27 changes.

Two critical PHP engine flaws, one plain-language explanation: affected versions, discovery, server impact and how to verify the fix.

CyberLens Lab•Site publication: 22 Oct 2026•5 min read

The short version

Source checked: 22 October 2026. Advisory published: 21 October 2026.

PHP published emergency fixes for CVE-2026-109618 and CVE-2026-109619. Both can permit remote code execution without signing in. These are PHP engine problems, not simply an application displaying an error.

What caused the vulnerability?

For CVE-2026-109618, running out of memory could interrupt PHP while request data was only partly prepared. During cleanup, the engine could use that invalid state. Think of a workshop that starts dismantling a machine before its assembly checklist is complete.

The patch changes how memory exhaustion is handled: PHP can stop at a safe point, or terminate immediately when a higher limit is reached, rather than letting cleanup operate on incomplete state. Technical advisory: out-of-memory corruption.

For CVE-2026-109619, a worker could keep references to memory belonging to an earlier request after that memory was freed. A later request could use those stale references before normal initialization reset them. Imagine an old desk label pointing to a drawer whose contents have already changed. Technical advisory: stale global state.

How was it identified?

The PHP Foundation describes a sequence of audits and reports. A developer encountered early signs of the memory-exhaustion problem while addressing a finding from a 2024 Quarkslab audit. In August 2026, Calif and OpenAI independently reported the same root cause, followed by further research. Demonstrated attack paths established the seriousness of the issue. Discovery, reproducibility and impact validation are separate steps. PHP Foundation’s account.

Which systems are affected?

PHP says web-serving installations must be treated as exposed, including PHP-FPM, Apache mod_php, CGI, FrankenPHP and LiteSpeed. Its strongest demonstrated application-independent path is on mod_php, before application code runs. Exposure and reliability depend on deployment details; a PHP warning alone does not prove exploitation.

The upstream fixed releases are:

Branch	Fixed release
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Older branches need a supported upgrade or a vendor-confirmed backport. Distribution package revisions may contain a backport without matching these upstream version strings. Official PHP release advisory.

Why an older-looking vendor version can be patched

Ubuntu’s USN-8948-1 notice lists 8.5.4-0ubuntu1.5 as the fixed package for Ubuntu 26.04 LTS. It carries the security patches without adopting the upstream 8.5.12 version string. Compare the full vendor revision with the vendor notice, rather than relying on php -v alone.

What should a site owner do?

Arrange the vendor’s patched package, test compatibility, deploy it and restart the relevant workers. Verify the version of the web-serving runtime, not only the command-line executable: they can differ. Ask a managed host to confirm its patched package and service restart.

Updating is the complete remedy. Configuration workarounds are not equivalent to a fix. Hiding error messages does not repair the underlying memory handling.

Try the idea simply

Use the version comparison on this page with a manually supplied version. It compares against the published upstream minimums for these two CVEs; it does not scan a server or verify backported packages.

For a video, animate two trays labelled “current request” and “released memory.” Show why a leftover reference is unsafe, then show the patched lifecycle. Use diagrams and dummy values rather than sending exploit traffic. Label this as a model of the mechanism, not a reproduction of remote code execution.