PHP2Shell: Two Unauthenticated RCE Flaws in the PHP Runtime and Why Patching Your Application Is Not Enough

Roughly 70 percent of the web runs on PHP, and on October 21, 2026, the PHP security team shipped an out-of-cycle emergency release for two critical vulnerabilities, tracked together as PHP2Shell, that let an unauthenticated attacker run code on the server. The flaws live in the PHP runtime itself, not in WordPress, Drupal, Magento, or any application sitting on top of it, meaning an organization can run clean, well-audited application code and still be fully exploitable. This post breaks down what PHP2Shell actually is, how the two underlying bugs (CVE-2026-109618 and CVE-2026-109619) work, why the runtime detail changes your exposure, and the specific steps to take today, including the interim mitigations the PHP team itself warns are incomplete. Exploitation attempts were observed before the patch shipped.

What happened

PHP2Shell is the collective name for two critical remote code execution vulnerabilities in the PHP interpreter, both rated 9.2 out of 10 on the CVSS v4.0 scale. Security researchers at Calif, Wiz, and OpenAI reported the flaws to the PHP security team starting in August, with Calif finding the first bug using OpenAI’s GPT-5.6 Sol, and coordinated disclosure, patch verification, and an assessment of the ecosystem-wide blast radius before any details went public.

The PHP team warned administrators on October 20 to prepare for an emergency update, but technical details leaked online that same day, before the patch was ready, and watchTowr confirmed it could reproduce one of the bugs. PHP published the advisories and fixed builds on October 21, a few minutes ahead of the scheduled 14:00 UTC release. Both vulnerabilities are unauthenticated, meaning an attacker needs no account, no credentials, and no prior foothold: a single crafted web request is enough to trigger them.

Critically, the flaws span every common PHP server configuration: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed are all affected, and Wiz reports that every PHP version released in the past decade is vulnerable to at least one of the two bugs, reaching back to PHP 5.4.

Related: Why AI in Pentesting Must Stand up to Independent Scrutiny

‍

How the flaws work

Both vulnerabilities share a single root cause: PHP can leave its memory in a corrupted state when a request terminates abnormally, and from that shared weakness the two CVEs take different paths to code execution.

• CVE-2026-109618 is an out-of-memory corruption flaw. When PHP exhausts its memory limit mid-request, the resulting corruption can be chained into code execution running as the web worker account.
• CVE-2026-109619 is a stale global state vulnerability. It enables an unauthenticated heap use-after-free that an attacker can turn into memory disclosure, leaking passwords, session tokens, API keys, and certificates directly from the worker’s memory, and ultimately code execution with the web worker’s privileges.

The PHP security team considers the risk highest for mod_php deployments, where an unauthenticated request can trigger the attack before any application code runs: there is no login page to reach, no input validation to clear, and no application logic standing between the attacker and the vulnerable interpreter. The team has confirmed a working exploit against this configuration. PHP-FPM is also exposed: PHP validated remote code execution against FPM for CVE-2026-109619, and considers FPM susceptible to CVE-2026-109618 even though no complete FPM exploit has been shown yet.

The underlying bugs have existed for years, but Wiz found that frontier AI models substantially lowered the cost of weaponizing them, turning a long-standing memory-corruption class into an active, same-day threat.

‍

Why "patch your application" doesn't apply

Most web vulnerabilities live in application code: a SQL injection, a broken access control, an outdated plugin. PHP2Shell is different because the flaw is in the runtime that executes your code, which means exposure has nothing to do with how carefully your application was written. Clean code, well-audited frameworks, up-to-date plugins: none of it matters if the interpreter underneath is vulnerable.

According to VirusTotal data, more than 5.1 million PHP hosts are exposed on the internet, roughly 3.8 million of them with at least one open port, and the content management systems that collectively run much of the web, WordPress, Drupal, Magento, and Joomla, all sit on PHP and all inherit the exposure regardless of their own patch state.

Government agencies in the US and Europe told operators to patch immediately or take systems offline until they could, and several did: Finland’s government, the Dutch House of Representatives, French local government sites, and Belgium’s foreign ministry all pulled sites offline as a precaution. Cloudflare deployed emergency web application firewall rules at 03:02 UTC on October 21 and noted that the bugs can also crash PHP workers, so even failed exploitation attempts can cause denial of service. OpenAI described PHP2Shell as “one of the most impactful security issues in recent memory,” and Wiz drew the comparison every defender dreads: Log4Shell.

