Introduction

On 21 October 2026, the PHP development team published security updates addressing two critical vulnerabilities in the PHP runtime: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 (Critical) under CVSS v4.0 and can lead to unauthenticated remote code execution (RCE). Exploitation has been demonstrated against Apache with mod_php; the PHP security advisories also document a validated PHP-FPM exploitation path for CVE-2026-109619.

Security-fixed versions are available now: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CIRCL strongly recommends updating affected PHP runtimes immediately. The PHP project emphasises that configuration workarounds do not provide complete protection.

These vulnerabilities affect the PHP runtime itself, not a particular application. Updating WordPress, Drupal, Joomla or another PHP-based application without updating its underlying PHP runtime is not sufficient.

Technical details

CVE-2026-109618 — RCE via out-of-memory (OOM) corruption

PHP can use longjmp() to abort processing when an out-of-memory condition occurs. If an allocation fails while internal request structures are only partially initialised, the early exit can leave those structures in an invalid state. Subsequent request cleanup may then read or act on that invalid state, potentially enabling RCE.

According to the upstream security advisory, crafted HTTP multipart input can cause memory exhaustion through several mechanisms, including requests without a usable declared content length, unusually large numbers of multipart headers, and nested or empty file fields that generate disproportionate in-memory structures. Application-specific memory exhaustion paths may also exist.

Unauthenticated RCE has been demonstrated with Apache mod_php, where the vulnerable sequence can occur during request startup, before any PHP application code executes. PHP-FPM is considered susceptible under other conditions, although the upstream advisory does not report a complete PHP-FPM exploit for this particular CVE. FrankenPHP is considered likely susceptible, while LiteSpeed/LSAPI may require application-specific conditions.

CVE-2026-109619 — RCE via stale global state

Request-owned internal PHP state can remain referenced by a persistent worker after the request’s memory has been freed. A later HTTP request processed by the same worker may access that stale state before normal request initialisation resets it, leading to use-after-free and potentially RCE.

The upstream security advisory identifies confirmed paths involving session upload-progress handling and, on PHP 8.5, fatal-error backtrace state. Fatal errors, execution timeouts, and certain warnings or invalid/deprecated configuration directives can contribute to the sequence. Exploitation of the stale state requires a suitable producer and a subsequent consumer, which may be in separate HTTP requests.

Unauthenticated RCE has been demonstrated against Apache mod_php; the session upload-progress path has also been validated against PHP-FPM under suitable application conditions. Other affected internal state and extension paths may exist.

Affected Systems

PHP’s 21 October 2026 security announcement identifies all PHP installations serving web requests as potentially at risk, including deployments using PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest confirmed risk is for Apache mod_php, because an unauthenticated request can trigger a demonstrated attack before application code starts.

The following PHP releases contain fixes for both CVEs:

PHP branch	Security-fixed version	Earlier releases in the branch
PHP 8.5	8.5.12	Update immediately
PHP 8.4	8.4.27	Update immediately
PHP 8.3	8.3.36	Update immediately
PHP 8.2	8.2.35	Update immediately

PHP 8.1 and older are no longer supported by the PHP project and do not receive normal upstream security releases. They should not be regarded as safe merely because no new official point release exists. Organisations using legacy versions should upgrade to a supported branch or obtain a verified, maintained vendor backport. In view of the severity, the PHP security team has exceptionally made minimal source backports available for PHP 7.4, PHP 8.0 and PHP 8.1, intended for source builders or those without access to an LTS vendor. These branches are not a restoration of regular upstream support.

Particular attention should be given to:

Internet-facing websites, APIs and applications, regardless of whether they use PHP-FPM, mod_php or another supported interface (SAPI).
Shared hosting and multi-tenant environments with persistent PHP workers.
Content management systems, e-commerce platforms and administrative interfaces implemented in PHP.
Containers, virtual-machine images, appliances, hosting control panels and third-party products bundling their own PHP runtime.

Do not rely solely on a PHP version string. Linux distributors and long-term-support vendors may backport security fixes without adopting the new upstream version number. Check the vendor’s security advisory, package changelog and installed package build to establish whether both CVEs are fixed.

