PHP 8.2 security support ends on 31 December 2026: what to do

PHP 8.2 stops receiving security fixes on 31 December 2026. That is the date published by the PHP team on its supported versions page. After that date, an application still running on PHP 8.2 keeps working, but any new flaw in the PHP engine will stay open for this branch. This post brings together the official schedule, the versions to target, the changes to expect and a migration plan, with the source of each date.

What changes on 31 December 2026

Each PHP branch goes through three states, defined on php.net. In active support, bugs and flaws are fixed and point releases come out regularly. In security fixes only, only critical flaws are fixed, and releases come out only as needed. At end of life, nothing more is published: php.net then recommends upgrading as soon as possible, as users “may be exposed to unpatched security vulnerabilities”.

PHP 8.2 was released on 8 December 2022. Its active support ended on 31 December 2024; since then it only receives security fixes, until 31 December 2026. On 1 January 2027, it joins the list of unsupported branches, where PHP 8.1 has been since 31 December 2025.

This rhythm follows a rule adopted by the PHP project (RFC “Release cycle update”): each branch receives two years of bug fixes then two years of security fixes, and end-of-support dates are aligned on 31 December.

The PHP2Shell flaws, made public on 21 October 2026, show what this date means: the PHP team released fixed versions for branches 8.2 to 8.5 only; PHP 8.1 and older versions received none. PHP 8.2 was patched this time; a flaw published after 31 December 2026 will not be. The post PHP2Shell: check your PHP version, mitigate, then patch details the steps to follow.

The official PHP version schedule

Dates read on php.net on 17 October 2026 and cross-checked with endoflife.date:

Two useful readings. First, PHP 8.3 is itself already in security fixes only: a migration to 8.3 only pushes the deadline back by one year. Second, PHP 8.4 leaves active support on the same day PHP 8.2 leaves security support: it will stay maintained for security for two more years.

Which version to target: 8.3, 8.4 or 8.5?

The right target is the most recent version your stack fully accepts: framework, libraries, extensions and hosting.

• PHP 8.4 offers security fixes until 31 December 2028. It is the reasonable target when some dependencies do not declare PHP 8.5 yet.
• PHP 8.5 adds one year of support (security until 31 December 2029). It assumes every dependency declares compatibility; check it, do not assume it.
• PHP 8.3 only makes sense as an intermediate step, for example if a dependency still blocks 8.4. Its security support ends on 31 December 2027.

Composer answers the question for your project: the command composer prohibits php 8.4 (alias why-not) lists the packages that prevent moving to this version, with the blocking constraint. Run it again for 8.5 before choosing.

What breaks between PHP 8.2 and the next versions

An upgrade rarely skips a single step: moving from 8.2 to 8.4 means dealing with the changes of 8.3 and 8.4. The PHP manual publishes, for each version, the list of incompatible changes and deprecated features. A few examples from these guides:

PHP 8.3

• Incrementing an empty or non-alphanumeric string with ++ is deprecated; the str_increment() function is the intended route.
• Calling get_class() or get_parent_class() without an argument is deprecated.

PHP 8.4

• Implicitly nullable parameters are deprecated: function foo(T $a = null) must become function foo(?T $a = null).
• The E_STRICT error level is removed and its constant deprecated.
• exit() and die() now behave more like functions (type coercion, respect for strict_types).

PHP 8.5

• The “backtick” operator, an alias of shell_exec(), is deprecated.
• The non-canonical cast names (boolean), (integer), (double) and (binary) are deprecated in favor of (bool), (int), (float) and (string).
• Ending a case with a semicolon instead of a colon is deprecated.

A deprecation breaks nothing right away: it raises an E_DEPRECATED warning and announces a future removal. Turning these warnings on in pre-production gives the exact list of lines to fix.

Symfony and Drupal: the framework constraints

The framework often sets the target more firmly than the PHP schedule.

• Symfony: version 7.4, a long-term support version, requires PHP 8.2.0 or higher; it can therefore still be installed today, but your PHP will no longer be maintained after 31 December 2026. Symfony 8.0 requires PHP 8.4.0 or higher: upgrading PHP first opens the way to Symfony 8.
• Drupal: according to Drupal’s PHP requirements page, versions 11.1 to 11.4 do not support PHP 8.2; they accept PHP 8.3 and 8.4, and PHP 8.5 from Drupal 11.3. A site still on Drupal 10 with PHP 8.2 therefore has two linked projects: the PHP version and the Drupal version.

A six-step migration plan

1. Take inventory. Record the PHP version actually used everywhere: servers, containers, continuous integration, scheduled tasks. List the extensions and Composer dependencies.
2. Measure what blocks. Run composer prohibits php 8.4 (then 8.5) and note each package to update or replace.
3. Secure with tests. Before touching the version, make sure the critical paths are covered by automated tests, at least on the features that bring in revenue or expose data.
4. Fix the code. Read the 8.3, 8.4 and 8.5 migration guides, turn on E_DEPRECATED warnings, and use analysis tools: Rector, for example, applies upgrade rules up to the PHP version declared in composer.json.
5. Try it in pre-production. Same PHP version, same extensions, same test data as in production; check the error logs and scheduled tasks, not just the pages.
6. Go to production with a planned rollback. Keep the old image or server ready while you validate, and watch the logs in the following days.

What if the migration is not ready in time?

31 December 2026 does not switch the servers off. But each month spent on an unmaintained branch adds a risk you do not control: a flaw published in the PHP engine will no longer get an official fix for 8.2. If the deadline cannot be met, document the situation, reduce exposure (restricted access, closer log monitoring) and schedule the migration with a date. Also check the policy of your host or distribution, which may maintain its own packages for longer.

For agencies that need to inform several clients, the Agencies page presents our white-label work. For a direct project, the migration offer describes the fixed-price process, and the 48-hour Diagnostic prices the work before you commit.