The PHP development team today released emergency security updates for all supported PHP branches — 8.2, 8.3, 8.4, and 8.5 — fixing two critical vulnerabilities rated CVSS v4.0 9.2. Both allow unauthenticated remote code execution. The PHP project gave advance notice on October 20 and released the patches on October 21 at 14:00 UTC.
The key line from the official advisory: there are no complete mitigations. Updating is the only safe choice.
This is not a "apply these WAF rules and monitor" situation. If you are running PHP and serving web requests, the action is to update.
The Two CVEs
CVE-2026-109618: RCE via Out-of-Memory Corruption
PHP enforces a configurable memory limit on request processing. When a request exceeds that limit, PHP triggers an out-of-memory handler to begin cleanup. The vulnerability is in how that cleanup happens: if the OOM condition fires while PHP's internal request data structures are only partially initialized, the cleanup code may encounter and process invalid data as though it were valid. An attacker who can trigger the OOM condition at the right moment — by crafting requests that push memory consumption to the limit — can reach this vulnerable cleanup path.The incomplete mitigation is to set memory_limit=-1, removing the configurable limit. This eliminates the controllable PHP memory limit failure path, but an underlying system-level allocation failure can still reach the vulnerable code. It reduces exposure; it does not eliminate it.
Additional hardening measures that narrow the attack surface include setting a low post_max_size (8MB for applications without file uploads, 32MB if uploads are required), enforcing request size limits at the web server or proxy layer, and using container or cgroup limits as availability boundaries. None of these are complete solutions.
CVE-2026-109619: RCE via Stale Global State
PHP processes requests using worker processes. Each worker handles one request at a time, and PHP is expected to fully reset its internal state between requests. The vulnerability arises when request-owned internal state survives after the memory backing it has been freed. If a later request is handled by the same worker before normal initialization resets that state, the worker may use the stale data — data that belongs to a previous, already-completed request.The confirmed attack paths involve session upload progress handling and, on PHP 8.5, fatal error backtraces. The incomplete mitigations are to set session.upload_progress.enabled=0 and restart every worker process, and on PHP 8.5, to additionally set fatal_error_backtraces=0. These block the confirmed paths. Other variants may exist.
Both mitigations must be applied in php.ini, an FPM pool configuration, or Apache server configuration — not via ini_set() or .user.ini, which apply after the vulnerable initialization window has already passed.
Who Is at Risk
All PHP installations serving web requests are affected. This includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP security team has explicitly stated that risk is highest for mod_php, where a demonstrated exploit exists showing that an unauthenticated request can trigger the attack before any application code runs. The application itself does not matter. A fully hardened, well-audited PHP application running on a vulnerable PHP version is still exposed.PHP 8.1 and older are end of life and will not receive official security updates from the PHP project. Some Linux distributions and long-term support vendors provide backported fixes — check your vendor. For installations building from source without an LTS vendor, the PHP security team has published minimal source backports for PHP 7.4, 8.0, and 8.1 as a temporary measure. The correct long-term action for any installation on 8.1 or older is to upgrade to a supported version.
Update Paths
Fixed versions are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Linux distributions received the patches in advance of the public release, so package manager updates should be available immediately on Debian, Ubuntu, RHEL, and derivatives. After updating, restart the web server or PHP-FPM service to load the new module.For Debian-based systems running mod_php with Apache, the update and restart sequence is:
sudo apt update
sudo apt install libapache2-mod-php8.X php8.X
sudo systemctl restart apache2
php8.X -v # verify the patched versionVerify both the CLI version and the version reported by your web server or phpMyAdmin — on systems with multiple PHP installations, these can differ, and the Apache module is the one that matters for this vulnerability.
What This Means for Healthcare
PHP powers a substantial portion of healthcare web infrastructure. Patient portal front-ends, EHR web interfaces, health system public websites, telemedicine scheduling applications, and a large number of healthcare vendor products are PHP applications. Many of them run on Apache with mod_php — the highest-risk configuration per this advisory.The "no complete mitigation" framing is particularly significant for healthcare environments. Healthcare security teams are accustomed to a patch management process that includes a testing window, change advisory board review, and scheduled maintenance windows. That process exists for good reasons. But CVE-2026-109618 and CVE-2026-109619 are not vulnerabilities where a temporary mitigation buys meaningful time. The incomplete mitigations reduce specific attack paths while leaving others open, and they require configuration changes that themselves need to be applied carefully and verified. The risk calculus here favors treating this as an emergency patch rather than a scheduled update.
The PHP 8.1 end-of-life situation is a secondary concern that healthcare organizations should assess alongside the immediate patch. PHP 8.1 reached end of life on December 31, 2024. Any healthcare system still running PHP 8.1 has been without official PHP security support for nearly two years. This vulnerability makes the upgrade timeline a more urgent conversation.
For healthcare security teams conducting vendor risk assessments: any PHP-based vendor application that has not been updated to a patched version as of today is running software with a publicly disclosed, unauthenticated RCE vulnerability. That is a relevant factor in third-party risk conversations.
A Note on This Site
bregg.com runs a custom PHP CMS on Apache with mod_php — the exact configuration the advisory identifies as highest risk. The server was running an affected version of PHP this morning. It was updated to PHP 8.4.27 within hours of the patch release, and a post-patch check of the access logs and web root confirmed no signs of compromise during the exposure window. The patches for these CVEs were released publicly today; the window between public disclosure and remediation was measured in hours, not days.The reason for mentioning this is not self-congratulation — it is to illustrate the practical workflow for any organization running PHP in this configuration: identify your version, check that the patched version is available in your package repository, run the update, restart the web server, verify the version, and check your logs. On a standard Debian/Ubuntu stack, that sequence takes under ten minutes.