Updated on 9 November 2026: after 31 December 2026, PHP 8.2 no longer receives any security update: the version becomes obsolete, the site keeps running, but nobody fixes it any more. Seven weeks remain to move to PHP 8.3, 8.4 or 8.5, after a backup and a test on a copy. WordPress accepts PHP 8.4 since version 6.7, Joomla 6 requires PHP 8.3 at least, and PrestaShop 8 stays stuck on PHP 8.1 until the shop moves to PrestaShop 9.
On December 31, 2026, PHP 8.2 will no longer receive security updates. This is neither a bug nor a failure: it’s the PHP project’s schedule, published for years on php.net. But after the October 2026 PHP vulnerability, this date takes on a different meaning: we’ve seen what happens to unsupported versions. Nothing. No patch, and a site left exposed.
If you read only one paragraph: if your website, store, or software runs on PHP 8.2 or an older version, plan to upgrade to PHP 8.3, 8.4, or 8.5 before the end of the year, after backing up and testing on a copy. Start by checking your site’s PHP version, and the rest will guide you with your hosting provider.
What ‘end of life’ means, in concrete terms
Each PHP version follows the same cycle, described on the supported versions page: two years of full support, where bugs and vulnerabilities are fixed, followed by two years of security support, where only critical vulnerabilities receive a patch. After four years, the version is no longer maintained.
On October 21, 2026, two critical vulnerabilities were fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1, which reached end of life on December 31, 2025, did not receive an updated version: the project published source code patches, leaving it up to each host to apply them or not. Starting January 1, 2027, PHP 8.2 will be in the same situation.
The trap is that an end of life isn’t visible. The site doesn’t stop, no message appears, and orders keep coming in. A site running PHP 8.2 will work on January 2, 2027, just as it did the day before—just without a safety net.
Depending on the source, you will read that PHP 8.2 is “obsolete”, “no longer maintained”, “unsupported” or “end of support”. These words all mean the same thing: the end of security updates, on 31 December 2026. An obsolete version is not a broken version, it is a version nobody fixes any more.
Are you affected? How to check your version
The tool I published during the October vulnerability reads your homepage header and tells you which version your server reports: check your site’s PHP version. It won’t show anything if your host hides this information, but it’s the first thing to try.
If you use WordPress, go to Tools, then Site Health, tab Information, section Server: the line ‘PHP Version’ shows the version actually used by your site, not the one displayed by your host for the entire account. Finally, your hosting provider’s client area shows the active version per domain; step-by-step guides follow below.
The version schedule, verified on October 28, 2026
Dates read on October 28, 2026, from the Supported versions page of php.net and its end-of-life page.
PHP 8.1 and older: end of life. PHP 8.1 is no longer supported as of December 31, 2025 (last version 8.1.34), PHP 8.0 as of November 26, 2023, PHP 7.4 as of November 28, 2022. If your site runs on one of these versions, you’re not anticipating a deadline: you’re already unsupported.
PHP 8.2: security support until December 31, 2026. Released on December 8, 2022, full support ended on December 31, 2024. It received the October patch; this will be one of the last ones.
PHP 8.3: security support until December 31, 2027. Released on November 23, 2023, full support ended on December 31, 2025. Switching to 8.3 gives you one year of peace, no more.
PHP 8.4: full support until December 31, 2026, then security until December 31, 2028. Released on November 21, 2024. WordPress recommends 8.3 or higher, PrestaShop 9.0 and Joomla 6 recommend 8.4: the best balance between extension compatibility and remaining duration.
PHP 8.5: full support until December 31, 2027, then security until December 31, 2029. Released on November 20, 2025. The most durable, but also the one with which the fewest extensions and themes have been tested. PrestaShop 9.1 recommends it; WordPress supports it from version 6.9 onward.
As of January 1, 2027, only three supported versions will remain: 8.3, 8.4, and 8.5.
What hosting providers offer
I reviewed the public documentation of eight hosting providers on October 28, 2026. Here’s what it says, and what it doesn’t say.
OVHcloud. The guide to available versions, updated on October 27, 2026, lists PHP 5.3 to 8.5 with their own end-of-life dates: June 30, 2029 for PHP 8.4, June 30, 2030 for PHP 8.5, « to be determined » for 8.2 and 8.3, « recommended migration » for 8.1 and older. No fees are mentioned. See the OVHcloud guide.
o2switch. The PHP version selector page, dated June 23, 2026, lists PHP 4.4 to 8.5; the « native » version, applied by default, is PHP 8.1. No fees or end-of-life dates are mentioned. See the o2switch guide.
IONOS. This is a special case. Recent versions are free, and the version change page recommends PHP 8.4. However, versions abandoned by the PHP project, from 5.6 to 8.1, fall under "Extended PHP Support", billed monthly after a free transition period; the amount is not published. PHP 8.1 was included on December 31, 2025; unless there is a policy change, PHP 8.2 will follow on December 31, 2026. After migration, the option must be explicitly canceled. See the IONOS guide.
Hostinger. Thehelp article, updated on October 27, 2026, now only offers PHP 8.2 to 8.5; 8.1 and earlier have been removed from the selector, and 8.3 is the default version. See the Hostinger guide.
Infomaniak. The FAQ on version change, updated on October 27, 2026, states that the October patches have been deployed for PHP 7.4 to 8.5, with no version number changes: Infomaniak has applied the patch to older versions. List by offer and fees: not published. See the Infomaniak guide.
PlanetHoster. The knowledge base explains how to choose the version from a dropdown list of N0C, but does not publish the list of versions, removal date, or fees. The PlanetHoster guide shows where to click.
Gandi. The PHP documentation only indicates that the automatic installation of WordPress works with PHP 8.1, 8.2, and 8.3; the full list is not published.
LWS. Thehelp article on cPanel, dated December 30, 2025, lists PHP 5.6 to 8.5 as « currently available ». No fees or withdrawals announced.
In summary: only IONOS charges for maintaining an end-of-life version, Hostinger has removed older versions from the options, and the others leave them accessible without committing to fixing them. Keeping PHP 8.2 after December 31st remains your decision—and your risk.
What to do before December 31st: four steps
1. Backup
Files and database, both, into a backup you know how to restore. The host’s backup counts, if you know where it is and how to restore it.
2. Test on a copy
With most hosts, you can create a subdomain, copy the site there, and assign it a different PHP version without touching the main site. On the copy, switch to PHP 8.4, then browse the key pages: homepage, contact form, product page, cart, checkout, customer area, accounting export. Note what breaks.
3. Change the version
Once the copy is validated, change the version on the live site, in your host’s client area, during a quiet period. If you’re coming from PHP 7, don’t jump straight to 8.5: most breaking changes lie between 7.4 and 8.0—treat that step separately.
4. Verify
Go through the key pages again, check that test orders, emails, and scheduled tasks go through, and monitor the PHP error log for a few days. If the site stops responding entirely, revert to the previous version, and make sure the problem really is on your side: is your web host down? This page shows the live status of the main web hosts: check it before you call support.
What often breaks
An abandoned extension or theme. A WordPress extension without updates for two years has rarely been tested on PHP 8.4. Check the last update date for each active extension; outdated ones need replacing—not hoping.
Moving from PHP 7 to PHP 8. PHP 8 is stricter: operations tolerated in 7.4 trigger fatal errors, and several legacy functions are gone. A custom-built app written in 2018 and never touched almost always needs a few tweaks. It’s fixable—but do it on a copy.
The software itself has a maximum version. PrestaShop 8 stops at PHP 8.1: a PrestaShop 8 store can’t upgrade to 8.2 or higher without migrating to PrestaShop 9, which supports 8.1 to 8.4 and recommends 8.5 in version 9.1. Joomla 6 requires PHP 8.3 at minimum, Laravel 12 demands PHP 8.2 or higher. Check your app’s version before PHP’s.
What if your site runs on Joomla?
After WordPress, Joomla is the case I meet most often, and the most dated one: many Joomla sites were built between 2012 and 2018 and now show, in their administration, the warning asking to plan a PHP upgrade. The rules are simple. Joomla 4 has not been supported since October 2025. Joomla 5 receives fixes until October 2027 and runs very well on PHP 8.3. Joomla 6, the current version, requires PHP 8.3 at least and refuses to install on PHP 8.2.
The order that works, the one I followed in early November 2026 on a 750-page Joomla site: full backup, test copy on PHP 8.3, latest Joomla 5 release and extension updates, then PHP 8.3 on the live site, then Joomla 6 the same day, every page compared before and after. Two points deserve a real test on the copy: the template, especially if it was built for Joomla 2.5 or 3, and the form extensions. A 2015 template went through with seven changed lines; ChronoForms 7 works on Joomla 6 with a one-line fix, even though its publisher only announces it for version 8.
What I offer for a Joomla site, prices included, is on the update page for your Joomla website.
Frequently Asked Questions
My site is still working, why change?
Because it will also work the day a vulnerability is published, and no one will fix it. In October, sites running PHP 8.1 waited for a patch that only some hosts applied; after December 31, PHP 8.2 is in that situation. A site that works and a protected site are two different things.
PHP 8.3, 8.4, or 8.5?
For a classic website or store, PHP 8.4: supported until December 31, 2028, accepted by WordPress, PrestaShop 9, and Joomla 6, with two years of extension compatibility. PHP 8.3 is a transitional choice when an extension blocks the upgrade, to be reconsidered by the end of 2027. PHP 8.5 is justified when you fully control the application’s code, or when your software recommends it, such as PrestaShop 9.1.
My host does not offer PHP 8.4
Among the hosts I’ve reviewed, OVHcloud, o2switch, Hostinger, Infomaniak, and LWS offer PHP 8.4 and 8.5, while IONOS recommends 8.4; PlanetHoster and Gandi do not publish their lists. If the version is missing from your client area, ask support in writing whether it’s planned and when. If the answer is no or unclear, a host without PHP 8.4 by the end of 2026 won’t keep up with future deadlines: planning a move now is better than doing it in a rush.
How much does it cost?
You can do it yourself: half a day for a straightforward website, including backups and checks. If you prefer to delegate, my rates are on the PHP update page for your website, store, or software: free diagnosis, 190 € for a WordPress business site, 390 € for a store or site with many extensions, starting at 690 € for custom software requiring code fixes, and 100 € per month to monitor updates for you. Prices are net.
Are WordPress and PHP 8.4 compatible?
Yes. The WordPress requirements page recommends « PHP 8.3 or higher », and the WordPress compatibility table , updated on August 19, 2026, shows PHP 8.4 supported since WordPress 6.7 and PHP 8.5 since WordPress 6.9. The question isn’t WordPress, but your plugins and theme.
What happens on 1 January 2027 if I do nothing?
Nothing visible, and that is the problem. The site displays, forms are sent, the shop takes orders. But PHP 8.2 has become obsolete: the next flaw, and there is one every year, will only be fixed in versions 8.3, 8.4 and 8.5. You will find out the day a bot exploits it, or when your host switches off the old versions, as Hostinger already did for PHP 8.1.
I am not a technician: what should I do before 31 December?
Three things, in order. Check your site's version: one minute, no account needed. Ask the person who looks after your site, or your host, which version they recommend and whether a test copy is possible. Then have the change made before the end of the year, with a backup you know how to restore. If nobody takes care of it, that is exactly what I do, at a fixed price and with a written report.
Joomla and PHP 8.3: should I move to Joomla 6 at the same time?
Yes, if your site runs Joomla 5: Joomla 6 requires PHP 8.3, so both changes are tested on the same copy and made the same day. If your site is still on Joomla 4, unsupported since October 2025, move to Joomla 5 first, then to 6. In both cases, the template and the form extensions are checked before, on the copy, not after.
Before the end of the year
December 31, 2026, isn’t a surprise: the date has been published on php.net since the release of PHP 8.2. What the October vulnerability changed is the understanding of its implications. Two months are enough to back up, test on a copy, switch versions, and verify—without rushing.
Start by check your site's PHP version. Or if you prefer someone to handle it, from backup to report, the PHP update of your site, store, or software starts with a free diagnosis: send me your site’s address, and I’ll tell you what I see and what I propose.
