PHP2Shell: Critical PHP Flaws Allow Remote Code Execution

PHP is shipping emergency patches today, October 21, for two critical remote code execution flaws, now called PHP2Shell, that could let an unauthenticated attacker run commands on web servers built on PHP.

The bugs, tracked as CVE-2026-109618 and CVE-2026-109619, are rated 9.2 on the CVSS v4.0 scale and sit in PHP core, not in any single plugin, theme, or framework. The PHP security team set the release for 14:00 UTC (7:30 p.m. IST), a day ahead of the planned October 22 disclosure, because details leaked early. As of 11:35 UTC, the fix had not shipped, and both CVE records were still reserved.

That leak is why the story moved so fast. Security researcher Florian Roth posted that the PHP core had a remote code execution bug rated CVSS 10.0, the PHP team issued an advanced notice that evening at 19:33 UTC, and watchTowr said it believed it had reproduced CVE-2026-109618. watchTowr CEO Benjamin Harris said, ” The vulnerabilities are real, but withheld details until patches ship.”

What is PHP2Shell, and how does it work?

PHP2Shell is the name for the pair of flaws: a crafted web request that ends with a shell on the server. PHP has not published the root cause, affected component, or attack path, and neither have the firms that reproduced it, according to Tenable. One report describes CVE-2026-109618 as a use-after-free, a memory-safety bug in which a program keeps using memory it has already released.

Leaked notes and some early write-ups pointed at PHP’s session upload-progress handling. Treat that as unconfirmed. PHP developers have since said the bugs cannot be blocked through configuration, and Aikido withdrew its earlier advice to disable session.upload_progress.enabled. “Ini settings won’t save you,” a PHP release manager said, as quoted by Tenable.

PHP’s own score is 9.2, below the 10.0 in the first leaked posts. CERT-EU said the scoring implies exploitation without authentication.

Who is affected by PHP2Shell?

Anyone running a vulnerable PHP build on an internet-facing server. Because the bug is in PHP itself, the application on top barely matters, and updating a CMS or framework alone does not close the gap. Leaked demo footage showed the same attack against stock installs of:

• WordPress, MediaWiki, phpBB, Magento, Drupal, Joomla and WHMCS
• Laravel and Symfony applications
• Plain Apache mod_php with no framework

The affected range is not confirmed. The leak claimed every version since PHP 5, and the demo video references PHP 5.4.0 and later. Only supported branches 8.2, 8.3, 8.4 and 8.5 will get fixes. PHP 8.1, 8.0, 7.x and 5.x are end of life and will get no official patch, though Linux distributions may backport fixes.

Kevin Beaumont reported the expected fixed builds as 8.5.12, 8.4.27, 8.3.36 and 8.2.35, per Tenable. PHP has not confirmed these numbers. The last regular builds were 8.5.11, 8.4.26, 8.3.35 and 8.2.34, released on September 24, according to the PHP news archive.

The scale is large. PHP runs on about 70% of websites whose server-side language is known, according to W3Techs. Mallory counted about 884,000 internet-facing hosts whose banners report PHP 8.1 or older, and about 740,000 reporting PHP with no version. Those are banner counts, not confirmed vulnerable systems.

Is PHP2Shell being exploited?

Reports conflict. Cloudflare’s CTO said the company was “seeing early attacks emerging,” per Tenable, and Aikido now says exploitation has been reported in the wild. Patchstack claimed multiple active incidents but published no evidence, SOCRadar noted. watchTowr and Huntress had seen no in-the-wild exploitation, and neither flaw is in CISA’s Known Exploited Vulnerabilities catalog.

Either way, the window is short. Sansec expects mass exploitation within 15 minutes of the patch going public, since comparing the fix with the old code shows where the bug was. Unverified proof-of-concept repositories are already on GitHub. Do not run them: leaked exploit code is a common way to spread malware.

What should you do now?

1. Inventory every PHP install, including copies bundled with control panels such as cPanel and Plesk, vendor appliances and Windows software.
2. Patch internet-facing servers first as soon as fixed builds appear, then restart PHP-FPM or the web server so the new build loads. Check your Linux distribution and hosting provider for backported packages.
3. Do not rely on php.ini changes. PHP developers say configuration will not stop these bugs.
4. If you cannot patch, follow the UK NCSC and CERT-EU advice: take the system offline or isolate it from public networks until it is fixed.
5. Cloudflare has deployed WAF rules for known attack vectors, Tenable reports. They are a stopgap that covers only traffic routed through Cloudflare, and no complete WAF rule exists yet.
6. On PHP 8.1 or older, move to a supported branch, or put the server behind a VPN or take it off the internet.
7. Alert on PHP worker processes (php-fpm, php-cgi, httpd, apache2) spawning shells, script interpreters or download tools such as curl and wget. On Linux hosts without endpoint monitoring, Florian Roth’s free process-watcher can help.

After patching, look for signs of compromise: web shells, new files in the web root, new cron jobs or scheduled tasks, new admin accounts and unusual outbound connections. Aikido advises checking back to at least June 2026. If you suspect a breach, isolate the server and preserve web and PHP logs before cleaning up.

Updates

2026-10-21, 11:35 UTC: Published ahead of the 14:00 UTC PHP release. Updated with the PHP developers’ statement that configuration changes do not mitigate the flaws. We will add the official advisory, confirmed fixed builds, the affected version range, and exploitation confirmations as they are published.