Upgrade PHP
Upgrading PHP off an old branch
Sites on PHP 7.4, 8.0 or 8.1 get no PHP2Shell fix from the PHP project, and PHP 8.2 loses support on 31 December 2026. Close PHP2Shell now with a fixed build, then move your code to 8.3, 8.4 or 8.5 using the guide for your route below.
Last reviewed against php.net's supported versions and migration guides.
Choose your route
Seven upgrade routes, one guide each
Each guide lists the changes that bite on that route, in the order you meet them, with what to search your code for, how to test and how to roll back.
PHP 7.4
PHP 7.4 to 8.3
Crosses the PHP 8.0 break; lands on a branch with security fixes until the end of 2027.
PHP 7.4
PHP 7.4 to 8.4
The longest jump on this site, for teams that only want to move once.
PHP 8.0
PHP 8.0 to 8.4
Out of support since November 2023; four releases of change to absorb.
PHP 8.1
PHP 8.1 to 8.3
No PHP2Shell fix from the PHP project on 8.1, so this one is urgent.
PHP 8.1
PHP 8.1 to 8.4
The same urgency, with support on the target running to the end of 2028.
PHP 8.2
PHP 8.2 to 8.3
The smallest step off a branch that reaches end of life on 31 December 2026.
PHP 8.2
PHP 8.2 to 8.4
Two releases at once, for a longer runway before the next move.
Two jobs, not one
Fix PHP2Shell first, then migrate
A branch migration means code changes, testing and a planned switch. PHP2Shell cannot wait for that. Close it first: a fixed release if your branch has one, a backported build from your distribution, host or panel if it does not, or restricted access while you arrange either.
Then run the migration as its own project, on a staging copy, with a rollback plan that does not take you back to a vulnerable build.
Decide what to do about the live site todayWhere to land
Every target below has a PHP2Shell fix. Choose by how long you want before the next move, and by what your platform supports.
| Target | Security fixes until | Status today |
|---|---|---|
| PHP 8.3 | 31 December 2027 | Security fixes only |
| PHP 8.4 | 31 December 2028 | Active support until 31 December 2026 |
| PHP 8.5 | 31 December 2029 | Active support until 31 December 2027 |
Source: php.net's supported versions page. Full dates for every branch are on PHP end of life.
Before you start
Check the platform before the code
If your site runs on a platform such as Magento, PrestaShop, WooCommerce, Drupal, Joomla, Laravel, Moodle or Nextcloud, its release decides which PHP branches you can use. Some releases only accept older branches, so the platform upgrade has to come first or alongside the PHP move.
PHP version requirements by platformFor the server side of the switch, once the code is ready, use the guide for your server or host.
Quick answers
Upgrading PHP: questions, answered
Does upgrading PHP fix PHP2Shell?
Moving to a fixed release on a supported branch does: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and later. But a branch migration is a project, and PHP2Shell needs fixing now. If the migration will take a while, close PHP2Shell first with a fixed build or a vendor backport for the version you run, then migrate.
Should I aim for PHP 8.3, 8.4 or 8.5?
Pick the newest branch your platform, extensions and libraries support. PHP 8.3 has security fixes until 31 December 2027, 8.4 until 31 December 2028 and 8.5 until 31 December 2029. A later branch buys a longer runway, but only if everything you depend on already runs on it.
Can I skip the versions in between?
Your server can move straight to the target branch, but your code still has to cope with every change made along the way. Review the changes for each intermediate release, which is what each route guide sets out in order.
What if my platform cannot run a newer PHP yet?
Upgrade the platform first, or in step with PHP. Some platform releases only accept older branches, so the PHP move and the platform upgrade have to be planned together. Meanwhile, use a PHP build that carries the PHP2Shell fix for the version you run.
How CyPro can help
Help with the migration and the gap before it
A branch migration is a project, and the old system stays exposed until it lands. CyPro can protect it in the meantime, test the new build and help the board weigh up the options.
Fractional CISO for the board
A senior security lead who advises the board on whether to patch, mitigate or accept the risk, puts numbers on each option and owns the decision record.
More on cypro.co.uk
WAF and network hardening
Our consultants put a web application firewall in front of the site, isolate the server from the rest of your network and lock down admin access and data export.
More on cypro.co.uk
Application penetration testing
A focused test of the site and the controls around it, so you know the firewall, segmentation and monitoring hold before an attacker finds out for you.
More on cypro.co.uk
24/7 security monitoring
Our SOC analysts watch your servers day and night for the signs of exploitation: PHP workers starting shells, new outbound connections, logins that do not fit.
More on cypro.co.uk
Vulnerability scanning
Find every internet-facing PHP server you run, including the forgotten ones, and see which are still on a vulnerable build.
See the PHP exposure scan
Incident response
If a site may already be compromised, our responders contain it, preserve the evidence, find out what was touched and get you back online safely.
More on cypro.co.uk
Know your exposure
Find every PHP server you run
Patching the server you know about is the easy part. A vulnerability scan finds the forgotten staging site, the old microsite and the appliance with PHP inside, then tells you which ones are still exposed.