‍

The exploitation window is already open

Attack attempts started before the patches shipped. Cloudflare’s CTO reported early attacks during the disclosure window and described the firewall rules the company deployed as a stopgap. PHP has not confirmed successful in-the-wild exploitation yet, and as of October 21 neither CVE is in CISA’s Known Exploited Vulnerabilities catalog, but that is unlikely to hold for long. Wiz named its exploit script php2shell because it turns a crafted web request into a shell on the server. As with every mass-exploited RCE, defenders should expect web shells and other persistent backdoors to follow.

Because working exploits are already circulating and the vulnerable surface is enormous, defenders should treat any unpatched, internet-facing PHP server as a live target now.

‍

What to do now

PHP core developer Gina Peter Banyard stated plainly that the only complete fix is to update and that patching is the sole permanent defense.

• Upgrade to a fixed PHP release immediately: PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Minimal source backports are available for PHP 7.4, 8.0, and 8.1 for teams that build from source. PHP 8.1 and earlier are end-of-life from the project, but Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages (Ubuntu, for example, already ships fixes from php5 through php8.5). Note that PHP 8.2 reaches end of life on December 31, 2026, so patching to 8.2.35 buys you two months, not a year. After updating, restart Apache or PHP-FPM, or redeploy your containers, so the new binary loads and any worker that already handled a malicious request is replaced.
• Prioritize mod_php hosts, which the PHP team rates as the highest-risk configuration.
• Patch the platforms on top of PHP as their maintainers release updates: WordPress, Drupal, Magento, and Joomla among them.

If you cannot patch instantly, the PHP team published interim mitigations while stressing that none fully block exploitation:

• For CVE-2026-109618: set memory_limit=-1 where applications cannot override it (php_admin_value in the FPM pool or Apache configuration), set a low post_max_size (8M, or 32M if file uploads are required) with upload_max_filesize below it, and apply a container or cgroup memory limit. Setting memory_limit=-1 looks backwards, but it removes the memory limit failure the attacker controls, and the cgroup limit takes over as the availability boundary. Do not use RLIMIT_AS or RLIMIT_DATA instead, since those cause the exact allocation failure the bug depends on.
• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool, or the server configuration and restart every worker. Setting it with ini_set() or in .user.ini does not work because those apply too late. On PHP 8.5, also set fatal_error_backtraces=0 and restart workers. Then remove invalid or deprecated per-request settings and fix any attacker-reachable fatal errors or timeouts. Hiding diagnostics with error_reporting, display_errors, or @ does not help. If the application does not use multipart form data, block those requests at the web server or proxy before they reach PHP.

Treat these as a bridge for the hours until you patch, not a substitute. CISA, the FBI, the NSA, and the UK’s National Cyber Security Centre all advised organizations to update immediately or take affected systems offline until they can. PHP also recommends leaving session.upload_progress.enabled=0 in place after patching if you do not need the feature.

From a compliance standpoint, an unpatched critical RCE with public exploits is difficult to defend in any audit. SOC 2’s CC7.1, ISO 27001’s A.8.8 (vulnerability management), and PCI DSS requirement 6.3.3 all impose patch-cadence obligations, and a same-day, actively exploited 9.2 is exactly the scenario those controls exist to catch. PCI DSS gives one month for critical patches, but an actively exploited pre-auth RCE should not use that full window. Organizations should also record this event in their incident and vulnerability-management logs and review logs from before the patch for signs of exploitation. These bugs trigger below the application layer, so application logs will show very little. Check web server and PHP-FPM error logs instead for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, unexplained PHP worker crashes or churn, and newly dropped files in web-accessible directories. If you find evidence of attempts against an unpatched host, assume process memory may have been read and rotate the secrets that server held.

‍

Closing

Your attack surface includes every layer beneath your own code, and the runtime powering most of the web is not background infrastructure: it is part of the exposure and needs the same attention as the applications running on top of it. If your team is not sure whether your PHP infrastructure is running a vulnerable version, or whether a previous exploitation attempt left anything behind, a penetration test can give you a clear answer. Thoropass pentesters regularly identify the versions of server-side components in use, map them against known vulnerabilities, and exploit them where the environment allows, including hunting for indicators of compromise such as web shells or unauthorized file drops left behind by previous attacks. Reach out to the Thoropass Pentest Team to scope an engagement.

‍