PHP 8.4 and PHP2Shell: Fixed in 8.4.27, What to Do

As of 23 October 2026, the PHP project's fix for PHP2Shell on the 8.4 branch is PHP 8.4.27, released on 21 October 2026. Every older 8.4 release is affected, including 8.4.26 from 24 September 2026. Install 8.4.27 or your vendor's patched 8.4 package, restart PHP, and confirm the build that serves your site.

Many sites run PHP 8.4 without anyone choosing it. It is the default PHP on Debian 13, the PHP version Joomla 6 recommends, the runtime inside the official joomla:latest Docker image, and the PHP that cPanel uses for its own interfaces. If you are not sure which branch you are on, assume it could be 8.4 until you check.

This page covers the 8.4 dates, the packages that carry the fix on each distribution and control panel, the CMS versions that support 8.4, how to prove the fix is live, and when to think about moving on.

PHP 8.4 Branch Summary

Dates are from PHP's supported versions page, viewed on 23 October 2026.

Where PHP 8.4 Shows Up

A few common setups put you on 8.4 by default:

• Debian 13 (trixie). Debian's php package points to 8.4 on trixie.
• Joomla 6. Joomla's technical requirements list PHP 8.4 as recommended and 8.3.0 as the minimum. The official joomla:latest image runs Joomla 6.1.4 on PHP 8.4 with Apache. It was rebuilt on 22 October.
• cPanel's own PHP. cPanel says versions 138.0.18, 136.0.50 and 134.0.66 of cPanel and WHM include PHP 8.4.27. This is the PHP behind cPanel's interfaces, including Roundcube webmail. It is separate from the PHP your websites use, so update cPanel itself as well as your sites' PHP.
• RHEL 10 family. PHP 8.3 is the default there, but a php8.4 stream is available, so check which one you installed.

Joomla site owners should also read our PHP2Shell guide for Joomla. Updating Joomla does not fix this. The fix has to be in PHP. For the wider picture, see our Joomla security guide.

What Is in 8.4.27

The PHP2Shell fix appears in PHP's ChangeLog as "Fixed GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp (Avoid state corruption via bailout)." Because 8.4 is still in active support, 8.4.27 also carries a normal set of bug fixes. Two examples are a garbage collector fix (GH-24050) and an assertion failure after a throwing deprecation (GH-23896). The fixed release also turns memory_limit into a soft limit with a new hard limit above it.

One of those bundled changes caused trouble. A php-src issue reports that 8.4.27 and 8.5.12 can crash with "zend_mm_heap corrupted" in some SimpleXML code, and that the same code "passes on 8.4.26." The issue names the GH-24050 fix as the cause. It was closed as fixed in the source on 22 October. As of 23 October we could not confirm which release will ship that fix. If XML imports, feeds or integrations start failing after the update, report it to your developer or host. Going back to 8.4.26 would reopen PHP2Shell.

Debian 13: The Fixed Package and How to Install It

Debian fixes PHP in its security archive, not by moving to a new upstream release. The Debian security tracker shows, as of 23 October:

So the fix only reaches you if the server pulls from the Debian security archive. An example update, then a restart of the PHP service (Debian names it php8.4-fpm; use apache2 instead if you run mod_php):

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.4-fpm

To double-check, Debian suggests reading the package changelog, for example apt-get changelog php8.4-fpm, and looking for the entry that announces the fix. Ubuntu does not ship php8.4 in any release, so this section applies to Debian only. Our PHP-FPM guide explains restarts in more detail.

Red Hat, AlmaLinux, Rocky, Alpine and Amazon Linux

Red Hat's application streams life cycle lists the RHEL 10 PHP 8.4 stream as running from May 2026 to May 2029. The RHEL 9 entry is odd. Red Hat's security data lists php:8.4 as affected, but the RHEL 9 life cycle table we read has no PHP 8.4 row. If you run PHP 8.4 on RHEL 9, check with Red Hat or your vendor where that package came from and when it will be fixed.

AlmaLinux's fixed build keeps the 8.4.24 number. AlmaLinux tells users to confirm with rpm -q php8.4-common and compare against the patched version. On Amazon Linux 2023, see ALAS2023-2026-3303.

cPanel, CloudLinux and Plesk: Same Name, Different Builds

Hosting panels are where 8.4 version numbers get confusing. cPanel's EasyApache 4 update moved ea-php84 "from v8.4.26 to v8.4.27." CloudLinux's build of the same package carried the fix as a backport, as 8.4.26-2. CloudLinux warns that "A scanner that compares version numbers may flag them" and gives this check:

rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'

If the CVE IDs appear, the build is fixed. CloudLinux says it released ea-php builds with php.net version numbers on 23 October, so a later update may show 8.4.27 instead. On Plesk, the KB says to check under Tools & Settings > PHP Settings, where versions show in the handler names, or on the command line. An example for 8.4: /opt/plesk/php/8.4/bin/php -v, which should report 8.4.27.

Proving the Fix Is Live on 8.4

The fixed releases add a directive called memory_hard_limit_percent. PHP's manual says that if it "is not recognized, the PHP version in use is affected." One example check on a server you control:

php -i | grep memory_hard_limit_percent

If a line with the name appears, that PHP knows the directive. Two caveats apply. First, the command-line PHP can differ from the PHP that serves your site, so run the check against the right binary or ask your host. Second, the test is contested. It is only safe for builds of PHP's own 8.4.27 release. Debian's 8.4.27-1~deb13u1 and Amazon's 8.4.27 packages carry that upstream version. Backported builds such as AlmaLinux's 8.4.24 or CloudLinux's 8.4.26-2 may not have the directive even though they are fixed. For those, use the package version or changelog checks above. To see what your website itself runs, use the methods in how to check your PHP version.

CMS and Framework Support for PHP 8.4

• Joomla 6: recommended 8.4, minimum 8.3.0, per the Joomla technical requirements.
• WordPress: supported from WordPress 6.7 through 7.1.
• Drupal: supported by Drupal 10.4, 10.5 and 10.6 and by Drupal 11.1 through 11.4.
• Magento and Adobe Commerce: 2.4.8 lists PHP 8.4 and 8.3.
• Laravel: supported by Laravel 11, 12 and 13.

Next Steps: Staying on 8.4 or Moving Up

PHP 8.4 leaves active support on 31 December 2026, the same day PHP 8.2 reaches end of life. After that it gets security fixes only, until 31 December 2028. Staying on 8.4 through 2027 is a sound plan for most sites. When you are ready to move up, see our PHP 8.5 page.

If you are moving into 8.4 from 8.3 or 8.2, check these changes from PHP's 8.4 migration guide first:

• The IMAP, OCI8, PDO_OCI and PSpell extensions moved out of PHP to PECL. Code that reads mail with imap_* functions breaks unless you install the extension separately.
• The E_STRICT error level was removed.
• Passing invalid types to exit() and die() now throws a TypeError.
• Implicitly nullable parameter types are deprecated, which adds warnings in older plugins.
• DBA and ODBC functions now return objects instead of resources.

Take a backup and test on a copy first. Our backup guide covers what a restorable backup looks like. Sites still on 8.3 can follow our PHP 8.3 page to patch first and upgrade later.

Conclusion

For PHP 8.4, the target is 8.4.27 or a vendor build that carries the same patch. On Debian 13 that means the security archive's 8.4.27-1~deb13u1. On RHEL 10 it means RHSA-2026:87071. On CloudLinux panels, the changelog shows the CVE IDs. Restart PHP, prove the build, and keep an eye on the SimpleXML regression. If you would like us to handle the patching and verification, see our emergency PHP patching service. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions