Critical PHP updates: close the exposure, then prove the fix

PHP released fixes on 21 October 2026 for CVE-2026-109618 and CVE-2026-109619. Both can allow unauthenticated remote code execution. The immediate task is to identify exposed PHP runtimes, apply a verified fix and confirm that running applications actually use it. [1][2]

What the PHP project confirmed

CVE-2026-109618 concerns corruption during out-of-memory handling. CVE-2026-109619 concerns stale request state retained by a worker. The PHP project says installations serving web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies mod_php as the highest-risk configuration. [1][3][4]

These are runtime vulnerabilities. Updating a CMS, plugin or application dependency is not evidence that the PHP runtime has also been patched. Check the runtime used by each deployed service, rather than relying only on a developer workstation or an inventory label.

Fixed upstream releases

The following releases contain the fixes announced on 21 October. Use a later supported security release if one is available when you act. Distribution and LTS packages may carry backported fixes; verify the vendor advisory and package build rather than judging a package by its upstream version alone. [1][2]

PHP 8.1 and older are outside upstream support. Check your distribution or LTS vendor for a confirmed backport, or plan a move to a supported branch. [1]

A practical response checklist

• Scope the estate: public applications, internal services, containers, scheduled jobs and third-party products that embed PHP. Name the owner of each service.
• Prioritise exposure: identify public entry points and business-critical services. Make patching and temporary isolation decisions with the service owner.
• Validate the package: confirm that the selected release or vendor build contains the fixes. Test essential application flows and agree rollback criteria.
• Deploy completely: update images and hosts, redeploy affected workloads, and restart the relevant workers under the approved change procedure.
• Verify the running state: check the version or vendor build inside the actual application runtime. Confirm that old workers and outdated replicas are no longer serving traffic.
• Retain evidence: record the advisory, affected assets, deployed build, verification result, exceptions and the person accepting any remaining risk.

Temporary measures are not a complete fix

The PHP project states that only an update fully resolves these vulnerabilities. Its advisory describes configuration measures for particular attack paths, with important limitations. Read that guidance before changing memory or request handling settings; copying an isolated setting into production can introduce a different failure. CERT-EU recommends considering isolation of internet-facing services when immediate patching is not feasible. [1][2]

Keep patching and incident investigation separate. A successful update does not establish whether a system was previously compromised. If there are signs of unexpected execution, altered files or suspicious requests, preserve relevant evidence and involve the incident response owner.

What a useful close-out record contains

For each service, retain a short record: asset and business owner, exposure, runtime before the change, fixed package or build, deployment reference, running-state verification and any unresolved exception. Set an expiry or review trigger for every temporary exception.

This turns an urgent advisory into an accountable decision. The useful outcome is a verified change in exposure, with enough evidence for another person to check it.