PHP 8.2 EOL: What to Do Now

PHP 8.2's security support ends 31 December 2026, so any site still running it needs an upgrade plan before that date. After that, no one patches PHP 8.2 anymore, including for critical security bugs.

This guide is for site owners, WordPress admins, and developers who looked at a hosting notice or a php -v output and thought "wait, is my PHP version still supported?" You'll get the dated PHP supported-versions table straight from php.net, what "end of life" actually changes on your server, a safe order of operations for upgrading (staging copy first, then a composer audit, then plugins and themes, then picking PHP 8.4 or 8.5), and a caveat about hosts and Linux distributions that most upgrade guides skip.

PHP 8.2 end of life: the full support table

PHP's release cycle gives every version two support phases: active support (bug and security fixes, regular point releases) and security support only (critical security fixes, released as needed). Once both end, the version is end of life, meaning php.net no longer maintains it and anyone still on it may be running unpatched vulnerabilities. These are php.net's own definitions, from its supported versions page.

Here's where every currently supported branch stands as of 24 October 2026:

Source: php.net, Supported Versions, read 24 October 2026.

A few things worth noticing in that table. PHP 8.1 isn't on the list at all anymore; it's already past end of life and no longer maintained. PHP 8.2 is in its security-fixes-only window right now and has a hard stop at the end of 2026. PHP 8.4 is still in active support until the end of 2026, which is why it's the version most sites should be aiming for.

If you want to run your own PHP end of life check instead of trusting a summary, php.net's page is the primary source and it updates with every release.

What "end of life" actually means for your site

End of life doesn't mean PHP 8.2 stops running on 1 January 2027. Your server won't shut off. What stops is the stream of fixes.

• No more security patches. If a vulnerability is found in PHP 8.2's core after it goes end of life, there is no official fix for it, ever.
• No more bug fixes. Anything that was already broken stays broken.
• Growing distance from the ecosystem. Newer versions of WordPress, Laravel, Symfony, and popular Composer packages gradually drop support for old PHP branches, so staying on 8.2 gets harder to maintain, not easier, the longer you wait.
• Compliance and vendor questionnaires. If a client or partner ever asks whether your stack is on supported software, "no" is an answer you want to avoid giving.

For a non-technical way to think about it: if your site handles customer logins, payment data, or any kind of form submission, an unpatched runtime is one more door nobody is watching. If you're unsure whether your overall setup looks exposed, our guide on whether your website is hackable walks through the common red flags, and you can run a free website security check to get a baseline without creating an account.

Step 1: Find out what you're actually running

Before planning anything, confirm your current version.

• Command line: run php -v on the server.
• WordPress: go to Tools > Site Health > Info > Server, which lists the active PHP version directly, as documented by WordPress.org.
• Shared hosting control panel: most hosts (cPanel, Plesk, etc.) show the PHP version under a "Select PHP Version" or "MultiPHP Manager" tool.
• Any app: check for a phpinfo() output or ask your host directly.

Write down the exact version, including the patch number (for example 8.2.30, not just "8.2"). That patch number matters for the next step.

Step 2: Take patch updates immediately, plan version jumps separately

There are two very different kinds of PHP update, and treating them the same way is how upgrades go wrong.

1. Patch updates within the same branch (for example 8.2.30 to 8.2.35) only contain bug and security fixes. According to php.net's release process, these are meant to be safe to apply without breaking your code, so take them as soon as they're available.
2. Moving to a new branch (for example 8.2 to 8.4) can remove deprecated functions and change default behavior. Code that relied on something PHP quietly removed will break, so this always needs testing first.

As of 24 October 2026, the latest patch releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12, all released 22 October 2026 according to the official PHP changelog. If you're on an older patch of any branch, update to the current patch first before you think about jumping branches.

The safe order to upgrade PHP 8.2 to 8.4

This is the order that avoids surprises. Don't skip the staging step, even for a small site.

1. Clone your site to a staging copy. Full copy of code, database, and files, running on the target PHP version, isolated from the live site.
2. Run composer audit against your composer.lock file (if you use Composer). This lists known security advisories for every package version you're actually running, not just what's in composer.json. Fix or update flagged packages before moving on.
3. Run composer install on staging to deploy exactly the locked versions and confirm nothing is missing.
4. Check every plugin, theme, and library for target-version support. Open each plugin or theme's changelog and look for an explicit "tested up to PHP 8.4" note, or check the vendor's documentation. A plugin that hasn't been updated in two years is the most common thing that breaks an upgrade.
5. Switch staging's PHP version and watch the error log, not just the homepage. Click through checkout flows, forms, admin screens, anything with custom code.
6. Fix what breaks on staging, not production. Deprecation warnings are usually harmless; fatal errors mean a function was removed and that code needs an update.
7. Repeat on a second staging pass once fixes are in, then schedule the production switch for a low-traffic window with a rollback plan ready.

Which version should you target?

For most small business sites, PHP 8.4 is the sensible landing spot right now: it's mature enough that plugin ecosystems have caught up, and even though its active support window closes at the end of this year, it keeps getting security fixes until 31 December 2028.

The host and Linux distro caveat nobody mentions

Here's something that trips people up. Many Linux distributions backport security fixes into their packaged PHP builds without changing the version number you see. So php -v might say 8.2.something while your distro has quietly patched specific CVEs into that exact build.

That's good news in the short term, but it means the version number alone doesn't tell you your real exposure. Ask your host directly: which PHP security fixes do they apply to their packages, and for how long after php.net's official end of life date. Don't assume; get it in writing or in their documentation. Treat this as a bridge, not a replacement for migrating off PHP 8.2 before the clock runs out.

A quick WordPress note

If your site runs WordPress, two extra things matter. First, Site Health (Tools > Site Health) flags outdated PHP directly, so check it now rather than waiting for a fire. Second, every plugin and theme you run needs to explicitly support your target PHP version; an incompatible plugin is the single most common cause of a white screen after a PHP upgrade. Test the full plugin stack on staging before touching production.

If your upgrade reveals other weak spots (exposed admin panels, missing security headers, outdated extensions), our security headers checker is a fast way to see what your current setup is missing, and it's free.

Key takeaways

• PHP 8.2's security support ends 31 December 2026; after that, no official patches exist for new vulnerabilities in it.
• Check php.net's supported versions page for the current table rather than relying on a snapshot, since dates and latest patch releases change.
• Always test a version jump (8.2 to 8.4, for example) on a staging copy first; same-branch patch updates are safe to take immediately.
• Run composer audit before and after any upgrade, and confirm every plugin or theme explicitly supports your target PHP version.
• Ask your host what they backport and for how long. It buys time, but it isn't a substitute for migrating off an end-of-life version.

If you'd rather have a second set of eyes confirm your site is actually in good shape after the upgrade, or before you start, Bug Circuit's Circuit plan is a one-time $49 manual audit: a real person checks your site and hands you a written report with severity, evidence, and exact fixes. No pressure either way, and if you just want a quick free yes/no on anything critical first, that's on the pricing page too. And if you ever suspect something's already gone wrong, our hacked website guide covers what to check first.