PHP2Shell Explained: The Full Story Behind PHP's Emergency October 2026 Security Patch

On Wednesday, October 21, 2026, the PHP project shipped one of the most urgent security releases in its history. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, which the security community quickly nicknamed PHP2Shell. Both are rated 9.2 on the CVSS v4.0 scale, and under the right conditions they let an attacker run code on a server without logging in. This article explains what the bugs are, how they were found, why the disclosure turned chaotic, and what it means for anyone running a PHP website.

The Two Vulnerabilities in Plain English

CVE-2026-109618: Remote Code Execution via Out-of-Memory Corruption

Every PHP request runs under a memory_limit. When a request hits that ceiling, PHP aborts the current work instantly. The problem is timing: if the abort lands while PHP is halfway through setting up internal request data, that data is left half-built. Later, when PHP cleans up the request, it treats those half-built structures as valid. That is memory corruption, and in skilled hands memory corruption becomes code execution.

Picture a waiter who gets pulled away halfway through writing an order. The incomplete ticket still goes to the kitchen, and the kitchen trusts it. An attacker who can control exactly when the waiter is interrupted can make the kitchen cook almost anything.

On Apache with mod_php, researchers demonstrated full remote code execution with default settings, triggered by an unauthenticated request before any application code started. Code execution was also confirmed on PHP-FPM through code paths inside applications.

CVE-2026-109619: Remote Code Execution via Stale Global State

The second flaw lives in error handling. If a fatal error happens at an unlucky moment, some internal state keeps pointing at memory that belonged to a request that has already ended. When the same worker process handles the next request, it can use that freed memory before the normal reset happens. This is a classic use-after-free. A worker crash was confirmed, and the reporter demonstrated code execution against a real-world application on Apache with mod_php.

Why These Bugs Are So Serious

• They are in PHP itself, not in WordPress, Laravel, a plugin or your own code. Updating your CMS does nothing here.
• They sit in memory management and error handling, parts of the engine that nearly every request touches.
• Every PHP setup that serves web traffic is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
• No login or user account is needed.
• mod_php is the highest-risk setup, because the attack can fire before your application even loads.

The Back Story: A Warning Sign Back in 2024

The out-of-memory problem was not brand new. In 2024 PHP went through its first external security audit in years, performed by Quarkslab, organised through OSTIF and funded by Germany's Sovereign Tech Agency. While fixing one of the audit findings, a developer contracted by the PHP Foundation noticed the first signs of the OOM issue. Nobody had a concrete way to exploit it yet, and other findings looked more urgent.

Fixing it was genuinely hard. Every candidate patch had a price: breaking backward compatibility, creating new denial-of-service risks, or forcing changes in many third-party extensions. The security team worked by consensus, could not settle on an option, and the work stalled and restarted for months. The PHP Foundation has openly described this delay as a structural failure and says the team now decides by majority and actively encourages compromise.

2026: Auditors Turn a Theory Into a Working Exploit

• July 30, 2026: security firm Calif starts auditing PHP as part of OpenAI's Patch the Planet program.
• August 11: Ryan A at Calif reports an unconditional remote code execution with the same root cause as the 2024 OOM issue. OpenAI independently reports the same root cause on the same day.
• August 24: Wiz reports additional attack vectors, and OpenAI follows with more on September 18.
• From August 11 onward: the fix becomes the top priority for the Foundation's security staff, with engineers working through weekends.

The Foundation also points out that AI-assisted research has sharply raised the number of incoming reports. The team has published 15 CVEs since July 1 and processed more than 100 reports that turned out to be invalid, duplicates or impossible to reproduce.

The Leak That Rushed the Release

The coordinated plan was to release on October 22 at 14:00 UTC. That plan did not survive.

• October 20, about 15:00 UTC: the two CVE IDs began circulating on forums and social media, with an incorrect CVSS score of 10.0 and an incorrect release time. No technical details leaked at this stage.
• October 20, 19:30 UTC: PHP published an early pre-announcement and pulled the release forward by one day.
• Around 20:00 UTC: Calif mistakenly posted a video of its proof of concept working against several targets. It was deleted, but copies spread and accelerated public exploit development.
• October 21, 07:41 UTC: Chainguard published built images containing the fix more than six hours before the coordinated release, letting anyone study the patch early.
• October 21, morning: Cloudflare reported attack attempts before the official fix was out.
• October 21, 14:00 UTC: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 went live.

Who Is Affected?

Every PHP release before 8.5.12, 8.4.27, 8.3.36 and 8.2.35 is affected, and so are PHP 8.1, 8.0, 7.x and older. The PHP project only ships official releases for 8.2 and newer. For older branches, the security team published minimal source-level backports for 7.4, 8.0 and 8.1 to help people who compile PHP themselves, and several Linux distributions and long-term support vendors are shipping their own patched packages.

One detail catches many people out: Linux distributions often patch PHP without changing the visible version number. An older-looking version string is not automatically vulnerable, so you need to check the package changelog to be certain.

What You Should Do Right Now

• Find out exactly which PHP version and server API your site runs. Our step-by-step vulnerability check guide includes a ready-made script.
• Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or confirm that your host or distribution has applied the fix.
• Restart every PHP worker after updating. Old processes keep running old code until they are restarted.
• If you cannot update today, apply the temporary mitigations recommended by PHP, keeping in mind they reduce risk but do not remove it.
• If you are on PHP 8.1 or older, plan your upgrade now. PHP 8.2 itself reaches end of life on December 31, 2026.

Official Sources

• PHP.net security advisory, October 21, 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation: how these vulnerabilities were found and fixed