php2shell: the two critical PHP flaws and what to do now

php2shell at a glance

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities in the PHP runtime itself. Researchers call the pair php2shell. Because the bugs sit in the PHP runtime, they reach WordPress, Drupal, Laravel, Magento and any other PHP software alike, provided the server handles web requests with a vulnerable PHP version.

The PHP project is blunt about workarounds in its security advisory and release notes: there are no complete mitigations, and updating is the only safe choice.

What the two flaws are

Both bugs involve how PHP handles a request that aborts partway through. The PHP advisory describes them this way:

• CVE-2026-109618. Out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and request cleanup may then treat the invalid data as valid. According to the GitHub advisory, PHP used longjmp() to abort a request on an out-of-memory error; the fix replaces that mechanism.
• CVE-2026-109619. Request-owned internal state can survive after the memory behind it has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it. That is a use-after-free that can be reached across requests.

For a defender, the cross-request behaviour matters most. A long-lived PHP worker serves many visitors one after another. Wiz Research, one of the teams that reported the bugs, writes that an attacker could read PHP worker memory remotely, and that this memory may hold passwords, authentication tokens and API keys. Wiz says it reached unauthenticated code execution against the latest container images of WordPress, Drupal and Joomla during testing.

Who is affected

The PHP advisory names the scope plainly: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs. PHP-FPM, the usual setup behind Nginx, is on the list as well, so running FPM is no reason to wait.

Versions:

• Supported branches (8.2 to 8.5): update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP 8.2 itself reaches end of life on 31 December 2026, so plan the next upgrade while you are at it.
• PHP 8.1 and older: no official release. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP from source, and Linux distributions and LTS vendors received the patches in advance. Check your vendor's packages first.
• How far back the bugs go: Wiz writes that nearly every PHP version is affected, including releases back to PHP 5.4. The official advisories list only the supported branches.

The exposure is large. VirusTotal fingerprints roughly 5.1 million IP addresses running PHP. Of about 1.1 million that announce a version in an HTTP header, around 272,000 run a supported branch and about 758,000 run an end-of-life branch between 5.4 and 8.1. Servers on those old branches will not see an official fix.

From leak to patch in one day

The release came a day before the coordinated disclosure date because the details leaked first.

1. 20 October. Details of the two vulnerabilities leaked online ahead of the coordinated disclosure. Later that day the PHP project published an advance notice of a critical release for 21 October at 14:00 UTC, and reserved the right to release earlier if details became public or exploitation appeared.
2. 21 October, 03:02 UTC. Cloudflare began protecting customers of its free and paid WAF by default. It later reported that it had observed attack traffic targeting its customers and that attackers were changing their payloads to get past its rules.
3. 21 October, 07:34 UTC. Patchstack recorded active exploitation incidents reported by hosting partners. By 14:00 UTC, Huntress had still seen no exploitation across its own partner base.
4. 21 October, 13:52 UTC. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released, together with the two GitHub advisories, according to Patchstack's timeline. The advance notice had scheduled the release for 14:00 UTC.

The picture of exploitation is still forming. Shortly after the release, Patchstack's telemetry showed probing attacks and no hard evidence of breaches yet, and Patchstack expects that to change.

What to do now

1. Update and restart. Install the fixed release for your branch, then restart every PHP worker: FPM pools, Apache, FrankenPHP and LiteSpeed. A worker that is still running keeps the old code in memory. Confirm the result with php -v on the command line and with a phpinfo() check through the web server, because the command-line PHP and the web PHP are often different installs.

2. Rebuild what you ship. Containers carry their own PHP. Rebuild images on a patched base image and redeploy them. Managed platforms differ: some patch supported runtimes for you, others only after a rebuild or redeploy. Read your provider's bulletin.

3. Find the PHP you forgot. Inventory every place PHP runs, including admin tools, staging copies, old marketing sites and appliances that bundle PHP inside vendor software. End-of-life installs that cannot be upgraded today belong off the public internet.

4. If you cannot update today. The PHP advisory lists measures that reduce exposure to specific attack paths but do not make an installation safe:

; Apply where requests cannot override them (php.ini, FPM pool, server config), then restart every worker.
session.upload_progress.enabled = 0   ; blocks the confirmed session paths of CVE-2026-109619
memory_limit = -1                     ; CVE-2026-109618: removes the controllable memory-limit failure; other allocation failures remain
post_max_size = 8M                    ; or 32M if the application needs uploads; keep upload_max_filesize below it
fatal_error_backtraces = 0            ; PHP 8.5 only

