Treat PHP 5 as affected and unpatched
PHP 5.6, the last 5.x branch, reached end of life on 31 December 2018. Its final release was 5.6.40. Earlier 5.x branches ended years before that.
For PHP2Shell, the PHP project lists fixes for 8.2 to 8.5 and publishes source backport branches for 7.4, 8.0 and 8.1. For 5.x it has published nothing, not even a statement.
The PHP project has not said whether 5.x contains the same flaws. Some secondary sources claim every PHP 5 and later build is affected. The official advisories name only 8.2 to 8.5, and the NVD record's version ranges formally also match older builds. We cannot confirm either reading for 5.x, and we know of no trustworthy public test.
The safe assumption: treat PHP 5 as affected, with no upstream fix and none coming.
PHP 5 was already unsafe
A server on PHP 5.6 has been missing security fixes since the start of 2019. The advice was already to move off PHP 5. PHP2Shell shortens the time you have left to do it.
Who still sells PHP 5 builds
Some vendors keep patching old PHP after the PHP project stops. In what we found, none has confirmed that its PHP 5 builds cover these two CVEs. Status at our last check on 21 October 2026:
| Source | PHP 5 coverage | PHP2Shell status for PHP 5 |
|---|---|---|
| TuxCare ELS | Product page lists PHP from 5.2 | We found no entry for either CVE in its tracker |
| CloudLinux alt-php | Builds for 5.2 to 8.5 | CloudLinux says builds are "being prepared". Only alt-php74 builds were listed as shipped |
| Ubuntu Pro with Legacy Support | 14.04 ships php5 5.5.9, 16.04 ships php7.0 | Listed as fixed in USN-8948-2. Note 5.5.9, not 5.6 |
| HeroDevs NES | Starts at PHP 7.2 | Not covered |
Red Hat's data for RHEL 6 and RHEL 7, which ship PHP 5.x builds, is mixed. It lists RHEL 6 as not affected by CVE-2026-109618, "no fix planned" for CVE-2026-109619, and gives conflicting statements for RHEL 7. Do not read that as a clean bill of health. It covers only Red Hat's own old builds, and the question is still open.
A general promise of "coverage for 5.x" says nothing about CVE-2026-109618 and CVE-2026-109619. Ask the vendor about each CVE number and get the answer in writing. Compared in more detail on old PHP versions.
What to do this week
- Find out who runs the PHP. On your own server, run
php -vand note the SAPI. On shared hosting, open the PHP settings in your panel. If PHP 5 is the only choice there, the host is behind. Read the shared hosting guide and ask the questions on the triage page. - Take away the exposure you can. Put the site behind a login or VPN at the proxy if it does not need to be public. This reduces exposure but does not fix anything.
- Plan the move. There is nothing to patch 5.x with, so leaving it is the fix.
- Check for damage. Old stacks carry many other unfixed flaws, so look for signs of an earlier break-in. See after patching and, for WordPress, what to do if you are hacked.
If you manage the server and cannot move this week, WordPress.org's own PHP2Shell notice says that owners who manage their own server and run versions older than 8.2 should consider taking the server offline while they move, citing the UK NCSC. That advice comes from WordPress.org.
A realistic migration path
Going straight from 5.6 to 8.4 rarely works out. Split it into two hops and keep a working copy of the site at each one.
Hop 1: 5.6 to 7.4. This is the big jump. PHP 7.0 removed the old mysql_* functions, so any code that still calls them has to move to mysqli or PDO. Plugins, themes and libraries from the PHP 5 era often have newer versions. Where they do not, replace them. Use the PHP manual's migration guide from 5.6 to 7.0, then step through 7.1 to 7.4 on a test copy. PHP 7.4 is itself end of life, so treat it as a stepping stone and keep going.
Hop 2: 7.4 to 8.4. See the 7.4 to 8.4 guide. 8.4 is supported until 31 December 2028 and has the fixes for PHP2Shell in 8.4.27.
For WordPress, current core lists PHP 7.4 and newer as its working range and recommends 8.3 or newer. A WordPress site on PHP 5.6 likely runs an old core too, so the PHP move and the WordPress update go together. See how to check your PHP version and how to change it.
When migration is not realistic
If the application is old and unmaintained, and nobody can fix it:
- Rebuild. For a small site, moving content to a current CMS is often cheaper than porting years of PHP 5 code.
- Freeze and isolate. Turn it into static pages, or keep the old application on a private network behind a VPN.
- Pay for a vendor build, only after the vendor confirms both CVEs for the version you run.
Whatever you pick, write down the date of the decision. For the full list of options, see PHP end of life.
Last reviewed on 22 October 2026.