PHP releases emergency patches for critical PHP2Shell remote code execution flaws

The PHP project released emergency security updates on October 21, 2026, to address two critical vulnerabilities collectively known as PHP2Shell. These flaws reside in the core PHP runtime rather than individual applications, allowing attackers to execute arbitrary code on web servers without authentication. The release came a day earlier than planned after details of the vulnerabilities leaked online, prompting immediate action from the PHP security team.

What happened

The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, carry a CVSS v4.0 severity rating of 9.2. They affect nearly every PHP version dating back to PHP 5.4. The fixes are available in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Because these bugs exist in the language engine itself, even a static "Hello World" page served by a vulnerable PHP installation is at risk. The highest danger lies with servers using Apache's mod_php, where a single unauthenticated request can trigger the exploit before any application code executes.

Researchers from Wiz, Calif, and OpenAI discovered and reported the flaws. Their work, assisted by AI tools, accelerated the identification of working exploits for code that had remained in PHP for over a decade. Before the official patch shipped, Cloudflare observed early exploitation attempts against its customers. By the time the patches were released, security firm watchTowr confirmed active exploitation attempts for both CVEs, although no specific successful break-ins had been publicly confirmed at that time. Major services, including BambooHR and several Dutch government platforms, took systems offline as a precautionary measure.

How it works

These vulnerabilities allow attackers to read memory from the PHP worker process and potentially achieve remote code execution. This memory access can expose sensitive data such as passwords, API keys, and authentication tokens from other requests without the attacker first gaining code execution privileges. The risk profile varies by server configuration. While mod_php is highly susceptible to immediate exploitation, PHP-FPM offers some natural resistance because it terminates workers when requests fail during setup. However, researchers demonstrated that one of the flaws could still reach code execution on PHP-FPM under specific conditions involving operations within the running application.

The disclosure process was disrupted when a research firm accidentally posted a proof-of-concept video and a vendor published patched container images hours before the official release. This premature exposure forced the PHP team to accelerate their timeline. The underlying issues stemmed from complex memory management and session handling mechanisms that had been part of PHP for years. A 2024 external audit had initially flagged signs of the out-of-memory flaw behind CVE-2026-109618, but a concrete attack vector was not established until recent AI-assisted research clarified the exploitation path.

Key details

• Affected versions: All PHP versions from 5.4 up to 8.5.11, 8.4.26, 8.3.35, and 8.2.34 are vulnerable.
• Fixed versions: Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 immediately.
• Highest risk: Servers using Apache mod_php are most vulnerable to unauthenticated remote code execution.
• Partial mitigations: For CVE-2026-109619, setting session.upload_progress.enabled=0 reduces risk but does not fully fix the issue.
• Legacy support: PHP 8.1 and older are end-of-life; source backports are available for PHP 7.4, 8.0, and 8.1 for those building from source.
• Detection signs: Look for unusual multipart requests, memory-limit errors, repeated HTTP 500 responses, and unexpected PHP worker restarts.

Why it matters

For software engineers and IT leads, this incident highlights the critical difference between application-level security and runtime-level vulnerabilities. Updating frameworks like Laravel or WordPress does not protect against PHP2Shell because the flaw exists in the underlying interpreter. This means that even well-audited applications are exposed if the server environment is not patched. The speed at which AI-assisted research turned long-standing theoretical bugs into working exploits also underscores the need for rapid patching cycles. Waiting for a scheduled maintenance window is no longer a viable strategy for critical runtime flaws.

The disruption caused by premature leaks and active exploitation attempts demonstrates the fragility of coordinated disclosure in the modern threat landscape. Organizations must have robust incident response plans that include the ability to rapidly update infrastructure components. Relying solely on configuration tweaks as a mitigation strategy is dangerous, as the PHP core developers explicitly stated that only updating provides complete protection. This event serves as a reminder that infrastructure dependencies require the same level of vigilance as application code.

What you can do

• Identify all servers running PHP and check their current version numbers against the fixed releases listed above.
• Update the PHP runtime package via your system package manager or rebuild container images with the patched versions.
• Restart all web servers, PHP-FPM pools, and long-running PHP workers to ensure the new binary is loaded.
• If immediate updating is impossible, apply partial mitigations such as disabling session upload progress and enforcing strict memory limits, but plan to patch ASAP.
• Monitor logs for indicators of compromise, including strange multipart form submissions and sudden spikes in 500 errors.
• Verify that your Linux distribution’s package changelog includes the relevant CVE fixes, as version strings may not always reflect the patch status in LTS distributions.