All articles Practice 8 min read

PHP 8.2 end of life: what to plan before 31 December 2026

PHP 8.2's upstream security support ends on 31 December 2026. The dated facts from php.net, how to choose a supported target, a planning sequence for the upgrade and a copyable acceptance matrix.

Paul Utr 27 October 2026

Book consultation

Apply the current security fixes now, and plan a supported runtime separately, before the support deadline. For many sites an in-place PHP upgrade is enough. A CMS migration needs its own business case.

PHP 8.2 receives security fixes from the PHP project until 31 December 2026, and none after that date. This article reflects primary sources checked on 27 October 2026. For the October 2026 vulnerabilities and the fixed releases on each branch, see our PHP2Shell article.

PHP 8.2 support dates

Fact	Detail	Source
First release	8 December 2022	PHP supported versions
Active support	Ended 31 December 2024	PHP supported versions
Security support	Ends 31 December 2026	PHP supported versions
What security support covers	Critical security issues only, with releases made as needed	PHP supported versions
Latest 8.2 source release when checked	8.2.35, released 21 October 2026, fixing CVE-2026-109618 and CVE-2026-109619	PHP 8.2.35 release
Windows package rebuild	8.2.35-1, released 26 October with Brotli 1.2.1 to address CVE-2026-111497; the PHP runtime is unchanged from 8.2.35	Windows rebuild
After the end date	No further security fixes from the PHP project	PHP 8.2.35 release announcement

Active support and security support are different stages. Ordinary bug fixes for 8.2 stopped at the end of 2024; since then the branch has received security releases only. PHP’s end-of-life page urges anyone on an unsupported branch to upgrade, because older versions may expose a site to vulnerabilities and bugs fixed in later ones.

Linux distributions, hosting providers and commercial vendors may keep patching their own PHP 8.2 packages after 31 December. That is the provider’s support, on the provider’s terms, and it leaves PHP’s own lifecycle unchanged. Ask for the scope and end date in writing, and identify each fix by package build and advisory. A version string on its own cannot show whether a vendor build carries backported fixes.

Choose a supported target

Target	Active support until	Security support until	Security support beyond 8.2’s end date
PHP 8.3	31 December 2025 (ended)	31 December 2027	One year
PHP 8.4	31 December 2026	31 December 2028	Two years
PHP 8.5	31 December 2027	31 December 2029	Three years

PHP 8.3 is already in security-only support, so an upgrade to it schedules the next upgrade for 2027. PHP 8.4 and 8.5 give more time. What usually decides the target is what the CMS, framework, extensions and hosting plan support today. PHP 8.6 was at its fourth release candidate on 21 October 2026, so check the support table again when you decide.

WordPress and Drupal publish their own PHP compatibility. WordPress’s PHP compatibility table, updated 19 August 2026, lists PHP 8.4 as supported from WordPress 6.7 and PHP 8.5 from WordPress 6.9. The table covers WordPress itself, so check each theme and plugin separately. Drupal’s PHP requirements, updated 4 August 2026, list PHP 8.3 and 8.4 for Drupal 10.4 to 10.6 and PHP 8.5 from Drupal 11.3; Drupal 12.0 lists PHP 8.5 only. Drupal 10 itself reaches end of life on 9 December 2026, so a Drupal 10 site has a CMS decision to make as well; our Drupal 10 guide covers it.

Plan the upgrade in seven steps

These are planning steps for your team and suppliers to agree. They describe no test we have run.

Inventory every PHP runtime. Web requests (PHP-FPM, Apache mod_php or another server API), the command-line PHP used by cron and deployment scripts, queue workers, and the extensions each one loads. Web and command-line PHP can differ in version and configuration on the same server, so record each separately. Include staging sites and older services that are still reachable.
Collect compatibility evidence. Record the CMS version, each plugin, module and theme, the Composer packages and your custom code, with the vendor statement or test result that covers the target. Run Composer’s check-platform-reqs command under the target PHP; it checks whether the installed packages’ PHP and extension requirements are met.
Choose the target against the actual constraints. Weigh the support dates above against what the CMS, the extensions and the hosting plan support, and against when your team can take the next upgrade.
Identify the changes. PHP publishes a migration guide for each version step: 8.2 to 8.3, 8.3 to 8.4 and 8.4 to 8.5. Read the backward-incompatible changes and deprecations in every guide between your current branch and the target. Static analysis helps with custom code: PHPStan can analyse code as if written for a different PHP version through its phpVersion setting.
Stage the target build and test what the site must keep doing. Run the same build on staging with production-like configuration. Choose those tests before the work starts: publishing, forms, search, sign-in, payments or CRM handoffs, imports and scheduled jobs. Watch the logs for new errors and deprecation notices.
Agree deployment, restoration and monitoring. State how every serving instance moves to the new build, how workers are restarted, what triggers a restore, and how far a restore can go once CMS, plugin or database changes released alongside the upgrade are live. Keep the restore target on the latest patched 8.2 build. After 31 December that build receives no further fixes, so plan a restore as a short holding position. Monitor errors and the agreed tests after release.
Confirm who owns updates on the new branch. Name who watches PHP advisories, applies patch releases and plans the next upgrade before the new branch’s own end date. Our PHP website maintenance guide covers what to put in that agreement.

