On October 21, 2026, the PHP team released security updates for PHP 8.5, 8.4, 8.3, and 8.2.
The updates fix two critical vulnerabilities that can lead to remote code execution (RCE) without authentication.
If you maintain a PHP application or operate a server that handles PHP requests, check your PHP version and plan to update immediately.
Official advisory: PHP Security Advisory — October 21, 2026
TL;DR
- Two critical vulnerabilities affect PHP installations that handle web requests.
- Both can potentially allow an attacker to execute code on the server without logging in.
- The PHP team has released patched versions: 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
- Configuration changes can reduce exposure to some attack paths, but updating is the only complete fix.
Which versions should you update to?
Use the patched version corresponding to your current release branch.
| Current branch | Patched 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 team recommends that users update as soon as possible.
These vulnerabilities are particularly concerning because an attacker does not need valid application credentials to trigger the affected code paths.
The advisory covers PHP deployments that process web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.
The PHP team also identifies mod_php as the highest-risk configuration, citing a demonstrated exploit in which an unauthenticated request can trigger the attack before application code runs.
What are the vulnerabilities?
The two issues have separate root causes.
1. CVE-2026-109618: Remote code execution through out-of-memory corruption
The first vulnerability involves how PHP handles memory allocation failures during request processing.
When PHP processes a request, it initializes internal data structures that are later used to handle and clean up that request.
Under certain memory-allocation failure conditions, request processing can be interrupted while some of those structures are only partially initialized. During cleanup, PHP may then treat invalid or incomplete data as valid.
This inconsistent state can lead to memory corruption and potentially remote code execution.
The key issue is not simply that PHP runs out of memory. It is that the error-handling and cleanup paths can operate on internal request data that was never fully initialized.
Advisory: CVE-2026-109618
2. CVE-2026-109619: Remote code execution through stale global state
The second vulnerability concerns internal state that belongs to an individual request.
PHP may reuse a worker to process multiple requests. When a request finishes, its associated memory and state must be cleaned up correctly before the worker handles another request.
In the vulnerable code, some request-owned internal state can survive after the memory it refers to has been freed. A subsequent request handled by the same worker may use that stale state before normal initialization resets it.
This creates a use-after-free-like failure in the request lifecycle and can potentially lead to remote code execution.
The important distinction is that the problem involves state surviving beyond the lifetime of the request that owned it.
Advisory: CVE-2026-109619
What should you do?
1. Update PHP first
Upgrade to the patched release for your branch:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
For installations managed by a Linux distribution or hosting provider, check for updated vendor packages. Some vendors distribute fixes through their own package channels.
You can find the official downloads here:
After updating, verify the version used by the actual web-serving environment. The PHP version shown by a command-line executable may differ from the version used by PHP-FPM or a web server.
Also check every relevant runtime and deployment environment, including containers and production workers.
2. If you cannot update immediately
The advisory describes temporary measures that can reduce exposure to specific attack paths. These are defense-in-depth measures, not substitutes for patching.
For CVE-2026-109618, the recommendations include:
- Removing the controllable PHP memory-limit failure path by setting
memory_limit=-1, where appropriate and enforced through server-level configuration. - Restricting request and upload sizes with
post_max_sizeand appropriate web-server or proxy limits. - Applying container or cgroup memory limits as an availability boundary.
These settings need careful review. For example, removing PHP's memory limit does not prevent every possible allocation failure, and external resource limits still need to be designed to avoid introducing other risks.
For CVE-2026-109619, the advisory recommends disabling session upload progress through session.upload_progress.enabled=0 and restarting all affected workers. On PHP 8.5, setting fatal_error_backtraces=0 also blocks one confirmed attack path.
These measures cover specific paths only. They do not eliminate the underlying vulnerabilities.
See the official advisory for the complete configuration guidance and limitations.
What about older PHP versions?
PHP 8.1 and older no longer receive regular security updates directly from the PHP project.
Some Linux distributions and long-term support vendors may provide backported patches. If you run an older version, check the security status of your specific distribution or vendor package rather than assuming that the upstream version number tells the whole story.
The PHP security team has also provided minimal source backports for PHP 7.4, 8.0, and 8.1 to help people building from source or working without access to an LTS vendor.
PHP 8.2 reaches end of life on December 31, 2026. Even after applying this patch, plan to move to a supported release branch.
Final thoughts
These vulnerabilities are a reminder that security problems do not always originate in application code.
A PHP application may validate user input correctly and still be exposed if the underlying runtime contains a flaw that can be triggered during request processing.
The immediate priority is straightforward: identify the PHP runtime that handles your web traffic, install the appropriate patched release, and verify that the running workers use it.
Configuration-level mitigations may help reduce risk while an update is being prepared, but they are not a complete solution.
For the technical details and the latest remediation guidance, refer to the official PHP security advisory.
Top comments (0)