Blog · 3 min read
PHP 8.2 end of life in 67 days: a week-by-week plan
On this page
The short answer
PHP 8.2 stops receiving security fixes on December 31, 2026 (source: php.net supported versions). That’s 67 days from today, and Thanksgiving week and the year-end holidays both fall inside it. If your sites run PHP 8.2 or older, use the plan below:
- this week and next: inventory and compatibility scans;
- mid-November: staging copies and testing;
- late November to mid-December: switching production, stores after Cyber Monday;
- the last weeks: verifying.
Move to PHP 8.4, which gets security fixes until December 31, 2028, or 8.5, until December 31, 2029 (source: php.net supported versions). Going to 8.3 buys only one more year, to December 31, 2027 (source: php.net supported versions).
Why a plan, not a weekend
Upgrading PHP is mostly waiting for answers: does each plugin support the new version, does the host offer it, does checkout still work? Those answers take days, not minutes. And the deadline lands on a holiday week. Starting now leaves room for the things that break.
It’s a common position. By our calculation from W3Techs data, 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). Only sites that reveal their version are counted, so the figure may overstate the problem (source: W3Techs).
The plan
| Week | Dates (2026) | Do this | Done when |
|---|---|---|---|
| 1 | Oct 26–Nov 1 | Inventory. Every site, the PHP version that serves it (not the command line) (source: AlmaLinux), who controls the runtime, every plugin, theme and extension, custom code and scheduled jobs | One row per site in a sheet |
| 2 | Nov 2–8 | Compatibility. Check each plugin’s declared PHP support; run a static compatibility scan of custom code; confirm the host offers 8.4 or 8.5; pick replacements for abandoned plugins | Each site marked switch-ready, needs code changes, host can’t run 8.4, or bridge |
| 3 | Nov 9–15 | Staging. Build staging copies on 8.4 or 8.5. Stores: also finish the PHP2Shell checks before the freeze (the store checklist) | Staging copies exist |
| 4 | Nov 16–22 | Test on staging. Run the test plan: checkout, forms, logins, uploads, admin, scheduled jobs and emails. Fix or replace what breaks | Staging error logs are quiet |
| 5 | Nov 23–29 | Holiday week: online stores freeze (Black Friday Nov 27, Cyber Monday Nov 30). Non-store sites: switch the lowest-risk sites early in the week, or keep testing. Stores: change nothing in production | First simple sites on 8.4 or 8.5 |
| 6 | Nov 30–Dec 6 | Switch production, lowest risk first. Backup stored off the server, a rollback plan, a quiet hour. Restart PHP, then confirm the version that serves the site changed (source: AlmaLinux) | Simple sites switched |
| 7 | Dec 7–13 | Switch stores and the rest, now the freeze is over | Stores switched |
| 8 | Dec 14–20 | Catch up. Arrange a written bridge (host or vendor backport, with an end date) for anything that can’t make it | Every site switched or bridged |
| 9 | Dec 21–31 | Verify and record, then stop changes for the holidays. Per site: the new version, the date, and PHP’s recommended setting for CVE-2026-115560 re-applied on the new version (no PHP release fixes it as of October 23, 2026) (source: php.net advisory on CVE-2026-115560, October 23, 2026) | A dated record for every site |
Three things that derail the plan
- The host can’t run 8.4 on your plan. Find out in week 2, not week 6. If it can’t, moving host becomes part of the project.
- One abandoned plugin. A plugin that hasn’t been updated in years is the most common blocker. Choose a replacement in week 2, while there’s time to test it.
- Forgetting the restart. A switched version isn’t running until PHP restarts. Confirm the version from the web PHP, not the command line (source: AlmaLinux).
If you can’t finish by December 31
Your sites keep working on January 1. What stops is official security fixes for flaws found after December 31 (source: php.net supported versions). PHP2Shell showed what that means: when it was fixed, there was no official PHP release for 8.1 or older, and those sites depended on their host, their distribution or a paid extended-support provider (source: Beazley Security Labs). Prioritize sites that are internet-facing and handle logins or payments. Bridge the rest in writing, and finish in January.
Upgrading PHP isn’t a reason to rewrite. Other technologies have had flaws just as severe (source: Google Cloud). Close the gap on the runtime you have.
Where to go next
- The full project steps: the PHP 8.2 end-of-life checklist.
- WordPress sites still on 7.4: the 7.4 to 8.4 guide.
- Agencies: batch your clients with the triage guide.
- Recording what you did: the evidence checks.
Sourced facts
Full wording, primary sources and dates: /sources.
| ID | Fact | Primary source | Date |
|---|---|---|---|
| S-32 | PHP 8.2 security fixes end Dec 31, 2026 | php.net supported versions | Checked Oct 23, 2026 |
| S-32b | 8.4 to Dec 31, 2028; 8.5 to Dec 31, 2029; 8.3 to Dec 31, 2027 | php.net supported versions | Checked Oct 23, 2026 |
| S-34 | About 48% → about 66% of version-revealing PHP sites on EOL PHP (our calculation) | W3Techs | Oct 23, 2026 · LIVE |
| S-09 | CLI may differ from the web PHP; restart needed | Red Hat | Oct 21, 2026 |
| S-02b | CVE-2026-115560 interim setting | php.net | Oct 23, 2026 · LIVE |
| S-03 | No official PHP2Shell release for 8.1 and older | Beazley | Oct 21–23, 2026 |
| S-47 | Other stacks aren’t immune | Google GTIG | Dec 2025 |