Introduction
PHP has been powering web applications for decades. PHP powers popular platforms such as WordPress, Joomla, Drupal, and Wikipedia's MediaWiki 1. From content management systems to enterprise applications, it remains an important part of the backend ecosystem.
In October 2026, two critical vulnerabilities were disclosed in PHP, raising serious concerns about the security of web servers running vulnerable PHP versions. Both vulnerabilities could allow unauthenticated attackers to achieve Remote Code Execution (RCE).
Let's take a closer look at what happened, how these vulnerabilities work, and what developers should do to protect their applications.
1. What Happened?
On October 21, 2026, the PHP development team released security updates addressing two critical vulnerabilities:
- CVE-2026-109618: Remote Code Execution via Out-of-Memory (OOM) corruption.
- CVE-2026-109619: Remote Code Execution via stale global state.
Both vulnerabilities received a CVSS score of 9.2, and the PHP development team released patches addressing both issues in the core engine.
What makes these issues particularly concerning is that an attacker may exploit them without authentication by sending specially crafted HTTP requests to vulnerable PHP installations. This means the security risk is not necessarily limited to applications with weak authentication or poorly written business logic.
These vulnerabilities became widely known as PHP2Shell. Security researchers demonstrated successful exploitation against popular platforms such as WordPress, Drupal, and Joomla. Importantly, the vulnerabilities exist in PHP's core runtime rather than in the application code itself.
2. Understanding CVE-2026-109618: Out-of-Memory Corruption
Out-of-memory errors occur when a program cannot allocate the memory it needs to continue execution. In PHP, memory allocation failures can interrupt request processing. The vulnerability occurs when this interruption happens while internal request data is only partially initialized.
During request cleanup, PHP may incorrectly treat this incomplete data as valid 2.
This can lead to memory corruption and, under certain conditions, Remote Code Execution.
Why does this matter?
Developers often think of memory exhaustion as an availability problem that causes an application to crash. However, this vulnerability demonstrates that improper memory handling can become a much more serious security issue.
3. Understanding CVE-2026-109619: Stale Global State
The second vulnerability involves stale global state.
PHP uses internal global state to manage information during request processing. Some of this state may point to memory owned by an individual request.
The problem occurs when that request memory is freed but the global state still contains a reference to it.
A subsequent request handled by the same worker may access this outdated reference before the state is properly initialized.
This creates a use-after-free-like condition that can potentially be exploited to execute arbitrary code.
The important lesson: Memory lifecycle management is not just a low-level programming concern. Errors in this area can have direct security consequences.
4. Who Is Affected?
According to the PHP security advisory, vulnerable installations include PHP environments serving web requests, such as:
- PHP-FPM
- Apache with mod_php
- php-cgi
- FrankenPHP
- LiteSpeed
The PHP team identified mod_php as the highest-risk configuration.
The affected version ranges include PHP 8.5.0–8.5.11, 8.4.0–8.4.26, 8.3.0–8.3.35 and 8.2.0–8.2.34.
Older branches, including PHP 8.1 and earlier, are also affected and have reached end of life.
A Note on Another PHP Vulnerability
On October 23, 2026, another RCE vulnerability, CVE-2026-115560, was disclosed. Unlike the previous two vulnerabilities, this issue affects applications using a specific and unusual session configuration.
The PHP team recommended disabling session upload progress as a mitigation until the next regular bugfix release.
This is another reminder that security updates should be followed continuously, even after a major vulnerability has been patched.
5. How Can Developers Protect Their Applications?
The most important step is upgrading to a patched PHP release.
The security fixes were included in:
| 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 |
Beyond upgrading, developers and system administrators should:
- Identify all PHP installations across their infrastructure.
- Prioritize internet-facing applications.
- Review PHP versions used in Docker images and deployment pipelines.
- Check third-party products and dependencies that bundle PHP.
- Monitor security advisories and apply updates regularly.
- Review server logs and investigate suspicious activity.
Updating the runtime is essential, but organizations should also assess whether vulnerable systems were previously exposed or compromised. Some of the organizations took actions already.
Not a One-time task
These vulnerabilities are a reminder that application security goes beyond writing secure code.
Even when developers follow best practices, vulnerabilities in the underlying runtime, frameworks, libraries, or infrastructure can expose an entire application.
I've encountered similar situations before with npm package vulnerabilities and React security issues. Fortunately, the projects I worked on were not using the affected versions. Those experiences made me more aware of how important it is to regularly check security advisories and understand not only which versions are affected, but also how vulnerabilities can be exploited.
I believe security should be part of the entire software development lifecycle, from development and dependency management to deployment and monitoring.
Because keeping an application secure is not a one-time task. It's an ongoing responsibility
References & Resources
Image Credit: My Design - Canva