The advisory adds three warnings. For session.upload_progress.enabled, do not rely on ini_set() or an FPM .user.ini. Do not swap the memory limit for RLIMIT_AS or RLIMIT_DATA, which can cause the vulnerable failure. And hiding diagnostics with error_reporting, display_errors or @ does not help. Setting memory_limit = -1 also removes a guard against runaway scripts, so pair it with a container or cgroup limit.

5. Do not stop at the WAF. Cloudflare itself tells customers to patch even with its rules in place, and Patchstack points out that a proxy's rules only help if the origin server accepts traffic exclusively from that proxy. If the origin answers on its own IP address, an attacker can go around the WAF.

How to tell whether you were hit

The bugs live below the application, so the first traces show up at the server level: in web server logs, PHP error logs and process activity. Signals to look for:

• Request and crash patterns. Wiz lists unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies in responses, and unexplained PHP worker churn.
• What a PHP worker starts. Huntress, citing guidance from Florian Roth, advises alerting on PHP workers that launch shells, interpreters or download tools: sh, bash, python, perl, curl, wget, nc, and on Windows cmd.exe, powershell.exe and certutil.exe. Reconnaissance commands such as whoami, id and uname -a run by the web server user are a strong sign.
• What was left behind. If you suspect a compromise, isolate the server, preserve the web server and PHP logs, and look for web shells, new files in the web root, new cron jobs or scheduled tasks, and new accounts.

Clean logs are no proof of safety. A memory read that returns another visitor's session token may look like any other request.

After the patch: what may already have left the server

A patch stops new attacks. Anything that left the server while it was exposed is already gone, and a PHP web server holds a great deal. Code running as the web worker can read what the application reads: configuration files with database passwords, mail and payment API keys, cloud credentials and session secrets. In a Laravel application that is the .env file; in WordPress it is wp-config.php. From there the database is one connection away, with customer records, staff accounts and password hashes inside.

Exploitation after a PHP fix can start within days. When a critical PHP flaw (CVE-2024-4577) was fixed on 6 June 2024, Imperva detected attacks as early as 8 June, including web shell upload attempts and the TellYouThePass ransomware. Crews like that no longer build their own tools: under the ransomware-as-a-service model, developers lease ready-made ransomware to affiliates for a share of the profits. In the MOVEit campaign of 2023, CISA describes how the CL0P gang stole data from databases through a web shell and then threatened to publish the stolen files on its data leak site. Stolen data can surface later on dark web forums and marketplaces, in Telegram channels and in leak databases. Our research on Telegram-based data sales follows that path from the attacker's command-and-control server to the listing and the payment.

For any server that ran a vulnerable PHP version on the public internet, a sound after-patch routine is:

1. Rotate secrets. Database passwords, API keys, OAuth client secrets, the application key, and any credentials stored on the server. Assume the old values are known.
2. End sessions. Invalidate active sessions and tokens, which also covers session data that may have been read from worker memory.
3. Review the database and admin accounts for users, roles and API tokens nobody created.
4. Watch for your data outside. If customer or staff data was on the server, find out early whether it is being offered. That shapes the next steps, from breach notification to warning customers about fraud.

How WebThreat can help

WebThreat does not patch servers or scan them for this vulnerability; that work belongs to your hosting, operations or security team, and the steps above are where it starts. Our part concerns the data that may have left your servers before the update.

• EDG3 is WebThreat's threat intelligence for leaked data. It watches the places where stolen data is posted and sold, including dark web forums and marketplaces, Telegram and other channels, and leak databases. For a domain you have authorized, it traces a leak back to its first post and the seller behind it, and links reposted copies while keeping the provenance of each. A briefing with a threat-intelligence analyst shows what has been posted about your domain, with every finding tied to its source.
• CEM covers your leadership. If staff accounts were in a stolen database, those records can end up in leak databases. CEM starts from your company name, finds the leadership team and checks each person's email addresses against breach corpora and leak databases from the outside, with nothing to install. The methodology explains how findings are ranked.

If your PHP servers were exposed before the update and you want to know whether anything about your company is already circulating, book an EDG3 briefing or contact us.

This article reflects the state of the disclosure on 21 October 2026. Exploitation reports are changing by the hour; the PHP advisory and your vendor's bulletins are the authority for versions and fixes.