Debian

PHP versions in Debian and Ubuntu explained: which release ships what, and why the numbers look old

Which PHP each Debian and Ubuntu release ships, why a patched server can still show an old-looking version, and how to read and compare package versions.

Published
Reading time
7 min read

Run php -v on a fully updated Ubuntu 24.04 server and you will see PHP 8.3.6, although the PHP project has released 8.3.36. Security scanners often flag this as outdated and vulnerable. Usually it is neither: the distribution has backported the fixes into its own package. This article lists the PHP branch each supported Debian and Ubuntu release ships, explains why version numbers look the way they do, and shows how to check whether a specific fix is installed.

Which release ships which PHP

Each release ships one default PHP branch, selected by the php metapackage, and keeps it for the life of the release. Package versions below are those in the security or updates pocket on 31 October 2026.

ReleaseDefault branch (php metapackage)PHP package versionRelease support
Debian 12 (bookworm)8.2 (2:8.2+93)php8.2 8.2.35-1~deb12u1Debian LTS until 30 June 2028
Debian 13 (trixie)8.4 (2:8.4+96)php8.4 8.4.27-1~deb13u1Until 9 Aug 2028; LTS until 30 June 2030
Ubuntu 22.04 LTS8.1 (2:8.1+92ubuntu1)php8.1 8.1.2-1ubuntu2.28Standard security maintenance until May 2027
Ubuntu 24.04 LTS8.3 (2:8.3+93ubuntu2)php8.3 8.3.6-0ubuntu0.24.04.13Standard security maintenance until May 2029
Ubuntu 26.04 LTS8.5 (2:8.5+99ubuntu1)php8.5 8.5.4-0ubuntu1.5Standard security maintenance until May 2031
Ubuntu 26.108.5php8.5 8.5.9-0ubuntu2.1Until July 2027

A few things stand out. Debian has never shipped PHP 8.3 in a stable release, and none of the currently supported Ubuntu releases ships 8.2 or 8.4. Debian 11 (bullseye), which shipped PHP 7.4, is past the end of its LTS period. If you need a branch your release does not ship, the options are a newer release or a third-party repository.

Why the numbers look old

Stable distributions promise that an update will not change how the system behaves, apart from fixing the problem. The Debian security FAQ explains the rule: make as few changes as possible, because users rely on the exact behaviour of a release, so instead of moving to a new upstream version the relevant fixes are backported. The FAQ also allows exceptions when a backport is not practical, coordinated with the security team.

The two distributions apply this differently for PHP:

  • Ubuntu keeps the original upstream version and adds patches. Ubuntu 22.04 started with PHP 8.1.2 and is still on 8.1.2, now at package revision 1ubuntu2.28. The October 2026 update in that revision fixed the critical CVE-2026-109618 and CVE-2026-109619, according to its changelog, even though the upstream fixes were only released for 8.2 and later.
  • Debian has, in practice, imported new upstream point releases of the same branch into stable updates: bookworm's PHP is at 8.2.35, matching upstream. The branch never changes, only the point release.

Both are legitimate ways of delivering security fixes. The consequence is the same: the upstream number alone does not tell you whether a system is patched.

How to read a package version

A Debian or Ubuntu version has up to three parts: [epoch:]upstream-version[-revision].

  • 2:8.2+93 is the php metapackage: epoch 2, the default branch 8.2, and revision 93 of the php-defaults source package.
  • 8.2.35-1~deb12u1: upstream 8.2.35, Debian revision 1, and ~deb12u1 marking the first update built for Debian 12. A tilde sorts before anything else, so this version is considered slightly older than a plain 8.2.35-1.
  • 8.1.2-1ubuntu2.28: upstream 8.1.2, Debian revision 1, Ubuntu's change 2, and its 28th update.
  • 8.3.6-0ubuntu0.24.04.13: Ubuntu packaged upstream 8.3.6 itself (the -0ubuntu marker), and 0.24.04.13 is the 13th update carrying the per-release 24.04 suffix.

To compare two versions exactly as the package manager does:

dpkg --compare-versions 8.2.35-1~deb12u1 lt 8.2.35-1 && echo older

The same rules explain a common surprise with third-party repositories: a version such as 8.2.35-1+0~20261021.94+debian12~1 sorts higher than Debian's 8.2.35-1~deb12u1, so adding such a repository replaces the distribution's packages on the next upgrade unless you pin it.

How to check whether a fix is installed

# installed version and where it comes from
apt policy php8.3-cli php8.3-fpm
# full package version of every PHP package
dpkg -l 'php*' | grep '^ii'
# which CVEs the installed package's updates fixed
apt changelog php8.3-cli | grep -m 20 CVE-

Then compare with the distribution's own data: the Debian security tracker (per source package, for example php8.2) lists the fixed version for each CVE and release, and Ubuntu publishes its CVE status pages and security notices at ubuntu.com/security. If your installed version is equal to or higher than the fixed version listed there, you have the fix, whatever php -v says.

Scanners and version banners

Many external scanners read the version from the X-Powered-By header and compare it with upstream releases. On distribution packages that leads to false alarms. Two practical steps:

  • Set expose_php = Off in the PHP configuration for web SAPIs, so the header does not advertise the version at all. It is not a security fix, only less noise and less information for attackers.
  • When a report flags "PHP 8.x.y is vulnerable", answer it with the package version and the distribution's fixed-version data, not by reinstalling PHP from elsewhere.

If you run a Skyline Cloud VPS, the images on offer are Ubuntu 24.04 LTS, Ubuntu 22.04 LTS and Debian 12, so the distribution PHP you install there is 8.3, 8.1 or 8.2 respectively, maintained through the distribution's security updates, which you apply inside your own server.

What you should do

  • Know which PHP branch your release ships and how long the release itself is supported.
  • Judge patch status by the full package version and the distribution's advisories, not by the upstream number.
  • Use apt changelog and the Debian or Ubuntu security trackers to confirm specific CVE fixes.
  • Turn off expose_php on production web servers.
  • If you add a third-party PHP repository, remember that its versions sort higher and will replace the distribution's packages unless pinned.

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.