PHP2Shell: two critical flaws in PHP's core let attackers take over web servers without a password

21 Oct 2026 5 min read 2 views Technology
Technology

On October 21, the PHP team shipped emergency security releases to fix two critical vulnerabilities in the language's core, dubbed "PHP2Shell". The flaws, CVE-2026-109618 and CVE-2026-109619, allow code execution on the server through an unauthenticated web request and affect every PHP version from 5.4 to 8.5.11. The details leaked a day before the patch and public proofs of concept already exist.

Unlike most security advisories in the PHP ecosystem, which affect a single plugin or application, the problem here lies in the interpreter itself. That means it doesn't matter whether the server runs WordPress, Drupal, Laravel or a hand-written app: if it serves web requests with a vulnerable version, it is exposed.

What happened

  • October 20, morning: a Hacker News post announced two critical PHP vulnerabilities ahead of disclosure. It was taken down, but screenshots were already circulating and watchTowr confirmed the leak.
  • October 20: PHP brought its schedule forward and announced an out-of-band security release for the next day at 14:00 UTC. The original embargo was Thursday.
  • October 21: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released. That same afternoon, Calif and Wiz Research published the technical details.

The two flaws

  • CVE-2026-109618 (out of memory): if PHP runs out of memory while preparing a request's data, the process is interrupted and that data is left only partially initialized. The later cleanup treats it as valid, opening a path to code execution.
  • CVE-2026-109619 (surviving state): part of a request's internal state lives on after its memory has been freed. The next request handled by the same PHP worker can use that stale state before it is reset, a classic use-after-free that allows memory disclosure or code execution with the web server's privileges.

The PHP project rates them 9.2 out of 10 on CVSS 4.0: network attack, no authentication or user interaction, although with high complexity. The first leaks spoke of a 10. The leaked details point to the session.upload_progress feature, which is enabled by default.

Who is affected

According to PHP, any installation serving web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP has also confirmed an exploit for mod_php in which the malicious request strikes before any application code runs, so even a fully updated WordPress offers no protection on its own.

Wiz demonstrated remote code execution against WordPress, Drupal and Joomla, plus a separate memory-leak path that could expose passwords, tokens, API keys or certificates held in the process's memory.

The problem with old versions

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are out of support and will not get a new release; the project has only published minimal source patches for 7.4, 8.0 and 8.1, aimed at people who build PHP themselves.

VirusTotal's figures give a sense of scale. Of the PHP servers that reveal their version in HTTP headers, about 272,000 run supported branches, versus about 758,000 still on versions between 5.4 and 8.1; PHP 7.4 alone accounts for some 187,000. And since four out of five servers hide their version, the real number is considerably higher.

One important caveat: many Linux distributions (Debian, Ubuntu, Red Hat) backport the fixes to their own packages without changing the version number. A Debian PHP reporting 8.2.x may be patched even if it doesn't say 8.2.35; check your distribution's security advisory.

Exploitation

Public proofs of concept have existed since before the patch. As of the afternoon of October 21, Huntress had not yet seen real-world attacks on the systems it monitors, although other sources already report attempts. Cloudflare has added emergency rules to its managed rulesets, including those on the free plan.

What to do now

  1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's patched package, and restart PHP-FPM or the web server. Start with everything exposed to the Internet.
  2. Check your Docker images: a container pinned to a PHP tag won't fix itself. Rebuild or pull the new image and recreate the container. To check the version: docker exec <container> php -v.
  3. Take inventory: PHP turns up in unexpected places, such as hosting panels (cPanel, Plesk), phpMyAdmin, Nextcloud, Roundcube or third-party software.
  4. If you can't update yet: set session.upload_progress.enabled = Off in php.ini and restart. It's a stopgap and may not cover every vector, but it greatly reduces the risk.
  5. Take unfixable systems off the Internet: installations on PHP 8.1 or earlier should sit behind a VPN or WAF while they are migrated.
  6. Watch for signs of compromise: PHP processes spawning sh, bash, curl, wget or nc, new files in the web root, unknown cron jobs or new users. And, given the memory leak, consider rotating keys and passwords on exposed servers.

What to watch next

  • Whether mass exploitation campaigns appear, as usually happens a few days after a patch with a public exploit.
  • Advisories from Linux distributions and shared hosting providers, which host thousands of sites on old versions.
  • Third-party patches for unsupported versions, whose effectiveness has not yet been assessed.

This is not the only recent scare in the PHP ecosystem: read about the supply chain attack that compromised over 700 Laravel-Lang package versions.

Conclusion: PHP2Shell is one of those flaws that justifies dropping everything to update. It hits the interpreter rather than an application, works without a password and the details are already public. Anyone still on PHP 7.4 or earlier now has the ultimate reason to migrate.

Sources and documentation

Share