December 31, 2026 is the last day PHP 8.2 gets security fixes. Every PHP branch gets two years of active support followed by two years of security fixes only, as the supported versions page explains, and for 8.2 that second period ends with the year. From January 1, 2027 it is end of life.
According to W3Techs, as of October 9, 2026 version 8.2 ran on 28.3% of PHP 8 sites, second only to 8.3. We ran the numbers on the same data. 35.3% of PHP sites are still on versions 5 and 7, which haven't had fixes in years, and among PHP 8 sites 21.6% use 8.0 or 8.1, both out of support as well. Today roughly half of PHP sites run a supported version; with 8.2 gone, from January 1 it will be about a third.
What happens after December 31
The site keeps working, which is why the deadline keeps getting pushed back. What changes is the next vulnerability found in the language, because the fix only ships for supported versions.
That's what happened on October 21. For the two critical flaws known as php2shell, the PHP project released versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12, while 8.1 and older got no new release, only minimal source patches for people who build PHP themselves. This time anyone on 8.2 got away with a routine update, which won't be possible from January.
The same thing happened in June 2024 with CVE-2024-4577, a flaw that allowed remote code execution on PHP in CGI mode on Windows servers: fixed on June 6 in the versions supported at the time, not in 8.0. According to Wiz, by June 8 the TellYouThePass ransomware group was already using it.
Which version to move to
From January 1 there are three supported versions: 8.3 gets security fixes until December 31, 2027, 8.4 until December 31, 2028, and 8.5 until December 31, 2029. In most cases we recommend 8.4: the most common libraries and CMSs support it by now, and it gives you two years of headroom. 8.3 is a shorter jump, but in a year you're back where you started; 8.5 lasts longer and is also the youngest, so check it dependency by dependency before you pick it.
WordPress lists 8.3 as its minimum recommended version. Check what your host is doing too, because hosts don't always wait for the official date: Acquia dropped 8.2 on October 1, 2026 and moved every remaining environment to PHP 8.4 on its own.
What usually breaks in the migration
Going from 8.2 to 8.4 is rarely a matter of switching the version in the hosting panel. The clearest case is the extensions that left the standard distribution: IMAP, OCI8, PDO_OCI and PSpell are gone in 8.4, and management software that reads a mailbox through the imap_* functions just stops doing it. Then there's the framework. Laravel, Symfony and the rest declare which PHP versions they run on, and you often have to upgrade them before you can upgrade PHP. A plugin or library abandoned years ago has to be replaced, or patched by hand.
Deprecations, on the other hand, don't block anything. PHP 8.4 flags, for example, parameters that implicitly accept null, like function f(Type $x = null): the site works, but on old code the warnings can fill the logs until the real errors get lost.
To find these problems you have to run the real code on the new version. WordPress adds its own, from themes and plugins, which we covered in the article on the WordPress vulnerabilities we find in audits.
How to plan the upgrade
- Check which version your site actually runs on: the hosting panel shows it, or a
phpinfo()page in a non-public environment.php -vin a terminal can report a different version from the one the web server uses. - List what runs on top: framework, CMS, plugins, PHP extensions, libraries in
composer.json. If you use Composer,composer why-not php 8.4lists the packages blocking the upgrade. - Set up a copy of the site in a test environment on the new version and try the flows that matter: login, payments, outgoing email, imports, printing.
- Plan the production switch with the rollback ready.
If the migration won't be done by January, some distributions and vendors keep publishing fixes for unsupported versions: it's the route php.net points to for anyone still on 8.1. It covers a few months, as long as you know where the fixes come from and keep the migration on the calendar.
If your site or management software runs on PHP 8.2 or older, get in touch or see how we handle PHP migration. We start by reviewing the code and tell you how much work there is before anything touches production.