PHP 8.2 end of life: how to plan your upgrade before 31 December 2026

Last updated: 10 November 2026. Support dates and quotations verified on 10 November 2026 with the PHP project, the National Cyber Security Centre (NCSC), Debian, Red Hat and the WordPress, Drupal, Laravel and Symfony projects. We will update this page when PHP 8.6 is released.

PHP 8.2 reaches end of life on 31 December 2026. In the PHP project's own words, it "will receive no further security fixes after that date. Please plan your upgrade to a supported version" [1]. That leaves less than two months, with the Christmas break inside them, to move every site and application that still runs it.

PHP 8.2 is far from a niche version. W3Techs, which surveys public websites, reports that 26.5% of the websites it sees using PHP 8 run version 8.2 [2]. In October the PHP project shipped an urgent security release for 8.2 alongside the newer versions, and our PHP2Shell guide covers what to check after those fixes. From January, a flaw of that kind would get no 8.2 fix from the PHP project at all.

This guide is about the planned move rather than the incident: what end of life means, where your PHP comes from, which version to move to, and how to get there before the deadline. It sits within our wider guide to securing software you built, inherited or self-host.

What PHP 8.2 end of life means, and what it does not

Every PHP version now gets four years of support. The PHP project's policy is that each branch "is fully supported for two years from its initial stable release", is then "supported for two additional years for critical security issues only", and after that "reaches its end of life and is no longer supported" [3]. PHP 8.2 left active support on 31 December 2024, so it has been on security fixes only for nearly two years, and on 31 December 2026 those stop too [1][3].

Nothing switches off on 1 January 2027. PHP 8.2 will keep running, and so will the sites built on it. What changes is that newly discovered vulnerabilities in 8.2 will not be fixed by the PHP project, whose page on unsupported versions says anyone still using them is "strongly urged to upgrade to a current version" [4]. The National Cyber Security Centre (NCSC) is blunter in its guidance on obsolete products: "Weaknesses found in unsupported products will remain unpatched and will be exploitable by relatively low skilled attackers" [5].

In our experience, end of life catches businesses out in three ways, and security is only one of them:

1. Unpatched flaws. A critical PHP vulnerability found after 31 December would be fixed in the supported versions, with nothing from the PHP project for 8.2.
2. The ecosystem moves on. No version of Drupal 11 runs on PHP 8.2 [6], and Laravel 13 "requires a minimum PHP version of 8.3" [7]. Staying on 8.2 increasingly means staying on older frameworks too, each with its own end date.
3. Hosts move first. Acquia ended support for PHP 8.2 on 1 October 2026 and said applications still on it after that date "will be upgraded to PHP 8.4 automatically" [8]. WP Cloud, Automattic's hosting platform, will remove PHP 8.2 on 15 December 2026 at 12:00 UTC and has asked hosts to move their customers' sites before then [9]. A forced upgrade is the worst way to find out that your code is not ready.

PHP support dates for every current version

The support dates for every current PHP version are set out below, taken from php.net's supported versions page [3]. The next release is PHP 8.6, not PHP 9.0. It is scheduled for 19 November 2026, and php.net has not yet published its support dates [10][11].

PHP version	Active support until	Security fixes until	Status on 1 January 2027
8.2	31 December 2024	31 December 2026	End of life
8.3	31 December 2025	31 December 2027	Security fixes only
8.4	31 December 2026	31 December 2028	Security fixes only
8.5	31 December 2027	31 December 2029	Active support
8.6	Not yet published	Not yet published	Scheduled for release on 19 November 2026

One detail is easy to miss: PHP 8.4 leaves active support on the same day that 8.2 reaches end of life [3]. From 2027, PHP 8.4 receives security fixes only, which matters if you also rely on routine bug fixes.

Where does your PHP 8.2 come from?

The 31 December 2026 date applies to PHP as released by the PHP project. Many servers do not run that build. They run PHP packaged by their operating system vendor, and those vendors set their own support windows and backport security fixes into the versions they ship.

