PHP 8.2 reaches end of life on 31 December 2026: what it means and what to do

PHP 8.2 receives security fixes from the PHP project until 31 December 2026. After that date the branch reaches its end of life: no more releases, not even for critical vulnerabilities. This article explains what that means for a running application and how to plan the move to a supported version.

What "end of life" means

Each PHP release branch gets two years of active support, then two more years of fixes for critical security issues only. After those four years it reaches its end of life and is no longer supported (php.net: Supported versions). For a version in that state, php.net advises users to upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities.

Nothing stops working on 1 January 2027. The application keeps running; what ends is the supply of fixes. A vulnerability found after that date is not fixed in an official PHP 8.2 release.

Supported versions after 31 December 2026

Source: php.net: Supported versions. PHP 8.4 or 8.5 leaves the most time before the next upgrade; 8.3 is a smaller step, but it reaches its end of life a year later.

Step 1: find out which version you actually run

The version that matters is the one serving the application, which is not always the one on developers' machines. Check every environment: production, staging, old microsites and internal tools.

• On shared hosting, the version is usually shown, and can often be changed, in the hosting control panel.
• On a server, php -v shows the command-line version; the web server may use a different one through PHP-FPM. The server's installed packages show what the site uses.
• In a container, the tag of the base image, for example php:8.2-fpm, names the version.

Step 2: check your Linux distribution

If PHP comes from your distribution's packages, the distribution's security support matters as well as the PHP project's dates. Debian 12 (bookworm) ships PHP 8.2; Debian's Long Term Support team covers bookworm until 30 June 2028, with a few packages excluded, which the debian-security-support package lists (Debian announcement). Debian 13 (trixie) ships PHP 8.4 (packages.debian.org). Ubuntu 24.04 LTS ships PHP 8.3 and Ubuntu 26.04 LTS ships PHP 8.5 (packages.ubuntu.com).

Distribution support buys time, but it does not change which PHP versions your framework or CMS supports.

Step 3: check what your framework or CMS supports

• WordPress recommends PHP 8.3 or greater (WordPress requirements). Plugins and themes need checking one by one.
• Laravel 12 supports PHP 8.2 to 8.5 and receives security fixes until 24 February 2027; Laravel 13 requires PHP 8.3 or newer (Laravel release notes).
• Symfony 8 requires PHP 8.4 or newer (Symfony 8.0).
• Drupal 11 requires PHP 8.3 or newer, so it does not run on 8.2 (Drupal PHP requirements).

In a Composer project, composer why-not php 8.4 lists the packages that block the newer version.

Step 4: test the new version before you switch

The safest way to try a new PHP version is a separate, reproducible environment that matches production: the same extensions and settings, with only the PHP version changed. A container image makes this repeatable for the whole team, and later for production. For every version, PHP publishes a migration guide listing the incompatible changes: PHP 8.3, PHP 8.4, PHP 8.5.

Run the test suite if there is one, and go through the main user journeys. Deprecation notices in the logs show what is likely to break in a later version.

If the upgrade cannot be finished in time

Keep PHP 8.2 on its latest release until the end of December, and reduce what is exposed: unused admin areas, old endpoints, forgotten test installations. A firewall rule can filter some attacks, but it does not fix a vulnerability in PHP itself, so the upgrade plan should keep moving.

Where I can help

I help small and mid-sized companies move PHP applications to a supported version without rewriting them: an assessment of what runs where, a containerised and reproducible environment for the upgrade, and optional hosting and operations. Changes to the application code stay with your developers or agency.