# PHP end of life: risks of outdated versions

> Understand PHP end of life: what happens after support ends, why PHP 8.1 and older are critical after PHP2Shell, and how to plan the move to 8.2 or later.

Source: https://phpsos.de/en/ratgeber/php-end-of-life-risiken/  
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:** PHP end of life means that the PHP project no longer delivers security updates for this branch. PHP2Shell shows the consequences clearly: there is no official fix for PHP 8.1 and older, and PHP 8.2 ends on 31 December 2026. Anyone running an old branch today should plan the move now, not at the next emergency.

## What PHP end of life means

Each PHP branch, such as 8.2 or 8.3, is maintained by the PHP project only for a limited period. First there are bug fixes and security updates, later only security updates. After that, support ends completely. php.net publishes the current periods on its page on supported versions.

After the end of support, the software does keep running. But if a new vulnerability becomes known, the PHP project no longer provides a patch. The server stays vulnerable until someone else patches it or until you switch to a supported branch.

For management and IT leadership, this is above all a planning question. A migration can be prepared calmly. Under time pressure after a critical advisory, it becomes expensive and risky.

## What PHP2Shell shows about outdated versions

On 21 October 2026 the PHP project released patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both allow remote code execution without authentication and are rated CVSS v4.0 9.2. According to the trade press, nearly all versions back to PHP 5.4 are affected.

| Branch | Status according to the PHP project | PHP2Shell fix |
|---|---|---|
| PHP 8.5 | supported | 8.5.12 |
| PHP 8.4 | supported | 8.4.27 |
| PHP 8.3 | supported | 8.3.36 |
| PHP 8.2 | supported until 31 Dec 2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | no official updates | only minimal source backports |
| PHP 7.3 and older | no official updates | no backport from the PHP project |

For 8.1 and older, the only route left is backports from distributions or hosting providers. These often keep showing the old version number even though they are patched. Only the provider can confirm bindingly whether a backport has been applied. Details are on the page [PHP 8.1 and older: what applies now](https://phpsos.de/en/php2shell/php-8-1-und-aelter/), the full overview is at [Which PHP versions are affected?](https://phpsos.de/en/php2shell/betroffene-php-versionen/).

> **Important:**
> PHP 8.2 still received the PHP2Shell fix but reaches the end of support on 31 December 2026. Anyone migrating from 8.1 now should aim directly for a newer branch.

## The risks of outdated PHP versions at a glance

The security risk is in the foreground but is not the only one. Outdated PHP versions bring further problems with them:

- **No patches for new vulnerabilities:** Every future weakness stays open or depends on backports from third parties.
- **Outdated libraries:** Current packages require newer PHP branches. Security fixes in libraries then can no longer be applied, as the guide [composer audit](https://phpsos.de/en/ratgeber/composer-abhaengigkeiten-pruefen/) shows.
- **Dependence on the provider:** Hosting providers sometimes charge surcharges for old versions or discontinue operation. The deadline is then set by the provider, not by you.
- **Problems of proof:** Towards insurers, clients or in audits, an unsupported version is hard to justify. Whether contractual or legal consequences arise from it, clarify with your insurer or a lawyer.
- **Growing migration effort:** The larger the gap to the current version, the more code has to be adapted.

Older shop systems and custom developments untouched for a long time are particularly often affected. A typical example is [Shopware 5](https://phpsos.de/en/plattformen/shopware-5/), which often still runs on older PHP branches.

## Taking stock: which PHP versions run in your environment?

The first step is a complete picture. On many servers several PHP versions run in parallel, for example for an old website nobody has on their radar any more. These commands only read:

```bash
# Version of the command line
php -v
# Installed versions on Debian/Ubuntu
ls /etc/php/
# Installed versions in Plesk
ls /opt/plesk/php/ 2>/dev/null
# Running PHP processes with version in the name
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
```

For each website, record: domain, PHP version, operating mode, CMS with version, responsible person. This list is also the basis for your emergency plan. With shared hosting you usually find the versions in the hosting provider's customer menu.

## Planning the migration: how to proceed

A migration to a supported branch generally follows the same steps, regardless of the system:

1. **Set the target:** choose a branch that, according to php.net, will be supported for as long as possible and, according to the vendor's system requirements, fits your CMS.
2. **Check compatibility:** CMS, extensions, themes and your own code. The details are on the respective vendor's official site.
3. **Set up staging:** a copy of the website with the new PHP version, including the database.
4. **Test:** all important processes, from the contact form to the ordering process, plus the error log for warnings.
5. **Switch over and restart:** change the version, restart all PHP processes, check function and error log.

Plan realistically. A small website with a current CMS is often switched quickly. A shop grown over years with many extensions and its own code, by contrast, may require adaptations of code and extensions, up to a move to a new major version of the shop system. Clarify early who decides internally, what budget is available and whether external developers have to be involved.

Also define how you will keep an eye on ends of support in future. A fixed date each year on which you compare the list of your websites with the information on php.net prevents the same bottleneck from arising again in two years.

Until the changeover, you should use the interim measures from php.net, for example `session.upload_progress.enabled=0` in the server configuration. They are not complete protection but reduce the risk.

## How does PHP SOS help?

- We record all PHP versions, operating modes and applications on your servers.
- We assess the risk per website and define the order and target version with you.
- Until the migration, we implement interim measures and obtain confirmations about backports from the provider.
- We migrate via a staging environment and document testing and changeover.

The process is described in the service [PHP 8.1 and older: migration to a supported version](https://phpsos.de/en/leistungen/php-migration-legacy/).


## Frequently asked questions

**When does support for PHP 8.2 end?**  
PHP 8.2 reaches the end of support by the PHP project on 31 December 2026. The branch still received the PHP2Shell fix with version 8.2.35; for later vulnerabilities, no official update is to be expected after that.

**Will PHP 8.1 get a patch against PHP2Shell?**  
The PHP project no longer provides official updates for 8.1 and older. Only minimal source backports exist for 7.4, 8.0 and 8.1. Whether and how your hosting provider or distribution applies them, you have to ask the provider.

**Is an old PHP version with the hosting provider's backports safe?**  
Backports can close specific vulnerabilities but do not replace a supported branch. They depend on the provider, often come later and do not cover every vulnerability. As a permanent solution they are therefore unsuitable.

**How do I know whether my CMS runs with a new PHP version?**  
Check the system requirements on the vendor's official site and test in a staging environment. The same applies to extensions and themes, because they are often the real bottleneck.

## Sources

- [php.net: supported versions](https://www.php.net/supported-versions.php)
- [php.net: security announcements](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.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)