A lot of sites fixed PHP2Shell this week by updating PHP 8.2 to 8.2.35. That was the right call: it is a patched release and it took minutes. It is also a short-term one. PHP 8.2 reaches the end of its security support on 31 December 2026. After that date the branch gets nothing, whatever the next vulnerability looks like, and every site still on it will be exactly where the PHP 7.4 and 8.1 sites found themselves on 21 October: no release, no package, only an upgrade.
What changes on 1 January 2027
Nothing visible. Sites on 8.2 keep running. What changes is that the PHP project stops issuing fixes for the branch. Linux distributions with long support cycles may backport fixes for a while longer for their own packages, but that depends on the distribution and does not help sites on hosting panels that use upstream builds.
PHP's current support schedule, with year-end dates:
| Branch | Active support until | Security fixes until |
|---|---|---|
| PHP 8.2 | 31 December 2024 | 31 December 2026 |
| PHP 8.3 | 31 December 2025 | 31 December 2027 |
| PHP 8.4 | 31 December 2026 | 31 December 2028 |
| PHP 8.5 | 31 December 2027 | 31 December 2029 |
Which version to move to
- PHP 8.3 is the smallest step from 8.2 and buys a full year. Most WordPress plugins, themes and Composer packages that are maintained at all support it. Choose it if you want the lowest-risk move and plan to repeat the exercise at the end of 2027.
- PHP 8.4 buys two years and is the better choice when your dependencies already declare support. The notable change for custom code is that implicitly nullable parameters (
string $x = null) are deprecated; a quick search of your codebase shows how much that affects you. - PHP 8.5 is the newest branch. It is a reasonable target for new applications; for existing sites, wait until the ecosystem has caught up with it.
Why do it now and not in December
Three reasons.
- Calm beats urgency. An upgrade done in a planned window, with a staging copy and time to fix what breaks, costs less than one done during the next advisory with the site exposed in the meantime.
- Hosting queues. When the next emergency hits, hosting support queues fill up and maintenance windows are hard to get. In November they are not.
- Dependencies move slowly. If a plugin or package blocks the move, you want to find out while you have time to replace it, not while an exploit is circulating.
How the move looks
For a WordPress site on shared hosting the move is often a single change in the PHP selector, followed by a check of the key pages, the admin and any forms. Have a backup and the option to switch back for the first hour. The version-check guide shows where to confirm the result.
For a custom or Laravel application the work is in dependencies and server configuration; our Laravel checklist applies to the 8.2 to 8.3 or 8.4 move as well, with fewer deprecations to deal with.
For either, the steps are the same ones described in the end-of-life article: inventory, compatibility check, staging, fix, switch, watch.
A simple plan
- This week: note the PHP version of every site you own. Anything on 8.2 goes on the list.
- November: run the compatibility check and the staging test for each site on the list.
- Early December: switch production in a quiet window, one site at a time.
- After 31 December: nothing on 8.2 remains, and the next advisory is a routine update.
If you would like us to handle the list, send the website addresses and hosting providers and we will come back with what each site needs.