PHP2Shell Security Advisory: Critical PHP Vulnerabilities and Recommended Actions

The PHP project has shipped an emergency security release today Wednesday, October 21, 2026 to fix two critical remote code execution flaws in PHP itself, now being called PHP2Shell. Details leaked before the patches were ready and proof-of-concept exploits are already circulating, so attacks can start before the fix is even out.

If you run a supported PHP 8 branch, the fix is a free update. If you still run PHP 7.x or 5.x, there will be no free upstream patch, and your options are a paid extended-support subscription, a third-party repository, or upgrading to PHP 8.

What happened

On the morning of October 20, 2026, a post on Hacker News described two critical remote code execution vulnerabilities in PHP core. The post was taken down, but screenshots spread quickly and a short exploitation video was briefly posted and removed. watchTowr then confirmed the flaws are real and said it had reproduced CVE-2026-109618.

The disclosure was originally under embargo until Thursday, October 22. Later on October 20, the PHP project announced it was moving the release up to today (October 21 at 14:00 UTC), and that it may release even sooner if full details go public or exploitation appears in the wild.

What we know so far:

• Both flaws are unauthenticated remote code execution in PHP itself, not in a plugin, framework or CMS. Every application running on an affected PHP build inherits the risk, including WordPress, Magento, Drupal and Joomla.
• PHP rates both critical, at CVSS v4.0 9.2. CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) abuses out-of-memory handling that can leave internal request data partially initialized. CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) lets internal state from a finished request be reused by a later request on the same worker after its memory has been freed.
• Every PHP installation serving web requests is at risk. PHP’s advisory covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php highest risk, with a demonstrated exploit that triggers from an unauthenticated request before any application code runs. Sansec describes the scope as all web servers running PHP 5.4 or later.
• Proof-of-concept exploits are circulating. Researchers have publicly claimed working reproductions of both flaws, and PoC code is being shared online. Treat every unpatched server as a target and patch now.

The name PHP2Shell is a nod to bugs like Log4Shell and the WP2Shell chain we covered in July: a request to the server ends with the attacker running code on it.

Who is affected by PHP2Shell

PHP runs about 7 in 10 websites, so a bug in PHP itself is a bug in most of the web. W3Techs puts PHP at 69.3% of websites whose server-side language it can identify, more than every other language combined.

‍

‍

W3Techs, 21 October 2026 · share of websites whose server-side language is known

‍

The PHP version decides who gets a free fix. More than a third of PHP sites (34.8%) still run PHP 7, 5 or even 4, all end of life. That is roughly 24% of all websites, about one in four, with no official PHP release fixing PHP2Shell.

‍

W3Techs, 21 October 2026 · all-websites column = version share × PHP’s 69.3%

‍

The real exposure is larger than the red bars show. W3Techs counts PHP 8.0 and 8.1 inside PHP 8, and both are also end of life. The most vulnerable sites are the ones nobody has touched in years: old client sites, abandoned WordPress installs and legacy apps on shared hosting, which are also the least likely to be monitored.

Whether you get a free patch depends on which PHP branch you run. The PHP project only ships releases for branches it still supports; everything older is end of life (EOL) upstream. Because of PHP2Shell’s severity, the PHP security team made an exception and published minimal source backports for PHP 7.4, 8.0 and 8.1, though not new releases.

EOL PHP is far more common on the web than most people expect. Old LTS servers, legacy client sites and appliances often still run PHP 7.4 or even 5.6, and those are exactly the systems that will stay exposed after today’s release. If you are not sure what you run, php -v on each server, and the PHP selector in cPanel, Plesk or DirectAdmin for each site, will tell you.

PHP 8: Apply security updates immediately

For supported PHP 8 branches, the fix costs nothing. You only need to apply it quickly.

• Distribution packages (RHEL, AlmaLinux, Rocky, Debian, Ubuntu): your OS vendor will publish updated or backported packages through the normal update channel. Watch your distribution’s security advisories and run dnf update or apt upgrade as soon as they land. Backported packages may keep the same version number, so check the advisory, not just php -v.
• Control panels (cPanel EasyApache, Plesk, DirectAdmin, CloudLinux alt-php): updated builds normally follow within hours to days of the upstream release. Make sure automatic updates are on, or apply them manually as soon as they appear.
• Self-compiled PHP or official Docker images: rebuild from the new upstream release or pull the updated image tag.

