Two critical PHP flaws: what to patch and how to verify it

The fixes are available

PHP released emergency updates on October 21, 2026 for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2 and can allow an attacker to run code without signing in. If you operate a PHP website, check its runtime and apply the security update now. The PHP team’s release advisory is the starting point.

This includes sites running WordPress, Laravel, Drupal, or a custom PHP application. The update belongs to the PHP installation beneath the application. A plugin update or a clean Composer audit does not establish that the interpreter has been patched.

A Linux vendor may fix an older package without adopting one of those upstream numbers. For example, Ubuntu notice USN-8948-1 lists 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04 LTS and 8.1.2-1ubuntu2.28 for Ubuntu 22.04 LTS. Compare the complete installed package revision with the notice for your exact operating-system release. A bare “PHP 8.3.6” is insufficient evidence either way.

What the two flaws do

CVE-2026-109618 concerns out-of-memory handling. PHP can abandon an operation while its request data is only partly initialized. Cleanup then encounters invalid memory. The official technical advisory describes an unauthenticated remote-code-execution demonstration against Apache’s mod_php, using normal input and memory limits. The vulnerable sequence can happen during request startup, before the application runs.

CVE-2026-109619 concerns state left behind between requests. A worker can retain a reference to memory from a finished request after that memory has been freed. A later request reaching the same worker can use the stale reference before normal initialization clears it. The second advisory documents several paths, including session upload progress and PHP 8.5 fatal-error backtraces.

Read the diagram explanation

• Request A. An interruption or cleanup error can leave request-owned state reachable by the worker.
• Request boundary. The request memory is freed while the worker retains a reference to it.
• Request B. A later operation on the same worker can consume the stale state before normal initialization resets it.

Server configuration affects which paths are reachable. PHP identifies Apache with mod_php as the highest-risk setup, but its update guidance also covers PHP-FPM, CGI, FrankenPHP, and LiteSpeed. Using FPM is not a reason to defer the patch: the stale-state advisory includes a validated FPM path that depends on application behavior.

Find the PHP serving each site

Start with a list of hostnames and the service behind each one. Include staging sites, old subdomains, admin tools, and applications inside containers. For every entry, record the PHP branch, full package revision or image digest, handler, owner, and patch evidence. A hostname that redirects to your main site may have a different origin behind it.

If your hosting company manages PHP, ask for a precise answer:

If you manage the server, php -v is a useful first check. It identifies the binary your shell found. The website may use a separate FPM pool, an Apache module, a different control-panel version, or PHP inside a container. Check the service mapping as well as the package manager.

<?php
printf("PHP=%s SAPI=%s\n", PHP_VERSION, PHP_SAPI);

Download the two-line check, save it as runtime-check.php, and run php runtime-check.php to identify the command-line runtime. For the website, execute the same expression inside an existing authenticated diagnostics route, or ask your host for equivalent evidence. Keep diagnostics private and remove any temporary handler afterward. A public phpinfo() page discloses much more than this check needs.

PHP’s version reference and SAPI reference explain these runtime identifiers. Typical SAPI values include cli, fpm-fcgi, and apache2handler. Neither a version string nor a SAPI value proves a distribution backport is installed; retain the package or image evidence too.

Patch, replace workers, and check again

Use your hosting provider’s, distribution’s, or image maintainer’s update instructions. If you use a custom image, rebuild it with the fixed runtime and deploy the new artifact. Pulling an image onto a host does not replace a running container. Docker’s Compose documentation describes how changed images are applied when services are recreated.

Replace or restart the PHP workers through the normal service deployment procedure, then repeat the runtime and package checks against every serving instance. Behind a load balancer, a healthy response from one node leaves the others unverified. Record the deployed artifact and rollout completion rather than relying on a handful of requests landing on different workers by chance.

After deployment, exercise a few real application paths: sign-in, a page that reads the database, a form submission, and a normal upload if the site supports it. Check error logs and worker health. These are compatibility checks; successfully loading the homepage does not establish that a security fix is present.

A useful completion record is short: hostname, runtime/package or image, advisory reference, rollout time, worker replacement confirmation, and application checks. Keep the old artifact for diagnosis, but remember that rolling back to a vulnerable runtime reopens the issue.

If you cannot patch immediately

Configuration changes can reduce exposure to particular paths. Both technical advisories say they are incomplete. Disabling session.upload_progress.enabled and restarting workers blocks the confirmed early-session paths; on PHP 8.5, disabling fatal_error_backtraces blocks another confirmed path. Other stale-state paths remain. See the full stale-state mitigation guidance before treating any of these as protection.

The out-of-memory advisory also discusses enforcing memory_limit=-1 alongside frontend request limits and external memory boundaries. Removing PHP’s memory cap has availability consequences, and underlying allocation failures can still reach vulnerable behavior. That change needs an operator who understands the service’s resource limits; it is not a universal copy-and-paste fix.

If no patched build is available, restrict access at a layer before requests reach PHP while you arrange one. Account for direct-origin access as well as the public hostname. An application-level maintenance page may run too late for a startup vulnerability. Choose a maintenance window or access restriction that actually prevents untrusted requests from reaching the affected runtime.

Give a coding agent an evidence-based task

A coding agent can help locate Dockerfiles, package pins, service configuration, and deployment checks. Give it a concrete acceptance condition so it does not stop after changing a version in the repository:

Inventory the PHP runtimes used by this project and deployment.
For each, identify the package revision or image digest and the
official evidence that both CVE-2026-109618 and CVE-2026-109619 are fixed.
Propose the update and worker replacement steps.
Show how we will verify the runtime serving actual web requests.
Report unknowns explicitly. Do not treat a CLI check, dependency audit,
or edited Dockerfile as proof that production has been patched.

The PHP Foundation’s account of the release is worth reading after the operational work. It traces early signs of the out-of-memory problem to 2024, later reports from Calif, OpenAI, and Wiz, and the difficult compatibility and performance decisions behind the patch. Finding the bug was only part of the work. Experienced maintainers still had to produce and coordinate a fix that the PHP ecosystem could deploy.