# Which PHP Versions Are Affected?

> Which PHP versions PHP2Shell affects and which are fixed: version table for 8.5 to 5.4, notes on backports, end of support and how to proceed.

Source: https://phpsos.de/en/php2shell/betroffene-php-versionen/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** The PHP vulnerability PHP2Shell affects the 8.2 to 8.5 branches up to the releases of 21 October 2026 and, according to the trade press, nearly all versions going back to PHP 5.4. It is fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There are no official updates any more for PHP 8.1 and older, only minimal source backports for 7.4, 8.0 and 8.1.

## Which versions has the PHP vulnerability affected?

PHP2Shell comprises the two vulnerabilities CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on CVSS v4.0. Both allow remote execution of malicious code without logging in. On 21 October 2026 at 14:00 UTC (16:00 German time), the PHP project released fixes for all supported branches.

| PHP branch | Last version before the fix | Fixed from | Support |
|---|---|---|---|
| 8.5 | 8.5.11 | **8.5.12** | officially supported |
| 8.4 | 8.4.26 | **8.4.27** | officially supported |
| 8.3 | 8.3.35 | **8.3.36** | officially supported |
| 8.2 | 8.2.34 | **8.2.35** | ends on 31 December 2026 |
| 8.1, 8.0, 7.4 | all versions | no official release | only minimal source backports |
| 7.3 to 5.4 | according to the trade press nearly all affected | no update | without support for years |

The information on 8.2 to 8.5 comes from the php.net advisories. The statement on versions back to PHP 5.4 comes from the trade press; there is no complete official list for legacy versions.

For non-technical readers in a few sentences: if your server runs a version from the "Fixed from" column or higher and all PHP processes were restarted afterwards, PHP2Shell is closed. If an older number is shown, either a backport is involved that your provider has to confirm, or the vulnerability is open. When in doubt, ask your IT team or hosting provider exactly about these three points: version, backport, restart.

## Affected operating modes

The version number is only half the answer. All common ways of running PHP on a web server are affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates the risk highest for mod_php, because an exploit was demonstrated there before any application code even runs. Details at [Why mod_php carries the highest risk](https://phpsos.de/en/php2shell/mod-php-risiko/).

The application offers no protection: whether WordPress, Shopware, TYPO3, Laravel or a custom development, an update of the application does not close the vulnerability in PHP.

## Backports: when the version number is misleading

Many Linux distributions and hosting providers ship PHP in their own packages. Instead of jumping to a new upstream version, they adopt the fix as a backport into their existing version. This has a practical consequence: the displayed number stays old. An example from the current situation is Plesk, which can keep showing 8.2.34 although the flaw is fixed.

For you this means: the table above applies to the official releases from php.net. For packages from your distribution or from the hosting provider, the package version and the provider's confirmation decide. How to check both is shown in [Checking the PHP version and patch level correctly](https://phpsos.de/en/php2shell/php-version-pruefen/). For a quick test on the command line:

```bash
php -v
apt policy php8.3-fpm        # Debian/Ubuntu, package name differs by version and source
dnf info php-fpm             # RHEL family
```

> **Important:**
> A fixed version number on disk does not yet mean that it is running. Only after all PHP processes have been restarted does the server work with the corrected code.

## What applies to PHP 8.1 and older?

For PHP 8.1, 8.0 and 7.4 there are only minimal source backports, that is, fixes in the source code that someone has to adopt and compile themselves. Official releases will not appear. Some distributions with long-term maintenance build such fixes into their packages; whether that applies to your system can only be clarified from the package changelog or with the provider.

In the long run, there is no way around a supported version. Which PHP version your CMS or shop tolerates, you check according to the manufacturer's system requirements, for example on wordpress.org, shopware.com or typo3.org. More at [PHP 8.1 and older: what applies now](https://phpsos.de/en/php2shell/php-8-1-und-aelter/).

## And CVE-2026-115560?

On 23 October, php.net published an advisory about a third vulnerability. It only takes effect with an unusual session configuration. As of 25 October there is not yet a fixed version; until the next regular bugfix release, the remedy is `session.upload_progress.enabled=0`. A version list is only expected with the full advisory.

## How does PHP SOS help?

- **Inventory:** We record all PHP versions on your servers, including secondary installations for individual websites, which are easily overlooked.
- **Comparison:** For each installation we clarify whether an official release, a distribution backport or no fix is present.
- **Update with proof:** Through the [PHP patch service](https://phpsos.de/en/leistungen/php-patch-service/), we install the fix and restart all processes.
- **Migration plan:** For versions without official updates, we plan the move with the [migration from PHP 8.1 and older](https://phpsos.de/en/leistungen/php-migration-legacy/) and secure the server until then.


## Frequently asked questions

**Is PHP 8.3.35 still secure?**  
No, unless your provider has applied a backport. 8.3.35 is the last version before the fix; PHP2Shell is fixed in the 8.3 branch from 8.3.36. With distribution packages the number can stay the same although the flaw is fixed. In that case the package changelog or the provider's confirmation counts.

**Is PHP 7.4 affected by PHP2Shell?**  
According to the trade press, nearly all versions going back to PHP 5.4 are affected. For 7.4, 8.0 and 8.1 there are only minimal source backports and no official releases. Moving to a supported version is the reliable way.

**Why does Plesk show 8.2.34 although it has been patched?**  
Distributions and hosting providers sometimes adopt fixes as a backport into their existing packages. The version number then stays the same, and the flaw is fixed nonetheless. Check the package version or have the provider confirm the patch.

**Which PHP version should I choose now?**  
A supported version that your application is approved for according to the manufacturer's system requirements. PHP 8.2 reaches the end of support on 31 December 2026; if you are switching anyway, you should plan for that.

## Sources

- [php.net: Security announcements](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: Supported versions](https://www.php.net/supported-versions.php)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)