php2shell: critical RCE in PHP (CVE-2026-109618 and CVE-2026-109619)

On 21 October 2026 PHP shipped emergency patches for two critical vulnerabilities in PHP itself, together known as php2shell (CVE-2026-109618 and CVE-2026-109619). An attacker can use them to run code on a web server running PHP, without logging in. Both vulnerabilities are rated CVSS 9.2.

There is a fix now. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP states explicitly that updating is the only complete solution. The temporary measures that circulated yesterday cover only part of the attack paths.

Developing situation. This article was updated on 21 October 2026 at 14:45 UTC, after the official PHP release, the write-ups from the researchers at Calif, Wiz and OpenAI, and the first reports of Dutch services going offline.

php2shell in short

What should you do now?

1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and then restart all PHP workers. After updating, also review your memory_limit and post_max_size, because the fix adds a new hard memory limit that ends the process once it is reached.
2. Map where else PHP runs, including forgotten test and staging servers. A vulnerability scan helps find hidden systems. On shared hosting, ask your hosting provider when they will patch.
3. If you run PHP 8.1 or older, you get no regular update. Ask your distribution for a backport or upgrade to a supported version. Given the severity, PHP did release minimal source backports for 7.4, 8.0 and 8.1.
4. If you use the volunteer-maintained rpms.remirepo.net repository, switch to distribution packages or build from source. That repository will not carry the update for now.
5. Review your logs for the traces Wiz describes: unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oddly large PHPSESSID cookies, and unexplained restarts of PHP workers.

Cannot update right away?

PHP is clear that only updating is a complete solution. PHP core developer Gina Peter Banyard put it bluntly before the release, replying to someone who thought a setting would be enough: “the only mitigation is patching/upgrading PHP. I sadly know too much.” If updating is not possible straight away, these measures reduce part of the attack paths.

• Set memory_limit=-1 administratively, for example with php_admin_value in the FPM pool or the Apache configuration, and check that no pool, directory or application setting puts a finite limit back.
• Keep post_max_size low, 8M without uploads and 32M if uploads are needed, with upload_max_filesize below it.
• Set session.upload_progress.enabled=0 and restart every worker. Do this in php.ini, the FPM pool or the server configuration. An FPM .user.ini and ini_set() do not work here, because they are applied after the moment the attack takes place.
• If you run PHP 8.5, also set fatal_error_backtraces=0 and restart all workers.
• Do not use RLIMIT_AS or RLIMIT_DATA as a memory boundary. Those cause the very allocation failure that triggers the vulnerability.

Are you vulnerable?

One thing decides the answer, and it is not the software you run but the PHP version underneath it. Wiz demonstrated unauthenticated code execution against the latest WordPress, Drupal and Joomla. A fully updated site was simply exploitable, as long as the PHP underneath was old.

So updating your application does not help. The PHP runtime comes from your server package, your hosting provider or your container image.

Which PHP versions are affected?

PHP 8.1 and older no longer receive a regular update, and PHP 8.2 reaches end of life on 31 December 2026. Given the severity, the PHP security team did release minimal source backports for 7.4, 8.0 and 8.1.

How big is the risk in your situation?

How to check which version you run

Check the PHP version your web server uses, because php -v on the command line can show a different version than the one serving your site. Distributions often ship the fix under an old-looking version number. So check for the CVE in the package changelog, as Debian advises, rather than the version string.

ps -eo args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'   # which PHP serves your site?
php -i | grep '^PHP Version'                            # which version is running?

What is php2shell?

php2shell is the collective name for two separate vulnerabilities that both lead to remote code execution. PHP published an advisory with the full technical details for each one alongside the release.

CVE-2026-109618 concerns memory corruption on out-of-memory. PHP uses longjmp() to abort a request as soon as memory runs out. At certain moments the request memory is already reachable while it is not yet fully initialised. If PHP aborts there, that memory is left in an invalid state and the cleanup routine processes it as if it were valid. An attacker can trigger that memory exhaustion deliberately, for example with a multipart request containing an unrestricted number of headers that stays well within your configured limits.