Where your PHP 8.2 comes from	Security fixes until
The PHP project's own releases, built from php.net source	31 December 2026 [1]
Debian 12 "bookworm" (the php8.2 package)	Debian's Long Term Support (LTS) schedule for bookworm runs to 30 June 2028 [12]
Red Hat Enterprise Linux (RHEL) 8 or 9, PHP 8.2 Application Stream	Retirement scheduled for May 2029 [13]

Debian LTS comes with a caveat in Debian's own words: "The number of properly supported packages depends directly on the level of support that the LTS team receives" [12]. On Ubuntu, in our experience, PHP 8.2 usually comes from a third-party package repository rather than from Ubuntu itself, so its support depends on whoever maintains that repository. Check before you assume.

Operating system vendor support is a bridge, not a destination. It delivers the security fixes the vendor chooses to backport. It does not make Drupal 11 or Laravel 13 run on PHP 8.2, and it does nothing for a copy of PHP that someone compiled by hand. If you are not sure which of these you run, check the PHP version your web server actually uses, then ask your host or developer who builds it.

Should you upgrade to PHP 8.3, 8.4 or 8.5?

Choosing a target PHP version is a trade between runway and effort. Each step beyond 8.2 adds another version's worth of incompatible changes to clear, and another year before the next deadline [3].

Target	Security fixes until	Changes to clear from 8.2	Our view
PHP 8.3	31 December 2027	8.3	A quick, low-risk step when a plugin or dependency blocks 8.4, with the next move planned for 2027
PHP 8.4	31 December 2028	8.3 and 8.4	The sensible default for most sites: two years of runway and wide framework support
PHP 8.5	31 December 2029	8.3, 8.4 and 8.5	Well-maintained code with current dependencies
PHP 8.6	Not yet published	8.3 to 8.6	Not a deadline target; let your platform and plugins catch up first

The platform you run constrains the choice more than preference does, so check its own support table first:

• WordPress: the core team documents WordPress 6.9, 7.0 and 7.1 as compatible with PHP 8.2 through 8.5, and retired its old "beta support" label in May 2026 [14]. Core compatibility is not the whole story. WordPress.org says it does not know whether your themes and plugins will work on newer PHP versions, and that they should be tested to make sure [15].
• Drupal: Drupal 10.4, 10.5 and 10.6 run on PHP 8.2, 8.3 and 8.4 but not 8.5. Drupal 11 needs at least PHP 8.3, and PHP 8.5 needs Drupal 11.3 or later [6].
• Laravel: Laravel 12 supports PHP 8.2 to 8.5, so a Laravel 12 application can change PHP version without a framework upgrade. Laravel 12's own security fixes end on 24 February 2027, so plan that upgrade too; Laravel 13 needs PHP 8.3 or later [7].
• Symfony: Symfony 7.4, a long-term support release, requires PHP 8.2.0 or higher and receives security fixes until November 2029. Symfony 8.1 requires PHP 8.4.0 or higher [16].

Our general advice is PHP 8.4, with 8.3 as the fallback when something genuinely blocks it. Whatever the timing, we would not put PHP 8.6.0 into production in its first weeks.

What changes between PHP 8.2 and PHP 8.4

Most of what changes between PHP 8.2 and 8.4 shows up as deprecation notices and warnings rather than fatal errors. Every PHP version has its own migration chapter in the PHP manual, with lists of backward-incompatible changes and deprecated features [17][18][19]. These are the changes we see most often in older code:

• Implicitly nullable parameters (PHP 8.4). A typed parameter with a default of null, such as function foo(T1 $a = null), is deprecated. The manual's fix is to declare the type as nullable: function foo(?T1 $a = null) [19]. In our experience the old pattern is common in older code and plugins, so it can flood logs after an upgrade.
• trigger_error() with E_USER_ERROR (PHP 8.4). This is deprecated, and the manual says such usages "should be replaced by either throwing an exception, or calling exit()" [19].
• The E_STRICT constant (PHP 8.4). The error level has been removed and the constant is deprecated [19], which affects old error-handling code that still refers to it.
• Changed behaviour in PHP 8.3. range() now produces "a list of characters if one of the boundary inputs is a string digit", number_format() now acts on negative decimals instead of ignoring them [17], and using ++ on empty or non-alphanumeric strings is deprecated [18].

