In short: There is no official update for the PHP 8.1 vulnerability PHP2Shell. The PHP project provides only minimal source backports for 7.4, 8.0 and 8.1, not finished releases. If you operate these versions, you need a confirmed backport from your provider or interim measures, and you should plan the move to a supported version now.
Is there an update against the PHP 8.1 vulnerability?
Not from the PHP project. On 21 October 2026, official fixes appeared only for the supported branches: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older versions no longer receive official updates.
They are affected nonetheless. According to the trade press, the vulnerable versions reach almost continuously back to PHP 5.4. Anyone who runs one of these versions with public exposure therefore has a critical vulnerability rated 9.2 on CVSS v4.0 without a finished patch.
For many companies this is a surprise, because such systems often run stably and unobtrusively for years. That a version no longer receives updates goes unnoticed in everyday operation until a vulnerability like PHP2Shell appears. The source backports for 7.4, 8.0 and 8.1 are an exception and not a resumption of regular maintenance.
What the source backports mean
For 7.4, 8.0 and 8.1 there are minimal source backports. These are fixes in the source code that have been transferred to these older branches. They are not an official release with a version number, a tested package and a changelog.
In practice this means: someone has to adopt the backport, rebuild PHP from it, test and roll it out. That can happen in three ways:
- Your distribution adopts the fix into its packages, for example as part of long-term maintenance.
- Your hosting provider builds its own PHP packages and applies the backport.
- You yourself or a service provider build PHP from source. That is demanding and has to be repeated for every further vulnerability.
Whether your system has received a backport can be checked in the package changelog:
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL family
Package names differ by distribution and package source. If an entry is missing, ask the provider. How the check works in detail is described at Checking the PHP version and patch level correctly.
Securing the old server until the migration
As long as no confirmed backport is running, the interim measures from php.net apply: a non-overridable memory_limit=-1 with a memory limit via cgroup, post_max_size of 8M or 32M with upload_max_filesize below it, and session.upload_progress.enabled=0 in the server configuration, then restart all workers. They are not full protection. Details at Immediate measures if you cannot patch yet.
In addition come measures that reduce reachability: admin areas only via VPN or approved IP addresses, switching off unneeded websites, tightly limiting access to the server. The BSI (German Federal Office for Information Security) recommends taking servers without an update off the network temporarily. For an old application that is hard to migrate, an isolated solution can be the more honest answer than operating in the open internet.
If a server with PHP 8.1 or older has been exposed on the network without protection since 17 October, take that seriously: the BSI expected rapid large-scale exploitation. Preserve the logs from 20 October onwards and have the server checked for traces before you migrate.
Planning the migration: to which version?
The target is a version that the PHP project supports and that your application tolerates. PHP 8.2 closes the vulnerability from 8.2.35 but reaches the end of support on 31 December 2026. Anyone migrating now should therefore, if possible, go to 8.3 or newer, provided the application allows it. php.net gives the current state on its page of supported versions.
Which PHP version your CMS or shop supports, you check according to the manufacturer's system requirements, for example on wordpress.org, shopware.com or typo3.org. Often the application itself has to be updated first before PHP can change. A typical case is older shops, which we describe on the page Shopware 5. Background on the consequences of outdated versions can be found at PHP end of life: risks of outdated versions.
| Step | Content |
|---|---|
| Inventory | PHP version, application, extensions, custom changes |
| Requirements | supported PHP versions according to the manufacturer |
| Test environment | copy with new PHP version, evaluate the error log |
| Switchover | planned maintenance window, rollback prepared |
| Follow-up | check interim values, set up monitoring |
How does PHP SOS help?
With the migration from PHP 8.1 and older, we guide you from the legacy version to a supported one:
- Secure immediately: check backport status, apply interim measures, reduce reachability.
- Check for traces: preserve logs from 20 October onwards and analyse them for anomalies.
- Prepare the migration: clarify compatibility according to the manufacturer, set up a test environment, fix errors.
- Switch over and prove it: install the new PHP version, restart all processes, document the state.
Frequently asked questions
Is PHP 8.1 affected by PHP2Shell?
According to the trade press, nearly all versions going back to PHP 5.4 are affected, PHP 8.1 included. The PHP project no longer publishes official updates for 8.1, only minimal source backports.
What is a source backport?
A fix in the source code that has been transferred to an older version branch. It is not a finished release: someone has to adopt it, rebuild PHP, test and roll it out. Your distribution vendor, your hosting provider or a service provider can do that.
Is it enough to switch to PHP 8.2?
In the short term, PHP 8.2.35 closes the vulnerability. PHP 8.2, however, reaches the end of support on 31 December 2026. Anyone migrating anyway should therefore check whether the application, according to the manufacturer, also supports 8.3 or newer.
My shop only runs on PHP 7.4. What now?
Then two things are needed in parallel: secure the server with interim measures and isolation, and bring the application to a version that tolerates a supported PHP version. Which that is can be found in the manufacturer's system requirements.