The short answer
Upgrade to PHP 8.4. Its fixed release for PHP2Shell is 8.4.27. If a plugin, framework or server package holds you back, 8.3 (fixed in 8.3.36) is an acceptable second choice.
Do not pick 8.2 for a new move. Pick 8.5 only if everything you run supports it.
Supported branches and their end of life
"End of life" here means the date the PHP project stops issuing security fixes for the branch. Dates are from the PHP project's supported versions page, read on 21 Oct 2026.
| Branch | Fixed release | End of life | Where it stands |
|---|---|---|---|
| 8.5 | 8.5.12 | 31 Dec 2029 | Newest. Released 20 Nov 2025. |
| 8.4 | 8.4.27 | 31 Dec 2028 | Recommended. Released 21 Nov 2024. |
| 8.3 | 8.3.36 | 31 Dec 2027 | Acceptable. Released 23 Nov 2023. |
| 8.2 | 8.2.35 | 31 Dec 2026 | Ends in about ten weeks. |
| 8.1 | none, source backport branch only | 31 Dec 2025 | Ended. See PHP 8.1. |
| 8.0 | none, source backport branch only | 26 Nov 2023 | Ended. |
| 7.4 | none, source backport branch only | 28 Nov 2022 | Ended. See PHP 7.4. |
Active support (bug fixes) and security support are separate. For 8.4, active support ends 31 Dec 2026 and security fixes continue until 31 Dec 2028. For 8.3, active support has already ended and only security fixes remain.
Why 8.4
- Runway. Security fixes until 31 Dec 2028 give you more than two years before the next forced jump.
- Availability. Many hosts list 8.4 in their PHP selector, and the main Linux distributions and repositories ship it. See hosts and the distribution guides.
- WordPress. The WordPress handbook lists PHP 8.4 as supported from WordPress 6.7 on. Older WordPress releases (6.4 to 6.6) do not list it.
- Fewer jumps. Going from 7.4 or 8.1 straight to 8.4 means you deal with the changes of every version in between in one pass.
One caveat: 8.4 leaves active support at the end of this year. That is normal for a two-year-old branch. Security fixes continue as listed above.
Why 8.3 is acceptable
Security fixes run until 31 Dec 2027, about 14 months from today. Choose 8.3 if a plugin or library you depend on does not yet run cleanly on 8.4, and plan the next move for 2027.
Why not 8.2
8.2 reaches end of life on 31 Dec 2026. If you migrate to it now, you migrate again within weeks. A site that is already on 8.2 should install 8.2.35 now to get the PHP2Shell fix, then schedule the move to 8.4. See PHP 8.2.
Why 8.5 only when everything supports it
8.5 has the longest support, but your software has to run on it. The WordPress handbook lists PHP 8.5 as supported from WordPress 6.9 on. Plugins, themes, Composer packages and extensions such as imagick or redis each need to support it too. Check every one before you switch; read the 8.4 to 8.5 migration guide first.
If you can verify all of it, 8.5 is a fine target. If you cannot, 8.4 is the safer one.
Plan the jump
- Install the fixed patch release of your current branch first if you are on 8.2 or 8.3. Do the version jump after, on your schedule. If you are on 8.1 or older, the jump is the fix: see if you cannot upgrade yet.
- Back up files and the database, and test a restore. Until you have restored it once, you do not know that the backup works.
- Build a staging copy that runs the target PHP version with the same extensions and the same
php.inisettings. - Scan the code. Run PHPCompatibility, and optionally Rector, on code you own. Commands are in the guides below.
- Check the plugins. In WordPress, open each plugin's page and read its "Requires PHP" field and check when it last shipped a release. Update everything on staging first. Replace plugins that have not shipped a release in years.
- Turn on full error logging on staging:
error_reporting = E_ALLandlog_errors = On. Click through logins, checkout, forms, uploads and scheduled jobs, then read the log. - Switch production, restart every PHP worker and confirm the running version. On WordPress hosting, the steps are in change the PHP version.
- Keep the old version one switch away for a few days. Most panels let you flip back.
Never edit third-party plugin code to make it pass a scan. Update the plugin or replace it.
Compatibility tools
composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs -ps --standard=PHPCompatibility --runtime-set testVersion 8.4 .
PHPCompatibility reads your source and reports code that breaks on the version you name. Rector can rewrite some of those spots for you. Neither runs your code, so staging tests still matter.
Step-by-step guides
- PHP 7.4 to 8.4: the longest jump, across 8.0 to 8.4.
- PHP 8.1 to 8.4: covers 8.2, 8.3 and 8.4.
- PHP 8.2 to 8.4: covers 8.3 and 8.4.
- PHP 8.6: why you should not wait for it.
Last reviewed on 22 October 2026.