Moving on to PHP 8.5 adds more. The casts (boolean), (integer), (double) and (binary) are deprecated in favour of their short forms, the backtick operator is deprecated as an alias for shell_exec(), and using null as an array offset is deprecated [20].

A deprecation does not break your site today. It is the PHP project's notice that a feature is on its way out, and in our experience a log full of deprecation notices hides the one warning that matters. Clear them as part of the upgrade, not after it.

How to find PHP upgrade blockers before you switch

Free tools find most PHP upgrade blockers before anyone touches production. Four are worth running against your target version:

1. Composer's why-not command. Composer's documentation says it "tells you which packages are blocking a given package from being installed", and that you can "Specify a version constraint to verify whether upgrades can be performed in your project, and if not why not" [21]. Running composer why-not php 8.4 lists the dependencies that would stop a move to PHP 8.4.
2. Composer's platform setting. The config.platform.php option "Lets you fake platform packages (PHP and extensions) so that you can emulate a production env or define your target platform" [22]. Setting it to your target version makes dependency updates resolve against the PHP you are moving to, not the one you have.
3. PHPCompatibility. This is "a set of sniffs for PHP_CodeSniffer that checks for PHP cross-version compatibility" [23], which flags code affected by changes in the version you are moving to.
4. Rector. Rector rewrites code automatically using rule sets for each PHP version. For older projects its documentation advises using its PHP level setting and choosing to "raise it one step at a time" [24].

Static analysis cannot see everything that happens at runtime, so treat a clean run as a good sign rather than proof. The test that settles it is running your application on the target version: a staging copy, error logging turned up to full, and someone walking through the journeys that earn or cost you money. That means logins, checkout, forms, payment and email integrations, scheduled jobs, and anything that imports or exports data.

A five-step plan to upgrade before 31 December 2026

With less than two months to the PHP 8.2 deadline, the order of work matters more than the detail. This is the plan we follow:

1. Inventory everything that runs PHP. Include staging copies, old subdomains, scheduled jobs and command-line scripts. For each one, record the PHP version and who supplies it: the PHP project, your operating system vendor or your host.
2. Choose a target and check for blockers. Use your platform's support table, then run Composer and the compatibility tools against the target version. Do this in November, so plugin and dependency updates have time to land.
3. Fix and update on a staging copy. Update dependencies, deal with the incompatible changes and work through the deprecation notices. Keep every change in version control.
4. Test, then switch with a way back. Test the business-critical journeys on staging, then switch production in a quiet window in early December, with the previous PHP version still available so you can roll back quickly. If your host manages PHP, the switch may be a setting in the control panel, but the testing is still yours to do.
5. Watch, then diary the next date. Monitor error logs closely for a fortnight after the switch. Then record when your new version reaches end of life: 31 December 2027 for 8.3, 31 December 2028 for 8.4 and 31 December 2029 for 8.5 [3].

If you cannot upgrade PHP 8.2 by 31 December

Missing the PHP 8.2 deadline is a risk to manage, not a reason to stop. Two options buy time, and neither replaces the upgrade:

• Stay on a vendor-supported build. If your operating system vendor still supports its PHP 8.2 package, as Debian 12 and RHEL 8 and 9 do on their published schedules, staying on that package keeps security backports flowing [12][13].
• Buy extended support. Several companies sell security patches for end-of-life PHP versions. HeroDevs, for example, says its paid support covers PHP 8.2 past its 31 December 2026 end of life [25]. These vendors have something to sell, so get in writing which versions, which kinds of fix and which platforms are covered.

The NCSC's guidance on obsolete products allows for short-term mitigations while a replacement is planned, but it is clear about where that ends: "The only fully effective way to mitigate this risk is to stop using the obsolete product" [5]. Whichever option you choose, set a date for the real upgrade and give it a named owner.

