In short: Whether a PHP upgrade or a backport is the right choice depends on how long your system is still to run and how well the backport is evidenced. A backport from your own distribution on a supported operating system is a full-fledged route. Source backports, third-party sources and commercial long-term support for PHP 8.1 and older are bridges with an expiry date. In the long run, only a move to a PHP version that the PHP project still officially supports helps.
Why the question is pressing after PHP2Shell
On 21 October 2026, the PHP project fixed PHP2Shell in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For PHP 8.1 and older there are no official releases any more, only minimal source backports for 7.4, 8.0 and 8.1. According to trade press, almost all versions back to PHP 5.4 are affected.
This leaves many operators of legacy systems facing the same question: is it enough to patch the vulnerability somehow, or does the upgrade that has been postponed for years have to happen now? What an upgrade means in practice is described by our service on migrating from PHP 8.1 and older. What applies without an official update is under PHP 8.1 and older: what applies now. This article helps with the weighing in between.
What kinds of backports there are
“Backport” is a collective term. It always means that a fix from a newer version is carried over into an older one. Who does it and how well it is tested differs greatly, though.
- Distribution backport: Debian, Ubuntu, Red Hat and others take security fixes into the PHP packages of their supported releases. The version number often stays the same in the process; according to reports, Ubuntu 24.04, for example, continues to show 8.3.6 after the update. The fix is evidenced through the package changelog and the distribution’s security notices.
- Third-party source: The sury.org repository of Ondřej Surý has, according to reports, provided builds for all branches from 5.6 to 8.5. It is not the Debian security archive. Details are under The sury.org repository.
- Source backport from the PHP project: For 7.4, 8.0 and 8.1 there are minimal patches in the source code, but no ready-made releases. Anyone using them must build PHP themselves, test it and maintain it themselves in future.
- Commercial long-term support: Providers such as TuxCare ELS or Zend/HeroDevs offer maintenance for old versions. Whether and when they cover PHP2Shell must be confirmed in writing; this was not evidenced in the known sources. More on this under Long-term support for old PHP versions.
PHP upgrade or backport: the comparison
| Criterion | Upgrade to a supported version | Backport (depending on type) |
|---|---|---|
| Protection against PHP2Shell | Yes, with 8.2.35, 8.3.36, 8.4.27 or 8.5.12 | Yes, if complete and evidenced |
| Future security updates | Officially until the version’s end of support | Only as long as the respective provider maintains it |
| Evidence | Version number plus restart | Package changelog with CVE numbers, confirmation from the provider |
| Effort now | Medium to high, compatibility tests needed | Low for distribution, high for self-built |
| Effort later | Low until the next version jump | Grows with every new vulnerability |
| Risk to the application | Incompatibilities with old code and extensions | Low, behaviour stays largely the same |
| Suitability as a permanent solution | Yes | Only the distribution backport within a supported operating system |
The “effort later” row is the most important. PHP2Shell will not be the last vulnerability. Every month on a version without official support means the next alert raises the same question again.
Which target version for the upgrade?
According to php.net, every PHP branch gets two years of active support, followed by two years of security fixes only. This gives the following end dates for security support:
| Version | Security support until |
|---|---|
| PHP 8.2 | 31 December 2026 |
| PHP 8.3 | 31 December 2027 |
| PHP 8.4 | 31 December 2028 |
| PHP 8.5 | 31 December 2029 |
An upgrade to 8.2 is therefore only a short stopover. Anyone migrating anyway should aim for a version with a longer horizon, provided the CMS, shop and extensions support it. Check that in the vendor’s system requirements, not from memory. How the release cycle works is explained in PHP versions and the release cycle.
Whichever route: after installing, all PHP processes must be restarted. A backport that merely sits on the disk does not protect as long as old workers are running in memory.
A pragmatic order for legacy systems
- Immediately: Apply the interim measures from php.net or take the system off the network temporarily if no evidenced fix is available.
- In the next few days: Install an evidenced backport, preferably from your own distribution or with written confirmation from the provider.
- In parallel: Check the application’s compatibility with a supported version and set a schedule.
- In the next few months: Upgrade to the target version, prepared in a test copy, with a fallback plan.
Seeing the backport as a bridge, not as the destination, is the decisive idea.
When you do not need a service provider for this
If your server runs on a supported Debian, Ubuntu or RHEL and the distribution supplies the backport, a regular update with restart and a look at the changelog is enough. An experienced admin can manage that alone. Help is worthwhile for self-builds, third-party sources, very old versions or an application whose compatibility nobody oversees any more.
How does PHP SOS help?
- We check which PHP versions and package sources run on your servers and whether an evidenced fix is in place.
- We install backports, restart and document the evidence via the changelog.
- We test your application in a copy against the target version and name incompatibilities.
- We plan and accompany the upgrade as part of the migration from PHP 8.1 and older.
Conclusion
The distribution backport is a full-fledged route; all other backports are bridges. Anyone stuck on PHP 8.1 or older should use the backport to gain time for the upgrade, not to postpone it further.
Frequently asked questions
Is a backport as safe as an upgrade?
For the specific vulnerability that was fixed, a backport can be equivalent if it is complete and evidenced. But it fixes only what was backported. An upgrade to a supported version also brings all future official security updates.
How do I know that my backport covers PHP2Shell?
From the package changelog: it should name the CVE numbers CVE-2026-109618 and CVE-2026-109619. On Debian and Ubuntu, apt-get changelog shows this; in the RHEL family, rpm -q --changelog. The version number alone is not proof.
How long will PHP 8.2 still receive security updates?
According to php.net, security support for PHP 8.2 ends on 31 December 2026. Anyone updating to 8.2 today should therefore plan the next step right away.
Is commercial long-term support for old PHP versions worthwhile?
It can be a bridge if an upgrade is impossible in the short term. Have it confirmed in writing whether and from when PHP2Shell is covered. In the sources known so far, this was not evidenced.