# Long-Term Support for Old PHP Versions: Options and Limits

> PHP extended support for 8.1 and older: which routes exist, what providers must confirm in writing and why long-term support is only a bridge.

Source: https://phpsos.de/en/blog/langzeitsupport-alte-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:** For PHP 8.1 and older, there are no official updates from the PHP project any more. Long-term support, also called extended support, comes from Linux distributions, third-party repositories or commercial services such as TuxCare ELS or Zend/HeroDevs. It can bridge the time until the upgrade if the provider confirms coverage for your version in writing. But it replaces neither the upgrade nor the maintenance of the CMS and your own code.

## Why the question is on the table right now

On 21 October 2026, the PHP2Shell fixes appeared only for the supported branches 8.5, 8.4, 8.3 and 8.2. For 7.4, 8.0 and 8.1, the PHP project provided only minimal source backports, that is, fixes in the source code without a finished release. According to the trade press, nearly all versions up to PHP 5.4 are affected.

An analysis by CybelAngel shows how large the installed base is: around 2.24 million PHP hosts reachable from the internet, of which, according to CybelAngel, 59 percent run versions with no official fix to come. For many companies, the question of long-term support is therefore no longer theoretical. And it is growing: PHP 8.2 reaches end of support on 31 December 2026.

What a legacy system needs immediately is described in [PHP 8.1 and older: what applies now](https://phpsos.de/en/php2shell/php-8-1-und-aelter/). This article helps with the medium-term question: which route carries you to the upgrade, and what must it deliver?

## PHP extended support: the routes at a glance

| Route | What it delivers | Limits |
|---|---|---|
| Long-term maintenance by the distribution | Backports in the packages, as long as the distribution version is supported | only for the PHP version that this distribution ships |
| Third-party repository | e.g. sury.org, with builds from 5.6 to 8.5 according to reports | not the distribution's security archive, a question of trust |
| Commercial long-term support | patched packages for expired versions, e.g. TuxCare ELS, Zend/HeroDevs | have coverage per version and CVE confirmed, ongoing costs |
| Self-build from source backports | your own builds from the PHP project's fixes | laborious, needed again with every vulnerability |

On the commercial offers: TuxCare describes on its website CVE fixes for expired versions from PHP 5.2 to 8.x, delivered through the existing package management, for Windows and common Linux distributions. A notice on the same page reports PHP2Shell fixes for expired PHP versions. According to the cPanel documentation, TuxCare promises fixes for vulnerabilities from CVSS 7 within 14 days of publication; on cPanel servers, domains are switched from ea-php to alt-php for this. For Zend/HeroDevs, we had no statement on PHP2Shell coverage.

Notes on the third-party route are provided by the article [The sury.org repository](https://phpsos.de/en/blog/sury-repository-php/).

## What you need from the provider in writing

Long-term support is a service of trust. You are buying the promise that future vulnerabilities will be closed. Before deciding, have the following answered in writing:

1. Which PHP versions, operating systems and package names are covered, exactly?
2. Are CVE-2026-109618 and CVE-2026-109619 closed for your version, with which package status and since when?
3. How will CVE-2026-115560 and future follow-up announcements be handled?
4. Are the extensions you use included, or only the PHP core?
5. How do you yourself verify that a patch has been applied, for example via the package changelog?
6. How long does coverage for your version last, and how is an end announced?
7. What happens to the installed packages when the contract ends?

Answers that refer only generally to "all security vulnerabilities" are not sufficient. For auditors, insurers and your own documentation, what counts is the concrete assignment of version, package and CVE.

## The limits: what long-term support does not solve

Long-term support keeps the PHP runtime up to date. Everything above that remains your task. And that is where, with legacy systems, the bigger problem usually lies.

- **The application keeps going stale:** A CMS or shop that needs PHP 8.1 is often itself no longer in use in its current version.
- **Libraries and extensions:** Composer packages and plugins often no longer receive updates for old PHP versions.
- **No substitute for restart and check:** Even patched packages take effect only after all PHP processes are restarted, and they do not remove malware that was injected beforehand.
- **Technical debt grows:** The longer the bridge, the bigger the jump in the later migration.
- **Proof becomes more laborious:** Auditors, customers and insurers increasingly ask about the patch status. An expired PHP version with third-party patches can be documented but needs more explanation than a supported version.

When is long-term support the right choice anyway? Three situations are typical: a specialist application whose vendor has not yet approved newer PHP versions; a legacy system whose replacement has already been decided and which is to run for only a few more months; or a large codebase whose conversion must be planned carefully. In all three cases, long-term support buys time for an orderly solution. It is not a solution for systems that nobody wants to look after any more.

> **Important:**
> If a legacy system ran unprotected on the internet between 17 and 21 October, first clarify whether it is compromised. Long-term support for an already infected system protects nothing.

## An exit plan belongs with it

Long-term support is a good decision when it ends with a date. Decide by when the application should run on a supported version, who is responsible for the migration and which intermediate goals apply. How long PHP branches are officially maintained is explained in [The PHP release cycle](https://phpsos.de/en/php/release-zyklus/).

Whether an upgrade or a backport is more worthwhile for your system is weighed in the article [PHP upgrade or backport?](https://phpsos.de/en/blog/php-upgrade-oder-backport/).

## How does PHP SOS help?

- **Assess the situation:** We check version, package source and patch status of your legacy systems and whether they show traces of an attack.
- **Review offers:** We compare the written commitments of a long-term support provider with your actual inventory.
- **Secure the bridge:** Until the upgrade, we apply the interim measures from php.net and restrict reachability.
- **Carry out the exit:** With the [migration from PHP 8.1 and older](https://phpsos.de/en/leistungen/php-migration-legacy/), we plan and test the move to a supported version.


## Frequently asked questions

**What is PHP extended support?**  
This refers to offers that keep supplying PHP versions with security fixes after official end of support. These can be Linux distributions, third-party repositories or commercial services such as TuxCare ELS or Zend/HeroDevs.

**Does commercial long-term support cover PHP2Shell?**  
TuxCare states on its website that it has provided PHP2Shell fixes for expired PHP versions. For your specific version, package and operating system, you should still have this confirmed in writing and verify it in the changelog.

**Is long-term support an alternative to upgrading?**  
Only for a time. It keeps the PHP runtime patched, but not the CMS, the extensions and your own code, which are often outdated as well. An exit date therefore belongs in every decision for long-term support.

**What happens when the long-term support contract ends?**  
According to the cPanel documentation on TuxCare, the installed packages keep running but no longer receive new security updates. The system is then back in the same position as before, only later.

**Does the topic apply to PHP 8.2 as well?**  
Yes, soon. With 8.2.35, PHP 8.2 still receives the PHP2Shell fix, but reaches end of support on 31 December 2026. Anyone running 8.2 should plan the move now.

## Sources

- [PHP: Supported versions](https://www.php.net/supported-versions.php)
- [TuxCare: Extended Lifecycle Support for PHP](https://tuxcare.com/extended-lifecycle-support/php/)
- [cPanel documentation: TuxCare ELS for PHP](https://docs.cpanel.net/knowledge-base/third-party/tuxcare-extended-lifecycle-support-els-php/)
- [CybelAngel: Analysis of CVE-2026-109618 and CVE-2026-109619](https://cybelangel.com/blog/critical-php-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/)