Two critical PHP vulnerabilities have triggered an urgent security response after Cloudflare reported early attempts to exploit the flaws ahead of a planned security release. Tracked as CVE-2026-109618 and CVE-2026-109619, the vulnerabilities have each received a CVSS v4.0 score of 9.2. Researchers have collectively referred to the issues as PHP2Shell because of their reported potential to enable remote code execution (RCE).
Cloudflare says it has deployed an initial set of Web Application Firewall (WAF) rules to block known exploit patterns. The rules are available to all customers, including those on free plans, and the company is updating them as new attack patterns emerge. However, the reported activity does not establish how many systems have been targeted or whether the attempts have resulted in successful compromises.
PHP’s security team scheduled an emergency release for October 21 at 14:00 UTC, or 7:30 PM IST. At the time of writing, that deadline is still ahead. The team had also indicated that it could accelerate the release if technical details became public or it found evidence of active exploitation.
An independent proof-of-concept repository has already published verification tools and a lab environment for investigating the reported vulnerabilities. It describes several potential exploitation paths involving PHP’s session handling, memory management and PHP-FPM. However, the repository’s claims about affected versions and exploit conditions still need to be checked against PHP’s official advisory and patches.
The timing is significant. Public exploit research can help defenders understand a vulnerability, but it can also give attackers a starting point for developing working exploits before administrators have patched their systems.
According to the repository, the vulnerabilities affect PHP’s session.upload_progress feature, which tracks file upload progress. One reported attack chain involves injecting data into PHP session files and combining that behaviour with a local file inclusion (LFI) vulnerability in an application.
The research claims that PHP’s upload-progress handler stores a supplied filename in session data without adequate validation. It also describes how a session identifier supplied in a POST request body could be accepted despite the session.use_only_cookies setting, which is intended to restrict how PHP accepts session IDs.
An attacker could potentially use these behaviours to influence session data and then exploit an LFI flaw to make the application load a file from an unintended location. If the necessary conditions are met, the chain could lead to code execution on the server.
This is not a universal attack against every PHP website. The reported chain depends on configuration and application-level weaknesses, including a suitable file inclusion flaw. The distinction matters because a critical CVSS score indicates severity, not whether every installation is exploitable.
The repository describes another issue involving a use-after-free memory error. This occurs when software attempts to access memory after it has been released, potentially creating conditions for memory corruption or other unintended behaviour. The researcher says the condition can arise through re-entry into a var_destroy destructor and reports reproducing it with AddressSanitizer, a tool used to detect memory errors.
Additional research details describe PHP-FPM serializer state that may persist across requests and a handler mismatch that could cause a destructor to execute after deserialization fails. Some of these paths reportedly require additional conditions, such as an application gadget or access to a local file.
These details point to several possible exploitation mechanisms rather than one simple payload. The full relationship between the reported issues, their affected versions, and their practical exploitability should become clearer when PHP publishes its official technical advisory.
The number of outdated deployments adds another concern. Security company Mallory reported finding 883,717 internet-facing hosts running PHP 8.1 or older in Shodan data collected on October 20. That represents approximately 59% of the roughly 1.5 million hosts in its dataset that disclosed a PHP version.
The figures do not represent 883,717 confirmed vulnerable servers. Internet-facing hosts are not the same as individual websites, and some operating system vendors backport security fixes without changing the upstream PHP version number. Still, the data highlights how widely unsupported PHP installations remain exposed to the internet.
PHP 8.1 and older branches, including PHP 8.0, PHP 7.x, and PHP 5.x, are end-of-life and no longer receive regular upstream security fixes. PHP 8.2 and 8.3 receive security fixes only, while PHP 8.4 and 8.5 remain under active support.
The research repository lists PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 as planned fixed releases. Administrators should verify these version numbers against PHP’s official announcement before deciding which builds to install, as the advance notice has not yet confirmed the complete list of affected and fixed versions.
Cloudflare’s WAF rules offer a useful temporary defence, but they cannot eliminate the underlying vulnerabilities. WAFs inspect incoming requests and block traffic matching known malicious patterns. New exploit variants may evade rules designed around previously observed requests, particularly as more technical details become available.
Cloudflare CTO Dane Knecht has urged customers to apply the PHP security update as soon as it becomes available. That is the right approach: use network-level protection to reduce exposure, but do not treat it as a substitute for patching.
Administrators should inventory PHP installations across web servers, containers, staging environments and managed hosting platforms. They should then compare installed versions with the official PHP advisory and apply the appropriate update as soon as possible. After patching, they should restart PHP-FPM or the relevant service where required and verify that the updated runtime is running.
For systems that cannot be patched immediately, the research repository suggests disabling session.upload_progress and setting session.use_only_cookies to On. These changes may reduce exposure to some reported attack paths, but they do not address every mechanism described in the research. Administrators should also review applications for local file inclusion and unsafe deserialization flaws.
Security teams should inspect web server and PHP logs for unusual session-handling requests, unexpected file changes and PHP worker processes launching unfamiliar programs. If there are signs of compromise, they should preserve logs and follow their incident-response procedures. Blocking a request at the WAF does not prove that an attacker never reached the application.
The PHP2Shell incident illustrates the difficulty of defending widely deployed software when exploit details emerge before fixes are available. The combination of reported exploitation attempts, multiple potential attack paths and a large population of outdated installations gives administrators little reason to delay preparation.
The immediate priority is to verify the official PHP advisory and patch affected systems as soon as confirmed fixes become available. For organisations still running unsupported PHP branches, the incident is also a reminder that temporary security rules cannot compensate indefinitely for software that no longer receives upstream security updates.