CVE-2026-109619 concerns the reuse of freed memory. PHP keeps internal state in a worker that is owned by a single request. If that state is not cleared before the request memory is released, the worker points to memory that is no longer its own. A later request handled by the same worker can use that stale state before normal initialisation replaces it. That is a use-after-free, and with a carefully crafted heap it yields code execution.

Two paths are confirmed for that second vulnerability. One runs through warnings about invalid or deprecated INI settings applied before normal initialisation. The other runs through session upload progress, a feature that is enabled by default and needs no session_start() in your own code. On PHP 8.5, the backtrace on a fatal error is the most strongly demonstrated path.

The highest risk sits with Apache and mod_php. It always calls the cleanup routine, even when starting the request has already failed. That lets an attacker strike before your own code even begins. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected too, although more is needed there. Meanwhile, GitHub repositories are circulating that claim to exploit the vulnerability. Do not run code from unknown accounts on your servers.

Why does php2shell hit so many servers?

The vulnerability is not in the software on top, but in PHP itself, the layer underneath. Updating WordPress, for example, does not help. And PHP runs almost everywhere:

• 69.3% of all websites with a known server-side language run on PHP (W3Techs).
• 39.6% of all sites run on WordPress. Other off-the-shelf software is written in PHP too, such as Joomla, Drupal, Magento, WooCommerce, Nextcloud, MediaWiki (Wikipedia) and Moodle.
• Your own custom software falls under it as well: applications built with frameworks such as Laravel or Symfony, plus the cPanel and Plesk control panels many hosts use.

On top of that, no authentication is required and the flaw sits in the same place in every installation. That makes the vulnerability easy to scan at scale. On 20 October 2026, Mallory counted over 1.5 million visible PHP servers via Shodan, of which 883,717 ran an unpatched version. A successful attack yields code execution with the rights of the web server. But even without that step, an attacker can read the working memory of a PHP worker, which may hold passwords, session tokens, API keys and certificates belonging to other visitors.

How seriously organisations took this showed on the day of the patch. In the Netherlands, MijnOverheid, DigiD, the site of the lower house of parliament, the national cyber security centre and several education systems went offline as a precaution, broadcaster NOS reported. The centre had seen no abuse but urged everyone to patch. It happened elsewhere too. HR provider BambooHR took its service offline in the United States, Canada and Ireland, halting payroll processing.

Cloudflare reported the first exploit attempts around the release and called its own firewall rules an explicit stopgap. No successful break-in has been confirmed by anyone, and watchTowr had seen no exploitation in the wild on 21 October. Sansec expected mass attacks within fifteen minutes of the release, so now that the technical details are public it is a race against the clock. If you run custom software on PHP, a web application pentest maps out which systems are in the line of fire.

Who found php2shell, and how did it leak?

php2shell was found by Ryan Austin of Calif Research, during an audit of the PHP source code within OpenAI’s Patch the Planet initiative. He found the first flaw on 1 August 2026, days after that audit began. Wiz came across them independently on 19 August and demonstrated unauthenticated code execution against the latest versions of WordPress, Drupal and Joomla.

The role AI played in this stands out. Both teams used language models while searching. Wiz calls the contribution of Gemini 4 Argon and GPT-5.6 Sol to finding the vulnerability, building the exploit and validating the patch invaluable. These are memory bugs in code that has been running on millions of servers for years.

The report itself followed the rules. Calif reported the first vulnerability to PHP on 11 August and supplied a working proof-of-concept three days later. The second followed on 21 August. After that, PHP, Calif, OpenAI and Wiz spent months hunting for variants, setting up detection and validating the patch, with a coordinated disclosure planned for late October.

On 20 October 2026 it went wrong. Through a post on Hacker News the vulnerabilities leaked, two days before that planned disclosure. Shortly after, the name php2shell appeared on X, with screenshots and a video of an exploit tool, and watchTowr confirmed the vulnerabilities were real. PHP then moved the release forward by a day.

So php2shell was never a classic zero-day. PHP had known about the vulnerabilities for more than two months and was working on a fix. Because of the leak it behaved like one on that final day, with exploit code circulating while no patch existed. That window has closed, but anyone who does not update quickly stays vulnerable, precisely because the technical details are now fully public.

The events in order (Central European Summer Time):