Mitigation

Applying the security update is the only complete mitigation. The configuration and network measures below are temporary ways to reduce exposure to particular attack paths; none makes an unpatched installation safe. Because the two vulnerabilities have different root causes, measures directed at one CVE must not be assumed to protect against the other.

1. Identify and prioritise exposed assets — immediately

Inventory all PHP runtimes, including those in containers, appliances, control panels and managed hosting services.
Prioritise publicly reachable services accepting untrusted HTTP requests, especially Apache deployments using mod_php.
Identify the actual running PHP version and SAPI for each web application; the PHP command-line version may differ from the interpreter used by the web server.
Contact hosting providers, Linux distributors and product vendors to confirm the availability and deployment of security fixes.

Useful first-pass inventory commands on Linux include:

1
2
3
4
5


php -v
php --ini
# Depending on distribution and installed PHP versions:
php-fpm -v 2>/dev/null || true
ps -ef | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'

These are inventory aids only. They do not establish whether the web-facing PHP runtime is patched, whether vendor backports have been applied, or whether a service is exploitable.

2. Apply vendor security updates now

Upgrade immediately to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, as appropriate for the installed supported branch. Use official PHP downloads or Windows downloads where relevant.
On Linux distributions or vendor-maintained installations, install the vendor’s patched packages and verify that the vendor explicitly addresses CVE-2026-109618 and CVE-2026-109619.
Update every deployed PHP runtime and PHP-FPM pool, including separately packaged or embedded versions, not just the default command-line interpreter.
Restart all affected PHP workers and, where necessary, their web-server or application-service processes. Verify that new web requests are handled by the patched runtime; merely updating files on disk is insufficient if old workers remain active.
For PHP 8.1 and older, prioritise migration to a supported branch. If migration is not immediately possible, assess documented distributor/LTS backports or the PHP project’s exceptional source-backport branches for PHP 7.4, 8.0 and 8.1.
Record patch status, vendor advisory reference, running build and restart verification for each affected asset.

Package availability note (21 October 2026): The PHP security team states that the volunteer-maintained rpms.remirepo.net repository will not have these updates on the release day. Administrators depending on it should plan to use distribution-maintained packages or build a patched PHP runtime from source rather than assume that repository is immediately updated.

3. Reduce exposure if immediate patching is impossible

Temporarily restrict non-public PHP applications to trusted networks or an authenticated VPN. For high-risk internet-facing services that cannot be updated, consider safe isolation or temporary removal from public access according to business criticality. A web application firewall or ordinary authentication control must not be treated as a complete fix for a flaw that can be triggered during PHP request processing.

Temporary measures for CVE-2026-109618 (OOM corruption)

Set memory_limit=-1 as an administrator-enforced setting where technically and operationally feasible, for example with php_admin_value in a PHP-FPM pool or the equivalent Apache configuration. Confirm that no pool, directory or application setting restores a finite limit, and restart affected workers. This removes the predictable PHP memory-limit failure underlying the confirmed attack, but low-level allocation failures can still trigger the vulnerable path. Removing PHP’s per-request memory limit also increases resource-exhaustion risk and requires particular operational care.
Constrain request sizes. For applications without file-upload requirements, use a conservative post_max_size = 8M; where uploads are needed, consider post_max_size = 32M and keep upload_max_filesize below post_max_size. Adjust these suggested values to actual application requirements. Independently limit decoded request-body size, input field count, multipart part count, multipart headers, uploads and nesting depth at the frontend or proxy. Enforcement must cover requests without a usable Content-Length. Where multipart processing is unnecessary, block it before it reaches PHP.
Use container/cgroup memory limits as an availability boundary, preferably with a worker-isolation policy that terminates only the affected worker rather than the entire service. These limits are not a complete security mitigation and do not guarantee that allocation failure is avoided. Do not substitute RLIMIT_AS or RLIMIT_DATA: these may cause memory-allocation failures that reach the vulnerable code path.

Temporary measures for CVE-2026-109619 (stale global state)

