The PHP development team has released emergency security updates addressing two critical vulnerabilities that could allow unauthenticated attackers to execute arbitrary code on affected servers. The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, both carry a CVSS v4.0 severity score of 9.2.
Released on October 21, 2026, PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 include fixes for both vulnerabilities. A follow-up advisory published on October 23 also highlights a separate issue involving PHP session upload progress.
For PHP developers and system administrators, these updates deserve immediate attention, particularly because some attack scenarios can occur before application code is executed.
Understanding the Two Critical Vulnerabilities
Unlike typical PHP application vulnerabilities involving SQL injection, cross-site scripting, or insecure file uploads, these issues affect PHP’s internal runtime.
This distinction is important. Even applications following established security practices may remain exposed if their underlying PHP installation is vulnerable.
1. CVE-2026-109618: Remote Code Execution Through Memory Corruption
The first vulnerability involves PHP’s handling of out-of-memory (OOM) conditions.
PHP uses internal mechanisms to manage memory allocation and terminate operations when memory limits are exceeded. Under certain circumstances, an allocation failure can interrupt initialization while internal request data is still in an incomplete state.
During request cleanup, PHP may subsequently process that invalid data, creating conditions for memory corruption and potentially remote code execution.
One particularly concerning scenario involves specially crafted HTTP multipart requests that cause unexpected memory exhaustion during request parsing.
According to the PHP security advisory, Apache installations using mod_php face particularly significant exposure because the vulnerable behavior can occur before the application itself begins execution.
This means that input validation implemented inside a PHP application may never have an opportunity to inspect the malicious request.
2. CVE-2026-109619: Remote Code Execution Through Stale Global State
The second vulnerability concerns the management of internal state between HTTP requests.
PHP workers maintain certain global structures while handling multiple requests. Some of these structures temporarily reference memory belonging to individual requests.
Normally, this state must be reset before its associated memory is released.
However, particular combinations of errors, initialization operations, and request cleanup can leave references to memory that is no longer valid.
When another request is processed by the same worker, PHP may access this stale state, resulting in a use-after-free condition.
The vulnerability can potentially be exploited to achieve remote code execution.
What makes this issue interesting from a technical perspective is that the problematic operations may occur across different HTTP requests rather than within a single application execution.
The PHP security team has documented several affected internal mechanisms involving error handling, configuration initialization, and session-related operations.
Which PHP Versions Are Affected?
The PHP development team has released the following patched versions:
| PHP Branch | Minimum 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 |
PHP 8.1 and earlier branches are no longer maintained by the PHP project. Organizations running these versions should migrate to a supported release or consult their operating system vendor regarding security backports.
PHP 8.6.0 RC4 also includes the fixes, although this development release is not intended for production environments.
It is worth noting that PHP 8.2 will reach its official end of life on December 31, 2026, making this an appropriate time to review longer-term upgrade plans.
How to Check Your PHP Installation
The first step is to identify which PHP version is actually running on your servers.
From the command line, execute:
php -vHowever, developers should remember that the command-line PHP version may differ from the version used by Apache, PHP-FPM, or another application server.
For environments running multiple PHP installations, all active runtimes should be checked individually.
We can also create a simple PHP script that verifies whether the installed upstream version contains the relevant security fixes.
<?php
declare(strict_types=1);
$patchedVersions = [
'8.2' => '8.2.35',
'8.3' => '8.3.36',
'8.4' => '8.4.27',
'8.5' => '8.5.12',
];
$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
if (!isset($patchedVersions[$branch])) {
echo "PHP " . PHP_VERSION;
echo " - Check branch support and vendor patches.\n";
exit(2);
}
$minimum = $patchedVersions[$branch];
if (version_compare(PHP_VERSION, $minimum, '>=')) {
echo "PHP " . PHP_VERSION;
echo " - Upstream security version requirement met.\n";
exit(0);
}
echo "PHP " . PHP_VERSION;
echo " - Update to PHP $minimum or later.\n";
exit(1);This example uses PHP’s built-in version constants and version_compare() function. It can be incorporated into a deployment verification process or an internal server auditing tool.
The script checks upstream version numbers only. It cannot establish whether a distribution has backported the fixes into a package retaining an older version number, and it does not inspect every PHP runtime on a server.
What About PHP-FPM, FrankenPHP, and Other Servers?
The vulnerabilities are not limited to traditional Apache installations.
The official security announcement identifies PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed among the environments requiring attention.
However, the exact attack conditions differ between server implementations.
For example, PHP-FPM terminates a worker when certain initialization failures occur, which changes the exposure compared with mod_php. Nevertheless, this does not eliminate all vulnerable scenarios.
For developers using Docker, updating PHP packages inside an existing container is not always sufficient as a deployment strategy. Base images should be refreshed, application images rebuilt, and running containers replaced.
The objective is to confirm that the patched runtime is being used by the actual production application, not merely installed somewhere on the server.
An Additional Session Security Advisory
On October 23, the PHP development team published a separate informational advisory concerning CVE-2026-115560.
This issue involves an unusual combination of PHP session configuration and application behavior.
Specifically, the affected scenario requires an application to configure session.serialize_handler as php_binary or php_serialize, change it to php at runtime, and then initialize the session while session upload progress remains enabled.
The PHP team recommends temporarily disabling session upload progress until the next regular bugfix release:
session.upload_progress.enabled=0The setting should be applied through the relevant PHP configuration and followed by a worker restart.
This additional advisory should not be confused with the two critical vulnerabilities fixed on October 21. It concerns a more specific configuration scenario, and the PHP team plans to publish its full advisory with a subsequent release.
Recommended Actions for PHP Developers
The immediate priority is to upgrade affected installations to the patched versions.
Where an upgrade cannot be completed immediately, the PHP security team has documented temporary measures involving memory limits, HTTP request size restrictions, session upload progress, and server configuration.
These measures may reduce exposure to particular attack paths, but they are not complete replacements for applying the patches.
Developers should also review their deployment procedures. Knowing which PHP version runs in development is useful, but maintaining an inventory of production runtimes, containers, and server packages is considerably more important during a critical security incident.
After updating, restart affected PHP workers, verify the effective runtime versions, review application logs, and confirm that security fixes have reached every relevant environment.
Conclusion
These vulnerabilities are a reminder that PHP application security extends beyond the code we write.
Input validation, secure database access, dependency management, and application-level protections remain essential. However, none of these practices can fully compensate for a critical vulnerability in the underlying language runtime.
The October 2026 emergency releases demonstrate why maintaining supported PHP versions and applying security updates promptly should be considered part of the development lifecycle rather than an occasional maintenance activity.
For organizations still running older PHP versions, this incident also provides a practical reason to reconsider long-delayed migration plans.
Official References
- PHP Development Team — Critical Security Announcement
- CVE-2026-109618 — RCE via OOM Corruption
- CVE-2026-109619 — RCE via Stale Global State
- PHP Release Archive — 2026