Upgrade acceptance matrix

Copy the table into a spreadsheet, keep one row per component and environment, and add rows for anything specific to your site. The prompts show what to fill in; leave a cell marked unknown until someone has evidence for it.

Component and version (current → target)	Compatibility evidence	Test journey	Expected result
PHP for web requests	Host or package notice for the target build	Load the main templates, an error page and the admin	Pages render; no new errors or deprecation notices in the logs
Command-line PHP, cron and queue workers	The binary and configuration each job uses	Run each scheduled job and worker once	Jobs complete on the target build
PHP extensions	Each extension’s available version for the target	Use the features that depend on it, such as image processing or caching	Output matches the current site
CMS core	The CMS’s published PHP compatibility for your version	An editor creates, previews and publishes a page	The page appears on the public site
Plugins, modules and themes	Vendor support statement, or a staging run with notices enabled	Use each one’s public and admin functions	Behaviour unchanged, no new errors
Composer packages and custom code	Static analysis against the target; updated lock file	Run the automated tests, then the custom features	Tests pass; features unchanged
Forms and integrations	Owner of each receiving system confirms the change	Submit each form and complete each integration transaction	Each submission arrives once, at the right destination

A completed matrix records functional acceptance: the upgraded site does the jobs the business agreed. Security status needs its own evidence, and the matrix certifies nothing as secure. If the site ran an affected version while exploitation was reported, assessing possible compromise is separate work for a qualified responder. The remediation and handover checklist keeps that assessment in its own section, apart from patch and functional status, and ends with the next upgrade decision.

Upgrade in place, or compare a migration

An in-place upgrade is the proportionate answer when the CMS has a supported release for the target, the extensions have maintained versions, and the publishing and integration setup works for the business. PHP remains a supported, maintained language on the newer branches.

The deadline can also expose a constraint the upgrade would carry forward, such as a plugin or module with no release for any supported PHP version. Compare a migration with the upgrade on the same requirements at that point; the maintenance guide sets out that business case and where Payload fits. A Payload site runs on Node.js and has its own runtime, dependency and hosting updates to maintain.

Start with what the site runs today

WAYF can assess the compatibility work, scope the upgrade with your hosting provider and agree acceptance criteria before delivery. Leave passwords and production secrets out of the first message; access is arranged once the scope is agreed.

A site still on PHP 8.2 after 31 December runs on a branch the PHP project no longer fixes.

Sources

PHP supported versions: the 8.2 release date, the end of active support on 31 December 2024, security support to 31 December 2026, the definition of security-only support, and the dates for 8.3, 8.4 and 8.5
PHP news archive, 2026: the 8.2.35 security release of 21 October 2026 and its end-of-life notice, PHP 8.6.0 RC4 of the same date, and the 8.2.35-1 Windows rebuild of 26 October
PHP end-of-life branches: PHP’s advice to users of unsupported branches
PHP migration guides for 8.3, 8.4 and 8.5: backward-incompatible changes and deprecations per version step
WordPress PHP compatibility, updated 19 August 2026, and Drupal PHP requirements, updated 4 August 2026: core compatibility by version, including Drupal 12.0’s PHP 8.5 requirement
Composer command-line reference and PHPStan configuration reference: platform checks and target-version analysis

All sources were checked on 27 October 2026. The planning sequence and the matrix are WAYF’s practical guidance; we have not tested a CMS, plugin or hosting platform for this article, and the matrix prompts need adapting to each site.

Author

Paul Utr

Co-founder, Chief Growth Officer

Paul has been launching online platforms since his teens, picking up UX and product design by building them. He led the Mailgun redesign at Netguru and was Principal Designer at Ramp Network through its seed-to-Series-B run. At WAYF he leads design and organisational alignment, and watches how language carries through every product we ship.

About Paul LinkedIn

Rather have it done for you? Bring the PHP inventory you have for your CMS or custom application. We can assess compatibility, scope the upgrade and agree acceptance criteria with your hosting provider.