After updating, restart PHP-FPM, Apache or LiteSpeed so the patched binary is actually the one serving requests. A long-running PHP-FPM pool will keep the vulnerable code in memory until it is restarted.

PHP security patch availability

The fixed upstream versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (PHP advisory). PHP says Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. Use the trackers below to follow each vendor.

PHP 7.x and 5.x: Limited patch availability

The PHP project has not released new versions for PHP 7.x or 5.x. Given the severity of these vulnerabilities, the PHP security team provided minimal source backports for PHP 7.4, PHP 8.0 and PHP 8.1 to help people building from source or without access to an LTS vendor. These are source patches only, so you need to build, deploy and maintain PHP yourself. PHP 7.3 and older, and all of 5.x, get nothing upstream. For packaged PHP on EOL versions, backporting work exists, but it is a paid service.

• RHEL-based distributions (CentOS, AlmaLinux, Rocky Linux, CloudLinux, RHEL): TuxCare Extended Lifecycle Support (ELS) backports security fixes to EOL PHP versions and EOL operating systems. Expect PHP2Shell fixes for 5.x and 7.x to arrive there for subscribers.
• Ubuntu: Ubuntu Pro adds Expanded Security Maintenance (ESM), which covers the PHP packages shipped with older Ubuntu releases, such as PHP 7.4 on Ubuntu 20.04. Ubuntu Pro is free for personal use on up to five machines; commercial fleets need a paid plan.

A subscription buys you time, not a fix for the underlying problem. Every critical PHP bug from here on will put EOL versions in the same position, so use the breathing room to plan the move to PHP 8.

Third-party PHP repositories

Two community-maintained repositories are widely used to run PHP versions other than the one your OS ships with.

• Remi’s RPM repository for RHEL, AlmaLinux, Rocky and Fedora, maintained by Remi Collet. It packages every PHP branch side by side and is often the fastest way to get a current PHP 8 on an older RHEL-based server.
• Ondřej Surý’s PPA for Ubuntu (and deb.sury.org for Debian), maintained by Ondřej Surý, one of PHP’s Debian maintainers. It serves the same purpose on Debian-family systems.

If you already install PHP from one of these, watch the maintainer’s announcements and update as soon as new builds appear. Check with each maintainer whether fixes will reach EOL branches; don’t assume a 7.x package from these repos will be patched. Both projects run largely on volunteer time and sponsorship, so if your business depends on them, consider supporting them.

How Monarx addresses PHP2Shell

Patching is the only fix for PHP2Shell. The flaws sit in the core PHP engine and trigger before Monarx’s PHP runtime protection can intervene, so ThreatShield cannot directly prevent exploitation.

Blocking early exploit payloads is not protection. Over the past 36 hours, several researchers published purported exploits, none of them confirmed. Attackers and researchers are now spraying those proof-of-concept payloads across the internet. Imunify and Monarx both block them, but PHP core maintainers have disputed their validity, and the released patch shows they were misguided. Upgrading remains the only effective mitigation.

Monarx still helps after a compromise. Our malware detection, real-time protection and automated remediation help identify, block and remove malicious activity that follows a successful compromise, where our detection and protection capabilities support it. Our security team is monitoring PHP2Shell and will update detection and protection rules as more details emerge.

Hosting providers should patch vulnerable PHP packages first, and keep these protections in place to detect and respond to anything that gets through.

Recommended actions for hosting providers

1. Inventory every PHP install now, including per-site versions in control panels, Docker images and appliances.
2. Consider temporary WAF rules that block or rate-limit HTTP POST requests with multipart/form-data bodies to your servers or network. This can break file uploads and some forms, so prefer rate limits on sites that need uploads. You can disable these rules once all PHP versions have been upgraded to patched versions.
3. Patch internet-facing PHP 8 servers first now that the release is out (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35), then restart PHP-FPM or your web server.
4. For PHP 7.x and 5.x, decide between TuxCare ELS, Ubuntu Pro, building PHP 7.4 from the PHP security team’s source backport, or an upgrade to PHP 8. If none is possible soon, restrict access to those sites.
5. Watch for post-exploitation behavior: PHP worker processes (php-fpm, php-cgi, httpd, apache2) spawning shells or download tools, and new PHP files in web roots.
6. If you suspect compromise, isolate the server, preserve web and PHP logs, and look for webshells, new cron jobs and new user accounts.

‍

Hosting companies interested in run-time protection for their customers can contact Monarx to learn more about ThreatShield.

💡 We will update this advisory as OS vendors and control panels publish patched packages and as more technical details emerge.