Set session.upload_progress.enabled=0 and restart every PHP worker. Apply it in php.ini, PHP-FPM pool or appropriate server configuration before request parsing; do not rely on ini_set() or PHP-FPM .user.ini. This blocks the confirmed session upload-progress paths, not other variants. This measure may be useful even where an application never explicitly starts a session.
For PHP 8.5, set fatal_error_backtraces=0 administratively and restart every worker. This blocks the confirmed fatal-error backtrace path, not other stale-state paths.
Remove invalid, deprecated or conflicting PHP settings applied per request that produce warnings or other diagnostics before normal initialisation. Suppressing diagnostic output using error_reporting, display_errors, log_errors or @ is not protective because the vulnerable state can be accessed before PHP decides whether to report the diagnostic.
Fix attacker-reachable fatal errors and execution timeouts, including faults in callbacks, upload/import handling, destructors, shutdown processing and extensions. Investigate warnings emitted during request cleanup as well. These steps lower the risk of particular producer/consumer sequences but cannot exclude all such sequences.

Important: Do not disable the PHP handler while leaving PHP source files directly accessible through the web server: a misconfiguration could expose application source code and credentials. When taking a service offline, use a safe maintenance response, network restriction or equivalent mechanism.

4. Increase monitoring and investigate suspicious activity

The upstream advisories establish exploitable mechanisms, but they do not provide a universal list of network indicators of compromise. Investigate behaviour that may be consistent with exploitation, including:

Unusual POST or multipart requests, requests to endpoints that do not normally accept uploads, and references to PHP_SESSION_UPLOAD_PROGRESS where request-body inspection is available.
Excessive multipart fields or headers, malformed or missing content lengths, unusually nested form fields or anomalous request-body sizes.
PHP or web-server worker crashes, unexpected restarts, memory-exhaustion events and OOM-killer activity, particularly when correlated with suspicious HTTP traffic.
Fatal errors, execution timeouts, startup diagnostics, deprecated or invalid PHP INI directives, and warnings during extension or request cleanup.
Unexpected child processes launched by PHP or web-server workers, unauthorised changes to web files or scheduled tasks, unusual outbound connections, or suspicious access to credentials.

These observations are hunting leads, not validated IOCs, and their absence is not proof that an unpatched runtime is safe. Preserve relevant web, PHP, application and host logs when compromise is suspected. Assess possible memory disclosure and execution with the privileges of the affected web worker; investigate before simply restarting or rebuilding affected systems.

Exploitation status

The PHP security advisories published on 21 October 2026 document successful, validated unauthenticated RCE: for CVE-2026-109618 against Apache mod_php, and for CVE-2026-109619 against Apache mod_php and PHP-FPM in the described conditions. These are confirmed exploit demonstrations, not evidence by themselves of widespread exploitation in the wild.

Reports of suspicious activity and possible early attack attempts preceded the official release. However, the availability of working exploit paths should be distinguished from independently verified compromises of specific organisations. Organisations should not wait for evidence of exploitation in their own environment before installing the fixes.

Guidance for organisations in Luxembourg

CIRCL strongly encourages organisations in Luxembourg to treat CVE-2026-109618 and CVE-2026-109619 as urgent security updates, especially where PHP serves public-facing HTTP requests. Confirm the actual deployed PHP runtime, apply security-fixed builds, restart all PHP workers, and verify deployment across web applications, hosting platforms, containers and managed services.

If immediate patching is not feasible, combine temporary network restrictions with the relevant CVE-specific measures above, understanding that none replaces patching. Organisations observing suspicious activity should preserve evidence, follow their incident-response procedures and contact the appropriate incident-response team, including CIRCL where applicable.

References

Classification of this document

TLP:CLEAR — Information may be distributed without restriction, subject to copyright controls.

Revision

Version 1.1 – TLP:CLEAR – Updated following PHP’s publication of security-fixed releases, technical advisories and temporary mitigations – 21 October 2026.
Version 1.0 – TLP:CLEAR – Initial version – 21 October 2026.

TR-102 Critical Remote Code Execution Vulnerabilities in PHP - CVE-2026-109618 and CVE-2026-109619