PHP Releases Four Updates to Fix Two Critical Vulnerabilities
PHP has released four updates to fix two critical vulnerabilities. Under certain conditions, an attacker could execute code on a server. Site owners and developers are advised to update PHP.
On October 21, the PHP project released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical vulnerabilities. Under certain conditions, an unauthenticated attacker could execute code on a server. As the PHP Foundation explains, PHP users need to update; technical details and instructions for different systems are available in the project’s announcement on php.net.
How the Two Vulnerabilities Work
CVE-2026-109618 is related to running out of memory. If a request hits the memory_limit at a particular point, PHP may leave internal data partially initialized and later treat it as valid. This corrupts memory. On Apache with mod_php, researchers demonstrated remote code execution through an unauthenticated request with default settings—before application code even runs. For PHP-FPM, they confirmed code execution through application-dependent paths.
With CVE-2026-109619, a fatal error can leave a pointer to memory from a previous request in PHP’s internal state. The next request handled by the same worker process may then access memory that has already been freed. Researchers confirmed this error and a process crash; one researcher also demonstrated code execution against a real application running under Apache with mod_php.
Both issues lie in mechanisms used by almost every request: memory management and error handling. In preparing the fixes, the team had to account for compatibility, performance, and third-party extensions. The confirmed attack scenarios differ between mod_php and PHP-FPM.
Why the Fix Took Time
A core developer spotted the first signs of the out-of-memory issue while addressing a finding from an external audit in 2024. Exploitation was considered possible at the time, but no concrete path to code execution had been found. Proposed fixes risked breaking compatibility, creating a denial-of-service risk, or requiring changes across many extensions. Work stopped and restarted over several months. The Foundation attributes the delay both to how decisions were made within the security team and to a shortage of specialists familiar with the PHP engine.
On August 11, 2026, Calif reported remote code execution stemming from the same root cause. OpenAI reported it independently on the same day. Wiz and OpenAI later submitted additional attack methods. Following those reports, the fix became the top priority for the Foundation’s security specialists. A patch was prepared for all supported branches.
The organization is also changing its process. In May 2026, it created the Ecosystem Security Team to review reports, coordinate responses, and work on PHP security. Tools help the team verify findings and identify reports with a common root cause, but people remain responsible for decisions and fixes. Since July 1, the team has published 15 CVEs and handled more than 100 reports that turned out to be incorrect, duplicates, or not reproducible.
The release date had to be moved up: on October 20, the CVE numbers appeared online without technical details but with an incorrect severity score of 10.0 instead of the actual 9.2. The updates were moved from October 22 to October 21. They could not be released immediately because distributors were still preparing packages. Before the agreed release time, videos demonstrating the attack and patched images from Chainguard also appeared. At the time of the public release, the PHP security team had found no working exploits among the samples it had examined.
What PHP Users Should Check
Site owners and developers should first find out which PHP version they are running and check whether the update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 is available for their branch. The Foundation urges users to update and points them to the PHP announcement for system-specific instructions. Its own overview covers the reasons behind the fix and how it came about, not the installation steps.
The assessment should not focus on just one exploitation path. A scenario that works before application code runs has been demonstrated for mod_php, while code execution through paths in an application has been confirmed for PHP-FPM. If a contractor or hosting provider manages the environment, I would ask them which PHP version is running and whether it has been updated. The fixes in PHP’s core are also covered in a separate blog post.
My Take
For me, the main takeaway is that you cannot assess the risk by looking only at a site’s code. In one confirmed scenario, the request triggers the issue before that code starts running. So I would check the PHP environment’s version first, then determine which attack conditions apply to the specific configuration.
The Foundation is clear about why the fix was delayed: every option had consequences, and there were not enough specialists to choose and verify a solution. In my view, this part of the story is just as useful as the news of the patch. Finding a bug and releasing a reliable fix are different tasks. The latter requires people who understand how PHP works and can assess the consequences of changes.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
- PHP Foundation's Overview of CVE-2026-109618 and CVE-2026-109619 thephp.foundation
junior full-stack developer
I'm building a practice booking service and figuring out how to connect the client side to an API. In my answers, I try to explain not only what I chose, but why.
All posts by the authorRelated articles
PHP Core Vulnerabilities Patched That Could Allow Remote Code Execution
PHP has patched core vulnerabilities that could lead to remote code execution and process memory disclosure. Website owners should check their PHP version and install the security update.
Details Published of an Alleged Vulnerability in PHP Upload Handling
The author describes an alleged PHP vulnerability involving file upload handling. The issue has not yet been officially confirmed, and no fix has been announced.
The PHP Vulnerability Is Real, but Published Exploits Raise Questions
The author argues that widely shared PoCs do not demonstrate an attack against a standard PHP server. The vulnerability is real, however, and affected servers should be patched.
Discussion 5
Tobias Arndt
one deployment detail worth checking: patch the php-fpm and cli packages separately where your distro splits them, then restart the relevant workers. Updating the CLI binary alone won’t replace the code already loaded by long-running fpm processes.
Ramin Aliyev
I’d be careful treating separate package updates as a universal requirement: some distros bundle CLI and FPM, and a package upgrade may restart workers for you. The important bit is verifying the running FPM processes actually picked up the patched binary, not restarting things by ritual.
Inês from Porto
That distinction is useful — I’ve been learning that “package updated” and “service is running the patched code” aren’t always the same thing. For PHP-FPM, checking the process start time or restarting the pool after an upgrade seems like a practical way to confirm it actually reloaded, especially when CLI and FPM come from one bundled package 🙂
Emil Ursu
Calling these simply “critical” risks blurring the important distinction in the write-up: the demonstrated unauthenticated RCE is specifically on Apache with mod_php, while the PHP-FPM path depends on the application. That doesn’t make the fixes optional, but it does mean risk assessments should account for the actual SAPI and request path rather than imply every PHP deployment has the same exposure.
Oliver Lopes
@emil_ursu, the SAPI distinction matters for exposure, but it doesn’t really argue against calling the bugs critical: mod_php has a demonstrated unauthenticated RCE, and PHP-FPM still has code-execution paths depending on the application. I’d separate severity from how widely a particular deployment is exposed—otherwise every risk label needs a footnote about the stack.