PHP 8.0 and PHP2Shell: No Official Fix. Your Options

As of 23 October 2026, there is no official PHP 8.0 release that fixes PHP2Shell (CVE-2026-109618 and CVE-2026-109619). PHP 8.0 reached end of life on 26 November 2023, and its last release, 8.0.30, came out in August 2023. The PHP security team published only a minimal source backport. Real-world fixes come from Linux distributions, control panels and paid support vendors.

There is one large exception to "8.0 is abandoned." Red Hat Enterprise Linux 9 ships PHP 8.0 as its default PHP and still supports it, and Red Hat patched it on 21 October. AlmaLinux 9 and Rocky Linux 9 followed. Elsewhere, 8.0 is mostly found on older control-panel servers and old Docker images, and some of those sources will never be fixed.

Whatever you find, treat a patched 8.0 as a temporary state. The goal is PHP 8.3 or 8.4. This page explains who has patched 8.0, how to tell, and what the move involves.

PHP 8.0's Status After PHP2Shell

PHP 8.0.0 was released on 26 November 2020. PHP's end-of-life page lists the branch as ending on 26 November 2023, with 8.0.30 (3 August 2023) as its final release. That means a server running upstream PHP 8.0 has had no security fixes from the PHP project for almost three years before PHP2Shell was announced.

The fixed releases from 21 October 2026 are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For 8.0, PHP's advisory says to contact a distribution or LTS vendor, or "upgrade to a supported version." Researchers report the bugs go back to PHP 5.4, so 8.0 is affected. The full branch list is in our PHP2Shell fixed versions guide.

The Official 8.0 Source Backport

The PHP security team published "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." For 8.0 it is the PHP-8.0-CVE-2026-109618-109619 branch, committed on 18 October 2026 with the message "Minimal mitigation for EOL version."

• It is source code only. No release, binary or package comes with it.
• The branch still identifies itself as 8.0.30, so a build from it reports the same version as an unpatched server.
• It is meant for teams that already compile PHP. For everyone else, a vendor package built from the same fix is the practical route.

Do not run unofficial patch scripts you find online to "fix" 8.0. They are not reviewed by the PHP project, and security firms have warned that some PHP2Shell repositories on GitHub are fake. Stick to the official branch or your vendor's package.

RHEL 9: A Supported Operating System That Ships PHP 8.0

Red Hat Enterprise Linux 9's default, non-modular PHP is version 8.0. Red Hat lists it as a full-life application stream, so it gets security fixes for the life of RHEL 9, long after php.net stopped. On 21 October 2026, Red Hat published RHSA-2026:87151 with the fixed package php-8.0.30-8.el9_8.1.

• AlmaLinux 9: default PHP 8.0 fixed in php-8.0.30-8.el9_8.alma.1.
• Rocky Linux 9: RLSA-2026:87151, published 22 October.

AlmaLinux documents the update and check:

sudo dnf clean metadata && sudo dnf upgrade 'php*'
rpm -q php-common
sudo systemctl restart php-fpm

Compare the package version with the fixed one above. Do not judge by php -v: it will still say 8.0.30. AlmaLinux puts it plainly: "Don't rely on php -v: our fixes are backported, so the upstream PHP version number doesn't change." AlmaLinux 9 and 10 run PHP through PHP-FPM by default and do not ship mod_php.

A patched RHEL 9 PHP 8.0 is a supported, fixed setup. Its limit is your applications, not security updates: modern WordPress, Drupal and Joomla releases want newer PHP. RHEL 9 also offers php:8.2 and php:8.3 streams, which are both patched.

Other Sources of PHP 8.0, and Their Status

If your 8.0 comes from a control panel, the panel's packages are what matter, not the operating system's. CloudLinux notes that hosting servers "often run several PHP versions side by side," so every version that serves a website needs the update and a restart. Who does that depends on your plan, as our guide to the shared responsibility model for websites explains. Our guide on how to check your PHP version shows how to find out which build serves your site.

CMS Support for PHP 8.0

• WordPress: WordPress 7.1 still runs on PHP 8.0. WordPress.org recommends 8.3 or greater, and its news post on the PHP security release notes that PHP versions before 8.2 no longer get security updates from the PHP project.
• Drupal: Drupal 10 "requires at least PHP 8.1," so an 8.0 server cannot run Drupal 10 or 11. A Drupal site on 8.0 is on an older, unsupported Drupal as well. See our PHP2Shell guide for Drupal.
• Joomla: Joomla 5 needs PHP 8.1.0 or later and Joomla 6 needs 8.3.0, so an 8.0 Joomla site is on Joomla 4 or older.

Updating the CMS does not fix PHP2Shell, because the flaws are in PHP. But a site on 8.0 is usually behind on its CMS too, and both upgrades should be planned together.

What Breaks When You Move Off PHP 8.0

From 8.0, aim for 8.3 or 8.4. PHP 8.2 reaches end of life on 31 December 2026, so stopping there means doing this again next year. The jump stacks three sets of changes. PHP's migration guides list them; these are the ones most likely to affect older sites:

The 8.0 to 8.1 changes can stop code from running, especially old extensions that check is_resource() on FTP, LDAP or database connections. Most 8.2 and 8.3 changes are deprecations, which log warnings. Test the whole stack on staging. Our plan for upgrading an old PHP site safely walks through inventory, testing and rollback.

Your Options, in Order

1. Upgrade to PHP 8.3 or 8.4 (preferred). You get an official fixed release and security support to the end of 2027 (8.3) or 2028 (8.4). On RHEL 9 and its rebuilds, the php:8.3 stream is already patched and supported until May 2029.
2. Use a vendor-patched 8.0 as a stopgap. RHEL 9, AlmaLinux, Rocky, CloudLinux, cPanel and Plesk users can install the fixed build now. Others can buy patches from a paid LTS vendor. Restart PHP afterwards, and keep a date in the diary for the real upgrade.
3. Isolate or take the site offline. If your 8.0 comes from a source with no fix, such as the Docker 8.0 image or RHEL 8's retired stream, and you cannot switch quickly, follow the agencies. CISA says systems on "PHP 8.1 or earlier unsupported versions" should be taken offline "until they can be patched or updated." The UK NCSC says to "consider taking the system offline" if you cannot apply the temporary mitigations in time.

PHP's interim mitigations can reduce exposure for a few days but are not a fix. If you take a site down, use a maintenance page or network restriction, not a disabled PHP handler, which can expose source code and passwords. Before any change, confirm you have a working restore point; our guide to website backup and recovery explains what that means.

Docker Images on PHP 8.0

The official php:8.0 tag was last pushed on 22 November 2023. It will not receive the PHP2Shell fix. Images built on it need a new base, such as a fixed php:8.3 tag, then a rebuild, test and redeploy. Replacing the image on disk is not enough: running containers keep the old PHP until they are replaced. Images from other publishers have their own schedules, so check each one.

Conclusion

As of 23 October 2026, PHP 8.0 has no official PHP2Shell release. RHEL 9 and its rebuilds, CloudLinux, cPanel and Plesk have patched builds that still report 8.0.30, while Docker's 8.0 image and RHEL 8's retired stream have none. Patch where you can, isolate where you cannot, and move to PHP 8.3 or 8.4 as soon as testing allows. If you need hands-on help, our emergency PHP patching service can patch, isolate or upgrade with you. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions