PHP 8.1 and PHP2Shell: No Official Fix. Your Options

As of 23 October 2026, the PHP project has not released a fixed version of PHP 8.1 for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), and it will not. PHP 8.1 reached end of life on 31 December 2025. Its last official release, 8.1.34, is vulnerable. The only fixes for 8.1 are a minimal source backport from the PHP security team and patched packages from Linux distributions, control panels and paid support vendors.

So your options depend on where your PHP 8.1 comes from. Ubuntu 22.04 LTS, cPanel, Plesk and CloudLinux have patched builds. Amazon Linux 2023's php8.1, Red Hat's own php:8.1 stream and the official Docker 8.1 image have no fix coming.

Whatever stopgap you use, the real fix is moving to PHP 8.3 or 8.4. This page covers what is patched and how to plan the move.

PHP 8.1's Status After PHP2Shell

PHP 8.1.0 came out on 25 November 2021. According to PHP's end-of-life page, the branch reached end of life on 31 December 2025, and its final release was 8.1.34 on 18 December 2025. PHP supports each branch for four years in total, two with bug fixes and two with security fixes only. After that, the project stops releasing updates.

The PHP2Shell fixes shipped on 21 October 2026 as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP's advisory says: "PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version."

Researchers report the bugs reach back to PHP 5.4. Our PHP2Shell fixed versions table lists every branch side by side.

The Official Source Backport, and Why It Still Says 8.1.34

PHP's 21 October advisory says the 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." For 8.1, that is the PHP-8.1-CVE-2026-109618-109619 branch in the official php-src repository. Its fix commit, dated 18 October 2026, is labeled "Minimal mitigation for EOL version."

• It is source code, not a release. There is no download, no Windows build and no package. It helps only teams that already compile PHP themselves.
• It does not change the version number. The branch still defines the version as 8.1.34. A server built from it reports PHP 8.1.34 in php -v, phpinfo and WordPress Site Health, exactly like an unpatched server.
• The new memory setting test does not work for 8.1. PHP's manual says the fixed 8.2 to 8.5 releases add a directive called memory_hard_limit_percent, and that if it is not recognized, your PHP is affected. The 8.1 backport does not add that directive. A patched 8.1 build can fail that test and still be fixed.

You may also come across unofficial patch scripts or repositories posted online. Don't run them on a production server. They are not reviewed by the PHP project, and security firms have already warned that some PHP2Shell repositories on GitHub are fake or pranks. Use the official backport, or better, a vendor package built from it.

Which Distributions and Vendors Have Patched PHP 8.1

Most PHP 8.1 servers get PHP from a Linux distribution or control panel, not php.net. Status as of 23 October 2026; it changes daily, so confirm with the source.

No current Debian release ships PHP 8.1.

Ubuntu 22.04 is worth singling out. It is a fully supported LTS release that still ships PHP 8.1, and Canonical patched it on 21 October without requiring Ubuntu Pro. If that is your server, run the standard update and restart PHP:

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.1-fpm (if you use PHP-FPM; restart apache2 instead if you use mod_php)

Then confirm the package version is 8.1.2-1ubuntu2.28 or later. Compare the full package version, not the PHP version. Our guide on how to check your PHP version shows where to find it.

How to Tell Whether Your 8.1 Build Is Patched

Every patched 8.1 build keeps an old version number, so you need a different signal. Use the one that matches your source:

• Ubuntu or Debian packages: compare the installed package version with the "Fixed in" version, or read the changelog with apt-get changelog php8.1-fpm and look for the two CVE IDs.
• cPanel or CloudLinux: CloudLinux documents checking the changelog, for example rpm -q --changelog ea-php81-php-cli | grep -E 'CVE-2026-(109618|109619)'.
• Plesk: the build date must be 21 October 2026 or later. Plesk shows it in /opt/plesk/php/8.1/bin/php -v after "built:".
• Shared or managed hosting: ask your host which build serves your site. Several hosts say to check the build date in phpinfo rather than the version.

The command-line PHP can differ from the one serving your website, and every PHP worker must be restarted after an update.

CMS and Framework Versions Still on PHP 8.1

PHP 8.1 is common because several platforms still allow it:

• Drupal 10: Drupal says "Drupal 10 requires at least PHP 8.1." Drupal 10.4 to 10.6 support PHP 8.1 through 8.4. A fully supported Drupal 10 site can therefore be sitting on an end-of-life PHP. Drupal 11 needs PHP 8.3 or newer. See our PHP2Shell guide for Drupal.
• WordPress: WordPress 7.1 still runs on PHP 8.1, but WordPress.org recommends PHP 8.3 or greater.
• Joomla 5: the minimum is PHP 8.1.0, and the recommended version is 8.3. Joomla 6 needs 8.3.
• Magento: 2.4.5 supports only PHP 8.1, and 2.4.6 supports 8.2 and 8.1. Newer Magento releases need newer PHP.
• Laravel 10: supports PHP 8.1 to 8.3, but its own security fixes ended on 4 February 2025.

The flaws are in PHP, not these platforms, so a CMS update will not fix them. But your CMS version decides how far you can move PHP, so check it first, and bring core and extensions up to date as described in our security patching best practices.

What Breaks When You Move From 8.1 to 8.2 and 8.3

Skip 8.2 as a final target. It reaches end of life on 31 December 2026. Most 8.1 sites should aim for 8.3 or 8.4, which means absorbing the 8.2 and 8.3 changes in one move. PHP's migration guides list the details:

Most of these are deprecations, which produce warnings rather than errors, so 8.1 to 8.3 is one of the easier PHP upgrades if your extensions are current. Our step-by-step plan for upgrading an old PHP site safely covers staging, testing and rollback.

Your Three Options, in Order

1. Upgrade to PHP 8.3 or 8.4 (preferred). This gets you an official fixed release and years of security support: 8.3 until 31 December 2027 and 8.4 until 31 December 2028. For Drupal 10, WordPress and Joomla 5 sites with maintained extensions, this is usually a planned job, not a rebuild. Start with a tested backup (see backups and recovery).
2. Use a vendor-patched 8.1 as a stopgap. If your source is Ubuntu 22.04, cPanel, Plesk, CloudLinux or AlmaLinux, install the patched build now and restart PHP. If not, a paid LTS vendor such as Zend or Freexian can supply one. Zend itself describes this as buying time: "Use it to test your frameworks, extensions, and application code against a supported PHP release." Teams that compile PHP can build from the official backport.
3. Isolate or take the site offline. If you are on a source with no fix (Amazon Linux 2023 php8.1, RHEL 9 php:8.1, the Docker 8.1 image) and cannot switch today, follow the agencies. CISA says organizations that "continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." EU agencies advise "isolating exposed applications from public networks until fixes can be applied."

PHP's interim settings can reduce exposure while you work, but PHP says they "do not make an installation safe." Our guide to PHP2Shell interim mitigations explains each one. If you take a site down, use a maintenance page or a network restriction rather than disabling the PHP handler, which Beazley warns "can expose application source code and credentials."

Containers and Cloud Platforms on 8.1

The official Docker php image no longer builds 8.1. Its version list includes only 8.2, 8.3, 8.4 and 8.5. Any image built FROM php:8.1 carries an unpatched PHP, and pulling the tag again changes nothing. Move the base image to a fixed tag such as php:8.3 (8.3.36 or later), rebuild, test and redeploy.

On managed cloud platforms, AWS Elastic Beanstalk's updated platforms cover only 8.2 through 8.5, and Google App Engine's 8.1 runtime will not be patched. There, upgrading the runtime is the only route.

Conclusion

As of 23 October 2026, PHP 8.1 has no official PHP2Shell release, only a source backport and vendor packages that still report 8.1.34 or lower. If your source has patched it, install that build today and restart PHP. If it has not, take the agencies' advice and isolate the site. Either way, schedule the move to PHP 8.3 or 8.4 now, because the stopgaps will not last. If you need help patching or upgrading, our emergency PHP patching team can work through it with you. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions