PHP2Shell: the two critical PHP flaws and what a 9.2 actually means

PHP2Shell: the two critical PHP flaws and what a 9.2 actually means

Two unauthenticated remote code execution flaws in PHP core are rated 9.2, with fixes due at 14:00 UTC today. Here is what is confirmed, what is still a leak, and what to do first.

VULNERABILITIES / 2026-10-21

On October 20, 2026, the details arrived before the fix. A post on Hacker News named two critical vulnerabilities in PHP's core, security firm watchTowr confirmed they were real, and the PHP security team moved its security release forward by a day, to Wednesday, October 21 at 14:00 UTC. Both flaws, tracked as CVE-2026-109618 and CVE-2026-109619, are rated CVSS v4.0 9.2 and described as remote code execution reachable without authentication. Every current PHP branch is unpatched until that release lands.

What is confirmed, and what is still a leak

  • PHP's own notice confirms two critical vulnerabilities, both rated CVSS v4.0 9.2, in an out-of-band release scheduled for October 21 at 14:00 UTC, with full details, affected versions, and fixed versions published at the same time
  • watchTowr confirmed the flaws are real remote code execution bugs and says it reproduced CVE-2026-109618. It has not published technical detail
  • No exploitation in the wild had been reported as of the morning of October 21, and neither flaw is in CISA's Known Exploited Vulnerabilities catalog
  • CERT-EU published an advisory on October 20 stating that the 9.2 scores indicate the potential for unauthenticated remote code execution, and that the flaws may affect every PHP version from 5 onward
  • The fixed builds circulating ahead of the release, 8.2.35, 8.3.36, 8.4.27 and 8.5.12, are researcher expectations rather than an official list. PHP 8.1 and older are end of life and will get nothing upstream

How it works, as far as anyone can say

The root cause is not public. What is public is the shape of the risk. Remote code execution in PHP core means an attacker who can reach a web server sends a request and gets code running as the PHP process, before the application's own logic gets a vote. No login, no plugin, no admin panel. The flaw sits underneath WordPress, Drupal, Joomla, Magento, Laravel, Symfony and the shared hosting most of them run on, which is why a core flaw is a different category of problem from a vulnerable extension.

The leading unconfirmed theory comes from researchers reading php-src: a heap use-after-free in the upload progress handler, the code behind session.upload_progress in ext/session, reachable through a multipart form-data request. That handler has existed since PHP 5.4 and is enabled by default, which would put a very large share of the web in reach of a single unauthenticated POST. Researchers have posted that they recreated two use-after-free primitives in a lab. Treat the mechanism as unverified until the advisory ships: it is a strong lead, not a finding.

Separately, screenshots and a short video circulated of an exploit tool called PHP2Shell, credited to Calif.IO, whose banner claims it works against every PHP release from 5.4.0 onward and lists WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal and WHMCS as targets. A screenshot is not a working exploit, and none of those claims has been independently verified. Do not download bundles that promise to be it.

Why 9.2, and why the leaks said 10.0

Severity is the part of this story most likely to be repeated badly. PHP rates both flaws 9.2 under CVSS v4.0. Several early posts, including watchTowr's first statement, described them as CVSS 10.0. That is less a contradiction than a version mismatch: under CVSS v3.1 an unauthenticated, network-reachable, no-interaction remote code execution flaw was routinely scored 9.8 to 10.0, and v4.0 weights the same characteristics differently. The number that matters for a change board is the vendor's: 9.2, critical, both.

The practical meaning of 9.2 is not subtle. It implies network reachability, no privileges required, and no user interaction, with high impact on confidentiality, integrity and availability. PHP has not published the full vector, so the sub-scores are unknown, but CERT-EU's reading matches the score: unauthenticated remote code execution.

The exposure math is not evenly distributed

Two things make this worse than a typical critical CVE. The first is where the flaw lives: PHP core, below every application. A patched WordPress on an unpatched PHP is still exposed. The second is who cannot patch. Fixes will only land on the supported branches. Servers on PHP 8.1 or older will not receive an official fix at all, and Sansec's guidance is blunt: ask your provider to backport it or move you to a supported version, because the alternative is standing exposure.

If you rent hosting, you do not control this. Shared hosts, managed WordPress platforms, and commerce stacks running Magento, Shopware or WooCommerce update PHP on their own schedule. The useful question today is not whether your site is up to date, it is what PHP version your host is actually serving, checked through the web server rather than the command line.

What to do before and after 14:00 UTC

  • Inventory first: probe the PHP version through the web server, not with php -v on the shell, because the CLI often reads a different php.ini than the site does
  • Patch at 14:00 UTC. The release is expected to ship 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Confirm the actual versions on php.net when the advisory publishes, then restart PHP-FPM or your web server
  • If you cannot patch immediately, CERT-EU's advice is to isolate internet-facing applications from public networks until you can. WAF rules are not a fix here
  • A pre-patch stopgap circulating among researchers is setting session.upload_progress.enabled to Off. It may close only one of the two paths, it is not an official workaround, and it breaks real upload progress interfaces. Treat it as time, not protection
  • Rate-limit or inspect multipart form-data POSTs at the edge, especially to endpoints that have no reason to accept uploads
  • After patching, hunt: check web roots for shells, and watch for php-fpm, php-cgi or the web server spawning shells, curl, wget or nc. Patching does not remove an implant that is already there
  • Migrate anything on PHP 8.1 or older. There is no upstream fix coming for end-of-life branches
WHAT WE KNOW Confirmed: two critical remote code execution flaws in PHP core, CVSS v4.0 9.2 each, with an out-of-band release scheduled for October 21, 2026 at 14:00 UTC; no in-the-wild exploitation reported as of the morning of October 21; fixes only for the supported 8.2 to 8.5 branches. Unconfirmed: the root cause, the exact affected version range, the upload progress theory, and the PHP2Shell tool's claims. This brief was written before the advisory published and is updated as details land.