PHP 8.2 End of Life on December 31, 2026: What Business Owners Need to Do Now

PHP 8.2 end of life is on December 31, 2026. If your website, store, or internal system runs on PHP 8.2, that date is when the people who maintain the language stop releasing security fixes for it. Fewer than eleven weeks separate today from that deadline, which is short notice for anything that involves a development team, a hosting provider, and a production system you cannot afford to break.

This is written for the person who owns the business, not the person who writes the code. You may not know what PHP is beyond "the thing our website runs on." That is fine. What matters is what happens after December 31, what it takes to avoid it, and what your options are if the deadline arrives before the work is done.

What end of life actually means for your business

PHP is the programming language behind a large share of the web, including WordPress, many custom e-commerce platforms, and countless internal business tools built over the last two decades. Every version of PHP gets a fixed support window. For roughly the first two years after release, the PHP project fixes bugs and security holes. After that, it switches to security fixes only for a further two years. Once that second window closes, support stops entirely. No more patches, for any reason, ever.

PHP 8.2 was released in December 2022. Its active development phase ended in December 2024, and it has been in security-only mode since. December 31, 2026 is when that stops too.

You do not have to take this on faith. PHP 8.1 already crossed this line, on December 31, 2025. Any business still running 8.1 today is operating on a version of PHP that receives no fixes at all, for any vulnerability discovered from that date forward. That is the position PHP 8.2 users will be in on January 1, 2027, and it is worth understanding before you get there rather than after.

A newly discovered security flaw in an unsupported PHP version is never fixed by the people who maintain the language. Your hosting provider cannot patch it for you, because the patch does not exist. The flaw sits there, documented in public vulnerability databases for anyone to find, for as long as your system keeps running that version. Attackers do not need to be sophisticated to exploit a known, published vulnerability with no available fix. Many run automated scans looking for exactly this.

Running unsupported software is also the kind of thing that shows up badly in a cyber insurance claim, a compliance audit, or a client's vendor security questionnaire. "We were running a version with no security support" is not a sentence anyone wants to say out loud to an insurer after a breach.

How to find out what you are actually running

Before you can plan anything, you need to know which PHP version your site or application currently uses. A few ways to get that answer without touching any code yourself:

Ask your hosting provider directly. Most hosting control panels (cPanel, Plesk, a managed WordPress host's dashboard) show the PHP version somewhere in the account or server settings, and support staff can usually tell you within a few minutes if you ask by email or chat.

Ask whoever built or maintains your site. If you have a developer, an agency, or a freelancer on retainer, this is a one-line question for them: "What PHP version are we running, and when does it reach end of life?" If they cannot answer quickly, that itself tells you something about how closely the system is being maintained.

Check it yourself if you have WordPress. Under Tools, then Site Health, then the Info tab, there is a Server section that lists the PHP version in plain text. No code required.

If none of those are available to you, a short conversation with an independent developer who can look at the server and report back takes less time than you would expect, and it does not commit you to anything beyond that answer.

What a realistic upgrade actually involves

The honest answer is that it depends on your codebase, and anyone who gives you a number before looking at your actual code is guessing. That said, a few things reliably affect the size of the job: how old the application is, whether it depends on third-party plugins or libraries that themselves need updating, how much custom code was written specifically for your business, and whether there is an automated test suite that can confirm nothing broke.

A small WordPress site built on recent, well-maintained plugins can sometimes move to a newer PHP version in a day or two of testing. A large custom application built up over ten or fifteen years, with code written by several different developers who are long gone, is a different project entirely, and can reasonably take several weeks of careful work. We've written a detailed technical walkthrough of what that upgrade path looks like for anyone who wants the engineering detail; the short version for a business owner is that a competent team tests the upgrade on a copy of your site first, checks everything that matters still works, and only then moves it to the live system.

One thing worth deciding up front: whether to move to PHP 8.3 or PHP 8.4 rather than stopping at a version that is itself close to its own end of life. PHP 8.3 is supported until December 2027, and PHP 8.4 until December 2028. Jumping straight to one of those buys you more runway for the same disruption, which is usually the better trade.

If you cannot finish before December 31

Sometimes the honest answer is that the work will not be done in time, whether because a developer has to be found first, the application is larger than expected, or budget needs to be approved. If that is where you are, you still have options, and none of them is "do nothing and hope."

Talk to your hosting provider about extended or paid security support. Several major hosting companies and specialist vendors sell continued security patches for end-of-life PHP versions, built from the same source the open-source project used to publish for free. It costs money and is meant as a bridge, not a permanent plan, but it keeps known vulnerabilities from going unpatched while the real upgrade is scheduled.

Reduce what is exposed in the meantime. A web application firewall, tighter server-level restrictions, and making sure admin areas are not reachable from the open internet all reduce the chance that a known vulnerability in your PHP version gets found and used against you before the upgrade lands.

Get a firm date, not a vague intention. "We'll get to it soon" is how businesses end up running unsupported software for years. A fixed start date for the upgrade project, even a few weeks out, turns this from a looming risk into a scheduled task with an owner.

Where to start this week

If you take one thing from this: find out your current PHP version this week, and find out how long an upgrade will actually take for your specific system before December 31 arrives and the decision gets made for you. A short code and tech stack review or a focused legacy system upgrade engagement can usually answer both questions within a few days.

If you would like a second opinion on where your systems stand, or a hand finishing the upgrade before the deadline, reach out at hello@wolf-tech.io or visit wolf-tech.io. We have taken plenty of PHP applications through exactly this transition, and the ones that go smoothly are almost always the ones that started before the deadline felt urgent.