Cybersecurity

PHP 8.1 reached end of life: what it means for your servers and how to move on

PHP 8.1 lost upstream support on 31 Dec 2025 (last release 8.1.34). What that means, where distributions still patch it, and how to plan your move.

Published
Reading time
7 min read

PHP 8.1 reached the end of its upstream life on 31 December 2025. Its last release from the PHP project was 8.1.34, published on 18 December 2025. Since then the PHP project no longer issues 8.1 releases, even for security problems.

That does not automatically mean every server with PHP 8.1 is unpatched: some Linux distributions keep backporting fixes into their own 8.1 packages. This article explains the difference, shows how to see which situation you are in, and how to plan the move to a supported branch.

What "end of life" means upstream

Each PHP branch gets two years of active support (bug and security fixes in regular releases), then two years of security-only fixes released as needed. After those four years the branch is end of life and php.net lists it as unsupported. For 8.1 that cycle ran from the first release, 8.1.0 on 25 November 2021, to the end of security support on 31 December 2025.

October 2026 showed what this means in practice. When the PHP project fixed two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, the fixed releases were 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The PHP advisory stated plainly that PHP 8.1 and older no longer receive updates from the project. Because of the severity, the security team made an exception and published minimal source backports for 7.4, 8.0 and 8.1 for people building from source, but there was no 8.1 release. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October 2026. Our separate article on those two vulnerabilities covers them in detail: PHP critical vulnerabilities CVE-2026-109618 and CVE-2026-109619.

The lesson: on an end-of-life branch you depend entirely on whoever built your PHP packages.

Where PHP 8.1 is still patched: Ubuntu 22.04 LTS

Ubuntu 22.04 LTS (jammy) ships PHP 8.1 as its default PHP. Ubuntu keeps the original upstream base, 8.1.2, and backports fixes into it, so a fully patched system shows a version such as 8.1.2-1ubuntu2.28. That package, published in October 2026, includes the fixes for CVE-2026-109618 and CVE-2026-109619 according to its changelog. A scanner that only reads "8.1.2" will report it as vulnerable even when it is not; the package version is what counts.

How long this lasts depends on Ubuntu's lifecycle and the archive component:

  • Ubuntu 22.04 LTS has standard security maintenance until May 2027 for packages in main. On jammy, php8.1-cli, php8.1-common and libapache2-mod-php8.1 are in main, while php8.1-fpm is listed in universe; all of them are built from the same php8.1 source package and are updated together.
  • After May 2027, Expanded Security Maintenance through Ubuntu Pro covers main and universe until May 2032.

So Ubuntu 22.04 users have a supported, patched PHP 8.1 today, but on a clock that is running out, and with libraries and frameworks steadily dropping 8.1 from their requirements.

Where it is not patched

  • Debian: no supported Debian release ships PHP 8.1. Debian 12 (bookworm) ships 8.2 and Debian 13 (trixie) ships 8.4. Debian 11 (bullseye) shipped 7.4 and its LTS period ended on 31 August 2026.
  • Self-compiled PHP or builds bundled by other vendors: no upstream releases any more. The October 2026 source backports were a one-off, not a promise.
  • Third-party repositories that still publish 8.1 packages: whether fixes are included depends on that maintainer. Read their changelog rather than assuming.

Find out what you are running

php -v
ls /etc/php/
systemctl list-units 'php*-fpm*'
apt policy php8.1-fpm php8.1-cli
apt changelog php8.1-cli | head -40

apt policy shows the installed version and which repository it came from; a line pointing to security.ubuntu.com or the Ubuntu archive means distribution packages. The changelog lists which CVEs each package update fixed. On servers with several sites, check which pool each site uses:

grep -rn '^listen' /etc/php/*/fpm/pool.d/

Planning the move

Your setupSecurity fixes todayRecommended move
Ubuntu 22.04 with PHP from the Ubuntu archiveUbuntu security updates; standard maintenance until May 2027Move to Ubuntu 24.04 LTS (PHP 8.3) or 26.04 LTS (PHP 8.5) before May 2027
PHP 8.1 from a third-party repositoryOnly what that maintainer shipsMove to PHP 8.4 or 8.5
Self-compiled or vendor-bundled 8.1None from the PHP projectMove now

Choose the target with the support table in mind. PHP 8.2 itself reaches end of life on 31 December 2026 and 8.3 on 31 December 2027, so from 8.1 the sensible upstream targets are 8.4 (security fixes until 31 December 2028) or 8.5 (until 31 December 2029). If you rely on distribution packages, the operating-system release decides the version: Ubuntu 24.04 LTS brings 8.3 and Ubuntu 26.04 LTS brings 8.5.

Work through the official migration guides in order (8.1 to 8.2, 8.2 to 8.3, 8.3 to 8.4 and, if needed, 8.4 to 8.5). The most common surprises in this range are dynamic properties being deprecated in 8.2, and implicitly nullable parameter types being deprecated in 8.4. Test in a staging copy with error_reporting = E_ALL and logging enabled, and update the framework and Composer dependencies first.

For the operating system itself, building a fresh server on the newer release and migrating sites to it is often cleaner than an in-place upgrade, and gives you an easy way back. If you run on a Skyline Cloud VPS, Ubuntu 24.04 LTS is among the available images.

What you should do

  • List every server and site still on PHP 8.1, and record where each PHP build comes from.
  • On Ubuntu 22.04, keep applying security updates, confirm with apt changelog that recent fixes are present, and schedule the move off 22.04 before May 2027.
  • Replace any self-compiled or third-party 8.1 build with a supported branch now.
  • Target PHP 8.4 or 8.5 so you do not have to repeat the exercise when 8.2 and 8.3 reach end of life.
  • Upgrade frameworks and libraries first, test with full deprecation logging, and keep the old setup available until the new one has run cleanly.

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 Cybersecurity 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.