PHP 8.2 stops receiving security fixes on 31 December 2026, and many websites are already on PHP versions that get none. Here's what end-of-life means for your business and why it deserves attention now.
Ask the owner of a PHP website which version of PHP it runs, and the answer is usually a pause. The agency that built it might know, or the hosting provider. Often nobody does.
That answer has a deadline attached. Every PHP version has a published end-of-life date, after which the PHP project stops shipping security fixes for it. For PHP 8.2, one of the most widely used versions on the web, that date is 31 December 2026: ten weeks from now.
This week showed what end-of-life means in practice. When the PHP project fixed the critical PHP2Shell flaws in PHP itself, it shipped official releases for PHP 8.2 and newer. PHP 8.1 and older got no official release at all. For businesses on those versions, a serious, publicly known flaw had no straightforward fix from the people who make PHP.
What PHP end-of-life means, in plain terms
PHP is the engine that runs a large share of the web's websites and business applications. Like most software, each version of it is supported for a fixed period, and the schedule is public.
Since April 2024, the PHP project has given each version two years of active support, with regular bug fixes and security fixes, followed by two years of security fixes only. Support ends on 31 December of the relevant year. After that, the version is end-of-life: however serious a new flaw is, the PHP project will not fix it for that version.
As of this week, php.net lists four supported versions:
- PHP 8.2: security fixes only, until 31 December 2026.
- PHP 8.3: security fixes only, until 31 December 2027.
- PHP 8.4: supported until 31 December 2028.
- PHP 8.5: supported until 31 December 2029.
Everything older is already end-of-life. PHP 8.1 reached that point on 31 December 2025, PHP 8.0 in November 2023, PHP 7.4 in November 2022, and PHP 5.6 at the end of 2018. The php.net page is plain about it: users of these versions "should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities".
There is one nuance worth knowing. Some Linux distributions, such as Ubuntu, keep fixing their own packaged copies of older PHP versions for a while after the PHP project has stopped. Ubuntu did this for the PHP2Shell flaws in one older release. That is legitimate, but it only lasts as long as the distribution supports that release, and only helps if someone actually applies the updates.
What could go wrong for your business
An end-of-life date doesn't make a website vulnerable on 1 January. Nothing visibly changes. The site keeps working, which is exactly why the risk is easy to ignore.
What changes is what happens next time. When the next serious flaw is found in PHP, and there is always a next one, a site on an end-of-life version won't get an official fix. From that point, the realistic consequences are the familiar ones:
- Exposure of customer and business data if an attacker uses a known, unfixed flaw.
- Downtime and disruption while a compromised site is investigated and rebuilt.
- Unplanned costs, because an urgent upgrade under pressure is far more expensive than a planned one.
- Damage to trust with customers and partners who expect their information to be handled responsibly.
- Compliance questions, since running unsupported software can be hard to justify to auditors, clients or regulators.
There is also a slower cost. The rest of the ecosystem moves on. WordPress 7.0, released in May 2026, raised its minimum PHP version to 7.4, and WordPress's hosting handbook says that "a version that is end-of-life upstream is never recommended, even when WordPress still runs on it." Plugins and frameworks drop old PHP versions too, so a site that stays behind gradually loses access to the updates that would protect it.
Could your website be next?
The scale of the issue is larger than most businesses assume. W3Techs, which surveys the technology websites use, reports that PHP runs on 69.3% of websites whose server-side language it can identify. Working from its figures (our arithmetic, not W3Techs'), roughly half of PHP websites are on a supported version today. Once PHP 8.2 reaches end-of-life, that falls to about a third.
WordPress's own statistics tell a similar story. About 35% of the sites that report to WordPress.org already run a PHP version the PHP project no longer supports, including 15.5% on PHP 7.4.
Being on an unsupported version matters because of how attacks usually work. Attackers often use automated tools to scan large numbers of websites for known weaknesses, and they don't need to pick their targets by hand. A small business site or a forgotten microsite can be found simply because it is online and running software with a known, unfixed flaw. Having had no security incidents so far is not evidence of safety, only of luck so far.
That doesn't mean every site on old PHP will be attacked, or that every one is exposed to every flaw. It means that the protection most businesses quietly rely on, a fix arriving when a serious problem is found, is no longer there.
Why legacy PHP applications deserve attention
Sites rarely stay on old PHP versions by choice. The usual reasons are:
- The application breaks on newer PHP. PHP 8 removed or changed behaviour that older code relied on, and the work to adapt it was never budgeted.
- A dependency holds it back. One unmaintained plugin, extension or framework version can block the whole upgrade.
- The hosting plan decides. On shared and managed hosting, the provider chooses which PHP versions are available and when old ones are switched off.
- Nobody owns it. The original developers have moved on, and because the site keeps working, nobody looks.
Each skipped upgrade makes the next one larger. Moving from PHP 8.2 to 8.3 is usually routine. Moving from 7.4 to 8.4 can mean months of work. That accumulated delay, often called technical debt, is what turns a simple version change into a project.
To be fair to PHP: a site on PHP 8.4 or 8.5, kept up to date, is on a supported, actively maintained platform. The problem isn't PHP. It's PHP that nobody is keeping current. Node.js has end-of-life dates too, and a Node.js application left on an old release faces the same risk.
What this means for your organisation
For most organisations, the first step is simply knowing. Which PHP version does each of your websites and applications run, including the old microsite and the internal tool nobody mentions? When does each version reach end-of-life? And who is responsible for moving it on?
If the answers involve PHP 8.2 or anything older, the timeline is now short. Planning an upgrade or a move before 31 December is far easier than reacting after the next serious flaw is announced.
An honest picture of your current applications also makes the bigger decision clearer. For some systems, keeping PHP current is the right answer. For others, catching up costs nearly as much as rebuilding and leaves the same old architecture in place. Either way, the choice should be made deliberately, not by default.
Recommended next step
Before 31 December, find out where you stand. Our free Legacy PHP Risk Assessment can help you understand which PHP versions you run, which are already unsupported or about to be, and what is standing in the way of moving them on.
Then talk to our team about the options. Depending on your application, its architecture and your goals, that might be a planned PHP upgrade or a gradual move to a modern stack such as Node.js. No platform removes the need for routine maintenance, but the right one can make staying on supported versions a normal part of running your business rather than a crisis every few years.
Free Legacy PHP Risk Assessment
Not sure which PHP versions you're running, or what the end-of-life dates mean for your systems? We'll review your PHP versions, hosting setup and dependencies, and explain your upgrade and migration options in plain terms.
