Debian

PHP 8.2 reaches end of life on 31 December 2026: what Debian 12 users and everyone else should plan

PHP 8.2 security support ends on 31 Dec 2026. How that affects Debian 12, which ships 8.2 under LTS until 2028, other setups, and how to plan the move.

Published
Reading time
6 min read

PHP 8.2 receives its last upstream security support on 31 December 2026, two months from now. After that date the PHP project will not publish further 8.2 releases. Its active support already ended on 31 December 2024; since then it has received security fixes only, most recently in 8.2.35 in October 2026.

For many servers the question is less simple than "upgrade by December", because Debian 12 (bookworm) ships PHP 8.2 and is supported by Debian LTS until 30 June 2028. This article explains what upstream end of life means, what Debian's support covers, and how to plan.

The dates

BranchInitial releaseActive support untilSecurity fixes until
8.28 Dec 202231 Dec 202431 Dec 2026
8.323 Nov 202331 Dec 202531 Dec 2027
8.421 Nov 202431 Dec 202631 Dec 2028
8.520 Nov 202531 Dec 202731 Dec 2029

Source: the supported versions page on php.net. Moving from 8.2 to 8.3 only buys one more year, so most teams should aim for 8.4 or 8.5.

Debian 12: PHP 8.2 under Debian LTS

Debian 12 ships PHP 8.2 as its default (the php metapackage is 2:8.2+93). Regular security support for bookworm has ended and the release is now maintained by the Debian LTS team until 30 June 2028. According to the LTS wiki, all bookworm packages are covered except games and those listed as unsupported in the debian-security-support package; php8.2 is not on that list.

So far, bookworm's PHP has tracked upstream point releases. The latest update, DLA-4848-1 on 21 October 2026, brought php8.2 to 8.2.35-1~deb12u1 with the critical October 2026 fixes (see our article on those two vulnerabilities).

What changes after 31 December 2026 is where fixes come from. There will be no new upstream 8.2 releases to package, so any future fix for bookworm's PHP has to be backported by the LTS team itself. Debian LTS is run by volunteers and sponsoring companies, and its wiki says plainly that the number of properly supported packages depends on the support the team receives. That is a real safety net, but it is a different promise from an actively maintained upstream branch, and your libraries and frameworks will move on regardless.

Check what you have:

apt policy php8.2-fpm php8.2-cli
apt changelog php8.2-cli | head -30

A ~deb12u version coming from security.debian.org or the Debian mirrors means you are on Debian's packages and will receive LTS updates as long as you apply them.

Other setups

  • Ubuntu: no supported Ubuntu release ships PHP 8.2 by default (22.04 ships 8.1, 24.04 ships 8.3, 26.04 ships 8.5). If you run 8.2 on Ubuntu, it came from a third-party repository, and support after December depends on that repository.
  • Third-party repositories and self-compiled builds: after 31 December 2026 there will be no upstream releases to build from. Plan to be on 8.4 or 8.5 by then.
  • Debian 13 (trixie) ships PHP 8.4, which has upstream security support until 31 December 2028, inside a Debian release supported until 2028 and by LTS until 2030.

Your options on Debian 12

  1. Move to Debian 13. The cleanest long-term path: PHP 8.4 from the distribution, regular Debian security support. Either upgrade in place following the official trixie release notes, or build a new Debian 13 server and migrate the sites, which also gives you an easy rollback.
  2. Stay on Debian 12 for a defined period. Reasonable if the application cannot move yet. Keep applying LTS updates, and put a date on the move rather than treating 2028 as the plan.
  3. Run PHP 8.4 on Debian 12 from a third-party repository. Possible, but you take on a second package source with its own trust and update model, and the rest of the system still ages. Pin the repository so it replaces only what you intend.

Preparing the application

The code changes between 8.2 and 8.4 are documented in two official migration guides (8.2 to 8.3 and 8.3 to 8.4). The items that most often need work are the deprecation of implicitly nullable parameter types and of the E_STRICT constant in 8.4, the move of the IMAP, OCI8, PDO_OCI and PSpell extensions out of core into PECL in 8.4, and stricter argument validation that now throws ValueError in several extensions.

# which dependencies block PHP 8.4?
composer prohibits php 8.4
# lint with the target version (PHP 8.3+ accepts several files)
find . -path ./vendor -prune -o -name '*.php' -print0 | xargs -0 -n 200 php8.4 -l | grep -v '^No syntax errors'

Then run the test suite on 8.4 in a staging copy with error_reporting = E_ALL and logging on, and fix what appears. Upgrade the framework or CMS to a version that supports your target PHP first.

A realistic timeline

  • November: inventory servers and sites on 8.2, check framework support, set up a staging copy on the target version.
  • December: fix deprecations and failures, switch low-risk sites first, keep the old PHP-FPM pool available for rollback.
  • Early 2027: finish remaining sites, remove 8.2 packages, and for Debian 12 hosts, schedule the move to Debian 13.

What you should do

  • Find every server and site that runs PHP 8.2 and note where its packages come from.
  • On Debian 12, keep applying security updates; Debian LTS covers php8.2, but treat it as a bridge, not a destination.
  • Choose PHP 8.4 or 8.5 as your target; 8.3 ends a year later, on 31 December 2027.
  • Run composer prohibits, lint and the test suite against the target version before switching.
  • Plan the operating-system move (Debian 12 to 13) alongside the PHP move, so both are done on your schedule.

Sources

SKYLINE Engineering

@skyline

The engineering team at SKYLINE Industrial Solutions. We publish field-tested guides drawn from real KSA and GCC deployments.

See author profile
SKYLINE engineering services

Need this implemented for you?

Reading is free — building it right takes a team. SKYLINE engineers ship Debian for Aramco vendors, banks, hospitals and government agencies across Saudi Arabia. Talk to us before you start.

Aramco Approved Contractor ISO 9001 · ISO 27001 SAMA CSF aligned NCA ECC ready 247+ KSA clients

Comments

0 total · 0 threads
Be the first to leave a comment.