Cyber Essentials and unsupported software

Cyber Essentials, the certification scheme backed by the National Cyber Security Centre (NCSC), has a clear rule on unsupported software. Version 3.3 of its requirements, published in April 2026, says all software on in-scope devices must "be licensed and supported", must "be removed from devices when it becomes unsupported", and must receive fixes for critical or high-risk vulnerabilities "within 14 days of release" [26].

The same requirements say that "Publicly available commercial web applications (rather than apps developed in-house) are in scope by default", while "Bespoke and custom components of web applications are out of scope" [26]. Whether a vendor-supported PHP 8.2 package counts as "supported" is a question for your certification body. Ask before your next renewal rather than at it. Our reading is that a PHP runtime receiving security fixes from nobody is hard to describe as supported.

The NCSC has also been explicit about the direction of travel. In a May 2026 blog post on preparing for a "vulnerability patch wave", its chief technology officer wrote that organisations relying on out-of-support technology "will need to replace technologies, or bring them back within support" [27].

Plan your PHP 8.2 upgrade with an engineer

Steps 1 and 2 of the plan above are the ones most teams struggle to find time for, and they are where our PHP upgrade service begins. The first assessment is free: an engineer maps where each of your sites gets its PHP, which version each one really runs and which plugins or dependencies block your target version. You then get a written quote for the upgrade itself. If you would like someone to own your PHP versions and keep them in support from then on, see Ongoing Support.

Request a free PHP upgrade assessment

Frequently asked questions

What happens when PHP 8.2 reaches end of life?

After 31 December 2026 the PHP project releases no further security fixes for PHP 8.2. Sites keep running, but vulnerabilities discovered from then on are fixed only in PHP 8.3 and later, unless your operating system vendor or a paid support provider backports them. Some hosting providers also remove PHP 8.2 or move sites to a newer version.

Will my website stop working after 31 December 2026?

No. Nothing switches off when PHP 8.2 reaches end of life, and a site running on it will carry on working. The risks are security flaws that stay unpatched, frameworks and plugins dropping support for 8.2, and hosts upgrading PHP for you, which can break code that has not been tested on the newer version.

Should I upgrade from PHP 8.2 to 8.3, 8.4 or 8.5?

For most sites we recommend PHP 8.4, which receives security fixes until 31 December 2028. PHP 8.3 is the smallest step but is supported only until the end of 2027, while PHP 8.5 runs to the end of 2029 but has more changes to clear. Check which versions your CMS or framework supports before you choose.

Should I wait for PHP 8.6?

No. PHP 8.6 is scheduled for release on 19 November 2026, six weeks before PHP 8.2 reaches end of life. In our view that is too soon for most plugins, frameworks and hosts to have caught up. Move to a version your platform supports today, such as PHP 8.4, and consider PHP 8.6 at a later, planned upgrade.

Does my hosting provider upgrade PHP for me?

It depends on the host. Some upgrade sites automatically: Acquia moved PHP 8.2 applications to PHP 8.4 after 1 October 2026. Others ask customers to choose, or publish no date at all. Check your control panel and ask your host in writing. A host changing your PHP version does not test your code against the new one.

Is operating system or extended support enough?

Operating system or paid extended support can bridge a gap, but it is not a long-term answer. Debian 12 and Red Hat Enterprise Linux 8 and 9 publish support for their PHP 8.2 packages beyond 2026, and paid providers sell patches for end-of-life versions. Neither makes newer frameworks run on PHP 8.2, so plan the upgrade anyway.

How long does a PHP upgrade take?

A PHP upgrade takes as long as the code, plugins and dependencies demand, and whether a staging copy and automated tests exist matters as much as size. A small, well-maintained site can move quickly; an older application with custom code needs more time. Running Composer and compatibility checks against your target version first shows the scale of the work.

Sources

