On 21 October 2026 the UK National Cyber Security Centre (NCSC) published an alert titled “Critical security issue affecting PHP”. Two vulnerabilities in PHP itself may let an unauthenticated attacker achieve remote code execution (RCE) on a web server running PHP. Both are fixed in new releases.

If you run PHP, update first and read the rest later.

Summary

CVE-2026-109618CVE-2026-109619
TitleRCE via OOM corruptionRCE via stale global state
CVSS v4.09.2 (Critical)9.2 (Critical)
VectorAV:N/AC:H/AT:P/PR:N/UI:NAV:N/AC:H/AT:P/PR:N/UI:N
Weaknessuse-after-free, improper error handlinguse-after-free, stale global state

Both are reachable over the network with no login and no user interaction.

What is going on?

CVE-2026-109618: PHP uses longjmp() for out-of-memory (OOM) errors. If an allocation fails while request data is only partly initialized, request cleanup may treat the invalid data as valid. That leads to memory corruption and, under certain conditions, RCE. Known triggers involve multipart parsing: a request with no usable content length, an unrestricted number of headers per part, empty file controls that don’t count toward max_file_uploads, and nested field names.

CVE-2026-109619: In long-lived workers, global state (error, session, object and extension state) can keep pointing at request memory after it has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it, causing a use-after-free. Confirmed exploitation paths include PHP 8.5 with fatal_error_backtraces enabled and the session upload progress lifecycle.

What is affected?

Vulnerable versions:

  • PHP 8.2 before 8.2.35
  • PHP 8.3 before 8.3.36
  • PHP 8.4 before 8.4.27
  • PHP 8.5 before 8.5.12

Fixed versions: 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

The NCSC stresses that any organisation using PHP is affected, including products and appliances that bundle it. Unsupported versions older than 8.2 should be moved to a supported release too.

By deployment model (per the PHP team’s advisories):

  • Apache mod_php: exploitation validated over HTTP with default settings and normal prefork configurations.
  • PHP-FPM: susceptible according to source analysis, though no complete exploit has been demonstrated.
  • FrankenPHP and LSAPI: likely susceptible, not yet validated.

What to do

  1. Update. Upgrading to a fixed release is the only complete mitigation.

  2. Find every PHP install. Start with internet-facing systems, and don’t limit the search to old versions. Check containers, Docker images and bundled products (panels, CMSs, appliances). NCSC-NL published an inventory of software with a PHP dependency: NCSC-NL/php2shell.

  3. If you can’t update right away, apply these partial mitigations:

  • Set memory_limit=-1 administratively and restart all workers. Don’t use RLIMIT_AS or RLIMIT_DATA: they make mmap() fail and trigger the vulnerable path.
  • Keep post_max_size conservative and enforce request body size at the frontend (Nginx / load balancer).
  • Lower max_input_nesting_level and bound input variables, multipart parts, headers per part and uploads.
  • If your app doesn’t use multipart/form-data, block such requests at the frontend.
  • Set session.upload_progress.enabled=0, and on PHP 8.5 set fatal_error_backtraces=0. Then restart workers.
  • If performance doesn’t matter, pm.max_requests=1 in PHP-FPM removes state shared between requests.

  1. If neither updating nor mitigating is possible, the NCSC suggests taking the system offline.

  2. Check for compromise. If the system has been exposed, look for backdoors and unknown files or processes.

References