PHP 8.2 loses security support on 31 December: why clicking "Update all plugins" is only half the job
- php
- maintenance
- hosting
- security
On 31 December 2026, PHP 8.2 reaches end of life and stops receiving security updates from the PHP project. If your company website runs on WordPress, Laravel, or WooCommerce, there is a high chance it is sitting on PHP 8.1 (which lost security support in December 2025) or PHP 8.2 right now, even if your dashboard says every plugin and theme is up to date.
When I take over a site on my £49 a month website care plan, the owner almost always tells me their previous developer or marketing agency updated the site every month. Then I check the server headers. The WordPress plugins were clicked once a month in the browser, while the underlying language runtime sitting underneath them has not been touched in three years.
The dashboard says up to date. The server says otherwise.
A website is built in layers. At the top is the content management system or web framework, along with its plugins and packages. Underneath that sits the language runtime (such as PHP, Node.js, or .NET) that actually executes the code. Underneath that sits the Linux operating system.
Clicking the update button inside an admin panel only touches the top layer. It does not upgrade PHP or Node.js on the server, because a minor language jump can break an older plugin or custom checkout script and take the site down in the middle of the afternoon. Hosting companies know this, so most shared hosts and managed VPS panels leave your site pinned to whatever PHP version was current the week the site was built, or worse, charge you an extra monthly “extended PHP support” fee on your hosting invoice just to leave an obsolete version running.
Where PHP and Node.js versions stand at the end of 2026
If you have not checked your server runtime this year, the calendar has moved faster than most people realise. Node.js 20 reached end of life back on 30 April 2026, and PHP 8.2 joins it on 31 December 2026. The current support table for PHP looks like this:
| PHP Version | Active bug fixes until | Security patches until (EOL) | Status in October 2026 |
|---|---|---|---|
| PHP 8.0 and older | Ended Nov 2022 | Ended Nov 2023 | Dead; fails PCI-DSS and Cyber Essentials |
| PHP 8.1 | Ended Nov 2023 | Ended 31 Dec 2025 | Out of support; missing 2026 security fixes |
| PHP 8.2 | Ended 31 Dec 2024 | 31 Dec 2026 (9 weeks left) | Security-only; needs upgrading before January |
| PHP 8.3 | Ended 31 Dec 2025 | 31 Dec 2027 | Security-only; safe minimum for older plugins |
| PHP 8.4 | 31 Dec 2026 | 31 Dec 2028 | Recommended target for most production sites |
| PHP 8.5 | 31 Dec 2027 | 31 Dec 2029 | Current release for clean, modern codebases |
What actually breaks when you move off PHP 8.1 or 8.2
If upgrading the runtime were as simple as picking PHP 8.4 from a dropdown menu in cPanel or Plesk, nobody would be stuck on old versions. People leave it alone because they flipped that dropdown once three years ago, got a white screen of death on their contact form, panicked, and switched it straight back.
In PHP 8.2 and 8.3, the language started complaining loudly about sloppy habits that ten-year-old WordPress themes and abandoned WooCommerce add-ons rely on, particularly dynamic class properties and loose string handling. In PHP 8.4 and 8.5, deprecated functions that used to write a quiet warning into a hidden log file now throw fatal errors that stop the page loading.
The same thing happens on custom JavaScript and TypeScript sites. Teams that built an internal portal on Node.js 18 or Node.js 20 leave it running under `systemd` or PM2 for years because `npm audit` looks scary and nobody wants to touch the build pipeline.
Why running an end-of-life runtime costs real money
Leaving a site on PHP 8.1 or letting PHP 8.2 tick past 31 December hurts in three places.
First, security vulnerabilities in the language runtime itself stop getting patched. Unless you run an enterprise Linux distribution where the vendor backports every CVE fix into their own repository packages (and you actually check that those backports cover what you have installed), a public vulnerability in the PHP engine leaves your server exposed even if every WordPress plugin is current.
Second, as I wrote last week about the stricter Cyber Essentials Danzell rules, every internet-facing service and piece of software in scope must run a supported version receiving security updates. An external web server or client portal reporting an end-of-life runtime header is an easy fail for an assessor or a cyber insurance underwriter.
Third, modern PHP is noticeably faster. Moving a busy site from PHP 8.1 to PHP 8.4 typically cuts server response times by fifteen to twenty per cent without spending a penny on bigger hardware.
How I handle runtime upgrades on my care plan
On my £49 a month Website Care Plan and server maintenance work, runtime upgrades are part of the job, not a surprise project quote every two years.
I never flip the PHP or Node version on your live website to see what happens. I pull a fresh copy of the site and database onto a staging environment running PHP 8.4 (or the current LTS release), turn on strict error logging, and test the pages that actually make you money: the checkout, the enquiry forms, the search bar, and the PDF invoice generator. If an abandoned plugin throws a fatal error, I either fix the offending lines in the child theme or replace the plugin before the live server ever changes version.
Common questions
How do I know which PHP version my website is using right now?
If you use WordPress, go to Tools → Site Health → Info → Server in your dashboard and look at the PHP version line. If it says 8.1 or lower, your runtime is already out of security support. If it says 8.2, your security support ends on 31 December 2026.
Should we upgrade straight to PHP 8.5 or move to PHP 8.4?
For a custom application where we control all the code, PHP 8.5 gives you the longest runway (security support until December 2029). For a WordPress or WooCommerce site with third-party plugins, PHP 8.4 is usually the sweet spot today: it has security support until December 2028 and broader compatibility with commercial plugins.
My host charges £7 a month for “Extended PHP Support”. Should I pay it?
No. Several big shared hosting companies charge £6 to £10 a month solely as a penalty fee for leaving your account on PHP 7.4, 8.0, or 8.1. Paying £80 to £120 a year to keep broken, outdated code limping along is backwards. Spend an hour fixing the incompatible plugin or theme, switch to PHP 8.4, and cancel the penalty fee.
If your website is still sitting on PHP 8.1 or 8.2 and you want it moved cleanly onto a supported version before the December deadline, have a look at my £49 a month Website Care Plan or send me a message with your URL and I will check what your server is running.