1. PHP Group, "PHP 8.2.35 Released!", 21 October 2026. https://www.php.net/archive/2026.php#2026-10-21-1
2. W3Techs, "Usage statistics of PHP version 8 for websites", data as at 10 November 2026. https://w3techs.com/technologies/details/pl-php/8
3. PHP Group, "Supported Versions" (accessed 10 November 2026). https://www.php.net/supported-versions.php
4. PHP Group, "Unsupported Branches" (accessed 10 November 2026). https://www.php.net/eol.php
5. National Cyber Security Centre, "Obsolete products", Device security guidance (accessed 10 November 2026). https://www.ncsc.gov.uk/collection/device-security-guidance/managing-deployed-devices/obsolete-products
6. Drupal.org, "PHP requirements" (accessed 10 November 2026). https://www.drupal.org/docs/getting-started/system-requirements/php-requirements
7. Laravel, "Release Notes: Laravel 13.x", Support Policy (accessed 10 November 2026). https://laravel.com/framework/docs/13.x/releases
8. Acquia, "End of life for PHP 8.2 in favor of PHP 8.4 FAQs" (accessed 10 November 2026). https://docs.acquia.com/service-offerings/php-82-end-life-favor-php-84-faqs
9. WP Cloud, "Preparing for the removal of PHP 8.2", 14 May 2026. https://wp.cloud/preparing-for-the-removal-of-php-8-2/
10. PHP Group, "PHP 8.6.0 RC5 available for testing", 5 November 2026. https://www.php.net/archive/2026.php#2026-11-05-1
11. PHP project, "PHP 8.6 release timetable" (accessed 10 November 2026). https://wiki.php.net/todo/php86
12. Debian Wiki, "LTS" (accessed 10 November 2026). https://wiki.debian.org/LTS
13. Red Hat, "Red Hat Enterprise Linux Application Streams Life Cycle" (accessed 10 November 2026). https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
14. WordPress Core Team, "PHP Compatibility and WordPress Versions", Core Handbook, last updated 4 November 2026. https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/
15. WordPress.org, "Update PHP" (accessed 10 November 2026). https://wordpress.org/support/update-php/
16. Symfony, "Symfony Releases" (accessed 10 November 2026). https://symfony.com/releases
17. PHP Manual, "Migrating from PHP 8.2.x to PHP 8.3.x: Backward Incompatible Changes" (accessed 10 November 2026). https://www.php.net/manual/en/migration83.incompatible.php
18. PHP Manual, "Migrating from PHP 8.2.x to PHP 8.3.x: Deprecated Features" (accessed 10 November 2026). https://www.php.net/manual/en/migration83.deprecated.php
19. PHP Manual, "Migrating from PHP 8.3.x to PHP 8.4.x: Deprecated Features" (accessed 10 November 2026). https://www.php.net/manual/en/migration84.deprecated.php
20. PHP Manual, "Migrating from PHP 8.4.x to PHP 8.5.x: Deprecated Features" (accessed 10 November 2026). https://www.php.net/manual/en/migration85.deprecated.php
21. Composer, "Command-line interface / Commands": prohibits (why-not) (accessed 10 November 2026). https://getcomposer.org/doc/03-cli.md#prohibits-why-not
22. Composer, "Config": platform (accessed 10 November 2026). https://getcomposer.org/doc/06-config.md#platform
23. PHPCompatibility, project README on GitHub (accessed 10 November 2026). https://github.com/PHPCompatibility/PHPCompatibility
24. Rector, "Set Lists" (accessed 10 November 2026). https://getrector.com/documentation/set-lists
25. HeroDevs (a commercial support vendor), "PHP end of life dates and support timeline for every version", 26 October 2026. https://www.herodevs.com/blog-posts/php-end-of-life-dates-support-timeline-for-every-version-2026
26. National Cyber Security Centre and IASME, "Cyber Essentials: Requirements for IT Infrastructure v3.3", April 2026. https://www.ncsc.gov.uk/files/cyber-essentials-requirements-for-it-infrastructure-v3-3.pdf
27. National Cyber Security Centre, Ollie Whitehouse, "Preparing for a 'vulnerability patch wave'", 1 May 2026. https://www.ncsc.gov.uk/blogs/prepare-for-vulnerability-patch-wave