PHP 8.2 end of life on December 31, 2026: a practical checklist

The short answer

PHP 8.2 stops receiving security fixes on December 31, 2026 (source: php.net supported versions). From then on, new flaws found in PHP 8.2 won’t be fixed by the PHP project, and the supported branches will be 8.3, 8.4 and 8.5 (source: php.net supported versions). If you run PHP 8.2 or older, plan an upgrade now. Move to PHP 8.4 (security fixes until December 31, 2028) or PHP 8.5 (until December 31, 2029), rather than 8.3, whose fixes end on December 31, 2027 (source: php.net supported versions). That way you do the work once. Start with an inventory and a compatibility check, test on a staging copy, and schedule the switch away from your busiest weeks.

What does “end of life” mean?

End of life (EOL) means a PHP branch gets no more official security fixes. Your site doesn’t stop working on January 1. What stops is the supply of fixes when the next flaw is found.

PHP2Shell showed what that looks like. When the fixes shipped on October 21, 2026, there was no official PHP release fixing PHP 8.1 or older. Those sites had to rely on their host, their Linux distribution or a paid extended-support provider, or upgrade (source: Beazley Security Labs).

php.net can extend these dates; we re-check them monthly.

How many sites does this affect?

A lot. By our calculation from W3Techs data (as of October 23, 2026), about 48% of PHP websites that reveal their version already run a branch that no longer gets official security fixes. On January 1, 2027 that rises to about 66%, unless those sites upgrade (source: W3Techs). Two caveats matter. Only sites that reveal their version are counted, and well-maintained sites often hide it, so the figure may overstate the problem. And distribution packages can carry fixes under old version numbers (source: W3Techs; AlmaLinux).

WordPress shows the same pattern. WordPress.org’s own statistics show that about a third of WordPress sites (34% as of October 24, 2026) run PHP older than 8.2. Counting 8.2, the figure is about 58% (source: WordPress.org statistics). WordPress itself is mostly up to date, thanks to automatic updates. The PHP version underneath is set by the hosting environment, and that’s where sites fall behind (source: WordPress.org version statistics).

Which version should I upgrade to?

PHP 8.4 or 8.5. Moving from 8.2 to 8.3 buys one extra year, to December 31, 2027, and then you do it all again (source: php.net supported versions). Choose 8.5 if your plugins, theme and libraries all support it; otherwise 8.4. If you’re on 7.x, expect a bigger jump and budget more testing time.

Can I stay on 8.2 with a backport instead?

As a bridge, yes. As a destination, no. Hosts, Linux distributions and paid extended-support providers can keep old branches patched after official support ends (source: Beazley Security Labs). Some hosts patched PHP2Shell on end-of-life branches without changing the version number (source: AlmaLinux). A backport fixes the flaws it targets, but the branch still gets no official PHP fixes for the next one (source: php.net unsupported branches). If you use a backport, get its end date in writing, and plan the upgrade before then.

The checklist

Phase 1. Inventory (this week)

• List every site and application, including staging copies and old sites still online.
• Record the PHP version that serves each site, not the command-line version (source: AlmaLinux).
• Record who manages each runtime: your host, you, an agency, or the client (source: GoDaddy).
• List the CMS or framework, every plugin, theme and extension, and any custom code.
• Note scheduled jobs and scripts that run PHP outside the website. They need upgrading too.

Phase 2. Check compatibility

• Check that your host offers PHP 8.4 or 8.5 on your plan. If it doesn’t, moving host becomes part of the project.
• Check each plugin’s and theme’s declared PHP support. Flag anything abandoned and pick a replacement now. On WordPress, here’s how to read it.
• Run a static compatibility scan of custom code, for example PHPCompatibility or a Rector dry run. This flags code that newer PHP versions may reject, before anything changes.
• Sort each site: switch-ready (no code changes), needs code changes, host can’t run 8.4, or bridge needed.

Phase 3. Prepare

• Take a backup stored off the server, and test that it restores.
• Make a staging copy on the target PHP version.
• Write a short test plan for what makes you money or keeps the business running: checkout, payments, forms, logins, uploads, admin screens, emails, scheduled jobs.

Phase 4. Test on staging

• Switch staging to PHP 8.4 or 8.5, with error logging on.
• Run the test plan. Fix or replace whatever breaks, then re-test.
• Record what changed, so the production switch is a repeat, not an experiment.

Phase 5. Schedule the switch

• Avoid your busiest weeks. Online stores should finish runtime changes before their holiday code freeze around Black Friday and Cyber Monday.
• Leave a buffer before December 31 for anything that goes wrong.
• Agree a rollback plan: how you’d switch back, who decides, and how long the old version stays available.

Phase 6. Switch and verify

• Switch production, then restart PHP so the new version is actually running (source: AlmaLinux).
• Confirm the version that serves the site changed, not just the command line (source: AlmaLinux).
• Re-apply your security settings. A new PHP version can come with a fresh configuration file. Check PHP’s recommended setting for CVE-2026-115560 in particular (session.upload_progress.enabled=0 at server level), which no PHP release fixes as of October 23, 2026 (source: php.net advisory on CVE-2026-115560, October 23, 2026).
• Run the test plan on production and watch error logs for a few days.

Phase 7. After

• Record the new version, date and evidence for each site. How to record it.
• Put the next end-of-life date in the calendar: December 31, 2028 for 8.4, or December 31, 2029 for 8.5 (source: php.net supported versions).

If you can’t finish by December 31

Prioritize. Upgrade first the sites that are internet-facing and handle logins or payments. For the rest, arrange a bridge: a host or vendor backport with a written end date. Keep your configuration hardened and a firewall in front. Firewalls can block many attempts and buy time, but they don’t replace the patch (source: Beazley Security Labs). Then finish the upgrades in January rather than letting the bridge become permanent.

Upgrading PHP doesn’t mean rewriting the site. Other technologies have had flaws just as severe (source: Google Cloud). The risk lies in runtimes that no longer get fixes, not in the language.

Sourced facts

Full wording, primary sources and dates: /sources.

Frequently asked questions

Will my website stop working on January 1, 2027?

No. A site on PHP 8.2 keeps running. What ends is official security fixes: flaws found after December 31, 2026 won’t be fixed by the PHP project for 8.2 (source: php.net supported versions).

Do WordPress automatic updates upgrade PHP?

No. WordPress can update itself automatically, but the PHP version underneath is set by your hosting environment, and WordPress auto-updates don’t change it (source: WordPress.org version statistics). You, your developer or your host has to switch it.

Does upgrading PHP also fix PHP2Shell?

Moving to a current release on 8.4 or 8.5 (8.4.27 or 8.5.12 and later) includes the PHP2Shell fixes (source: php.net release archive). As of October 23, 2026, you still need PHP’s recommended setting for CVE-2026-115560, and a restart (source: php.net advisory on CVE-2026-115560, October 23, 2026).

Is PHP 8.3 a reasonable target?

It’s supported until December 31, 2027, a year longer than 8.2 (source: php.net supported versions). Unless something blocks 8.4, you’d be doing the same project again in twelve months.

Know before you book the work

• Agencies: run the inventory across your client list with the agency triage guide.