Two critical vulnerabilities in PHP can enable unauthenticated remote code execution. CVE-2026-109618 and CVE-2026-109619, collectively referred to as PHP2Shell, affect the PHP runtime itself. Both carry a CVSS v4.0 score of 9.2.
PHP released security updates on October 21, 2026. For teams running PHP in production, the priority is to identify affected builds, apply the appropriate fixes, and verify that the updated runtime is deployed.
What are the vulnerabilities?
CVE-2026-109618: Remote code execution through out-of-memory corruption
This vulnerability involves PHP's handling of memory allocation failures. Under certain conditions, an out-of-memory event leaves internal request data partially initialized. Subsequent cleanup operations can act on that invalid state, potentially enabling remote code execution.
Specially constructed multipart HTTP requests can trigger the vulnerable path. PHP identifies Apache deployments using mod_php as particularly concerning because the demonstrated attack path can execute before application code runs.
CVE-2026-109619: Remote code execution through stale global state
This vulnerability involves internal state that retains a reference to memory after it has been freed. A subsequent request handled by the same worker can encounter the stale reference before normal initialization resets it.
The two vulnerabilities have different technical causes, but the remediation principle is the same: updating application code alone does not fix a vulnerable PHP runtime.
Which deployments are affected?
PHP warns that installations serving web requests may be affected, including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed.
The attack conditions differ by vulnerability and server interface. Although PHP documents a particularly concerning attack path for mod_php, other configurations should not be considered safe without reviewing the relevant advisory.
Official technical references:
Which PHP versions contain the fixes?
PHP released patched versions for its four supported branches on October 21.
PHP branch | Fixed version |
PHP 8.5 | 8.5.12 |
PHP 8.4 | 8.4.27 |
PHP 8.3 | 8.3.36 |
PHP 8.2 | 8.2.35 |
The PHP security team also provided minimal source backports for PHP 7.4, 8.0, and 8.1. Users relying on the volunteer-maintained rpms.remirepo.net repository were advised to switch to distribution packages or build PHP from source to obtain the fixes promptly.
Linux distributions and long-term-support vendors may provide their own backported fixes. Check the relevant vendor's security tracker and package revision rather than relying on the upstream version number alone.
See the official PHP security release advisory for details.
What should teams do now?
1. Identify the runtime. Inventory production PHP deployments, including container images and third-party packages. Record the version, package source, server interface, and image digest where applicable.
2. Update to a fixed build. Upgrade PHP or install a vendor package containing the relevant fixes. For containers, rebuild or replace affected images, redeploy them, restart the relevant workers, and verify the running version and image digest.
3. Use temporary mitigations only when necessary. PHP documents configuration changes that can reduce exposure to specific attack paths, but these are not complete fixes. For CVE-2026-109618, the advisory discusses administratively enforcing memory_limit=-1 and limiting request and multipart input sizes. For CVE-2026-109619, it recommends disabling session upload progress before request parsing; PHP 8.5 also has a mitigation for a confirmed fatal-backtrace path. These measures have limitations and must be applied as documented by PHP.
Do not use RLIMIT_AS or RLIMIT_DATA as mitigations for CVE-2026-109618. PHP warns that they can trigger the vulnerable allocation-failure path. If immediate patching is impossible, consider isolating affected services from public access while remediation is underway.
4. Verify remediation. Confirm that the corrected runtime is actually serving requests. Review relevant logs for suspicious activity and investigate potential compromise where exposure may have occurred.
CleanStart: A hardened PHP image with the security fixes
A minimal container image can reduce unnecessary components, but it cannot fix a vulnerability in the PHP runtime. The runtime itself must contain the appropriate security updates.
CleanStart is releasing an updated PHP container image incorporating the applicable fixes for CVE-2026-109618 and CVE-2026-109619.
The updated image is intended to provide a hardened, verifiable foundation for containerized PHP applications. Before deploying it, confirm the published image version and digest, check application compatibility, and verify that the updated runtime is running across affected environments.
The bottom line
PHP2Shell reinforces a basic principle of software supply chain security: reducing attack surface is not the same as fixing vulnerable software.
Identify the PHP build, apply the appropriate fix, and verify what is running in production. A hardened image can provide a stronger foundation, but remediation depends on deploying a corrected runtime.
