PHP 8.2 end of life arrives on December 31, 2026. After that date, php.net publishes no further 8.2 security releases, and every CVE found afterwards gets fixes for PHP 8.3 and newer only. What that means for your servers depends entirely on where your PHP comes from. On a current distribution it is a calm, scheduled upgrade. On CentOS 7, RHEL 7 or Ubuntu 20.04 the date changes nothing, because those platforms stopped receiving PHP 8.2 builds long ago, and GetPageSpeed already ships the patched 8.2 for them.
PHP 8.2 released: December 8, 2022
Active support ended: December 31, 2024 (security fixes only since)
Security support ends: December 31, 2026
Still supported upstream: PHP 8.3 (to Dec 31, 2027), 8.4 (to Dec 31, 2028), 8.5
Patched 8.2 after EOL: GetPageSpeed Everpatch channels for CentOS 7 / RHEL 7
and Ubuntu 20.04
What actually ends on December 31, 2026
PHP branches get two years of active support and then two years of security-only fixes. PHP 8.2 entered the security-only phase at the end of 2024; that phase ends on December 31, 2026. After that date the PHP project tags no further 8.2 releases, for any severity. When the next PHP2Shell-class advisory lands, the official fixes will start at 8.3. The October 2026 advisory showed how fast such a disclosure turns into mass exploitation.
Nothing breaks on January 1. Your PHP 8.2 keeps serving requests exactly as before. What changes is the answer to “where does the next security fix come from.”
Your options, by platform
On a current distribution: upgrade to PHP 8.3 or 8.4
If you run a supported OS and installed PHP from its repositories or a maintained third-party one, this is the boring path, and the right one. The 8.2 to 8.3 jump is one of the mildest in recent PHP history, and 8.4 is close behind; most frameworks and CMSes have supported both for over a year. PHP 8.3 buys you upstream security fixes to the end of 2027, PHP 8.4 to the end of 2028.
One nuance worth knowing: a distribution’s own PHP packages outlive the php.net date. Debian 12 ships PHP 8.2 and keeps patching it for as long as bookworm itself is supported, the same way Ubuntu patches the stock PHP of each LTS. The end-of-life cliff is for everyone whose 8.2 does not come with distro security backing: EOL distributions, and PPA or third-party builds on any distribution.
On CentOS 7 / RHEL 7: the cutoff already happened in 2024
If you run PHP 8.2 on EL7, December 2026 is not your deadline. June 2024 was: that is when Remi, the de-facto source of PHP packages for EL7, stopped building for it, freezing CentOS 7 at PHP 8.2.20. Every 8.2 security release since then, PHP2Shell included, reached EL8 and newer only. Nobody ships a fixed PHP for CentOS 7 except GetPageSpeed.
The Everpatch PHP 8.2 channel carries the current upstream 8.2 release as signed RPMs, drop-in compatible with Remi’s packages in both shapes. For base-name packages (from remi-php82):
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php82 upgrade 'php-*'
systemctl restart php-fpm
For the php82 software collection (php82-php-* packages), no channel flag is needed:
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum upgrade 'php82-php*'
systemctl restart php82-php-fpm
Package names, configuration files and extension ABI stay the same, so PECL extensions and ionCube Loader keep working, and yum downgrade takes you back. Afterwards php -v prints Built by GetPageSpeed LLC.
And because EL7 packaging is independent of php.net’s calendar, upgrading the PHP version is also still on the table on CentOS 7: the PHP 8.4 stack for EL7 packages a fully supported current PHP for the EOL OS, and moving from 8.2 to 8.4 is usually a mild upgrade. Staying on patched 8.2 and moving to 8.4 are both supported paths; pick by what your codebase tolerates.
On Ubuntu 20.04: SurĂ˝ builds ended with focal
PHP 8.2 on Ubuntu 20.04 means the SurĂ˝ PPA, and the PPA stopped publishing focal builds when focal left standard support. Ubuntu Pro does not help here: ESM covers the stock PHP 7.4, not a PPA-installed 8.2. The Everpatch PHP 8.2 channel for Ubuntu 20.04 continues the same package line, drop-in compatible with the SurĂ˝ packages:
wget https://extras.getpagespeed.com/release-latest.deb
sudo apt install ./release-latest.deb
sudo apt update
sudo apt upgrade 'php8.2-*'
sudo systemctl restart php8.2-fpm
Package names stay php8.2-* and configuration stays in /etc/php/8.2/. Running Apache mod_php? Upgrade libapache2-mod-php8.2 as well and restart apache2 instead.
What happens to these channels after the EOL date
The Everpatch channels were built for exactly this moment. GetPageSpeed already maintains PHP branches years past their upstream end of life, 5.4 through 8.1 today, by porting each security fix from the maintained branches and validating it against the full phpt suite, real requests through PHP-FPM and mod_php, and in-place upgrade and downgrade paths. On January 1, 2027, PHP 8.2 simply joins that list: the channels keep delivering security fixes through a plain yum upgrade or apt upgrade after upstream stops.
Not sure whether the 8.2 build you are running is current? Paste your php -v or package list into the free PHP2Shell checker. It understands distro backports and vendor builds, and tells you per platform whether you are patched and what to run if not.
Free to install; commercial production use requires a subscription
The packages install from the public GetPageSpeed repository with no signup, free for personal, development and evaluation use. Commercial production use requires a subscription under the repository terms: GetPageSpeed Ultra ($500/year, up to 10 servers running your own services) or GetPageSpeed Fleet (from $800/year, for servers that host client websites or fleets larger than 10). That subscription funds porting each new PHP CVE to branches upstream has abandoned, which, from 2027, includes your PHP 8.2.
FAQ
Is PHP 8.2 still safe to run after December 31, 2026?
It keeps running, but every vulnerability discovered after that date goes unfixed in the official packages. How fast that becomes dangerous depends on the next CVE, not on the calendar; PHP2Shell went from disclosure to exploitation in the wild within days. Safe means one of: a distribution that still backports fixes to its own 8.2 (like Debian 12), an upgrade to 8.3 or newer, or a maintained backport channel.
Should I upgrade to PHP 8.3 or 8.4 instead of staying on 8.2?
If your code allows it, yes. Being on an upstream-supported branch is always the stronger position, and 8.2 to 8.3 is a mild jump. The patched 8.2 channels exist for the applications that cannot move yet: legacy codebases, vendor-locked platforms, or fleets where the OS itself is the blocker. Stay patched on 8.2 while you test, not instead of testing.
Does PHP 8.2 end of life affect Ubuntu 22.04 or Debian 12?
Not on the same date. Debian 12’s stock PHP 8.2 keeps receiving Debian security backports for as long as bookworm is supported, and Ubuntu LTS releases patch their stock PHP similarly (Ubuntu 22.04 ships 8.1 and still patches it, even though 8.1’s upstream support ended at the end of 2025). The date matters if your 8.2 comes from a PPA, or if your distribution is itself end of life.
Do I need a GetPageSpeed subscription to install the patched PHP 8.2?
Not for personal, development or evaluation use: the packages install from the public repository with no signup. Commercial production use requires GetPageSpeed Ultra or higher under the repository terms. Organizations with 250+ employees or $10M+ revenue, or anyone needing a contractual SLA and invoice/PO procurement, should contact us about Enterprise.
Conclusion
PHP 8.2 end of life on December 31, 2026 splits the world in two. On supported distributions, schedule the 8.3 or 8.4 upgrade this quarter and you are done. On CentOS 7, RHEL 7 and Ubuntu 20.04, where 8.2 security updates ended in practice long ago, the Everpatch PHP channels keep the branch patched past the date, in place, validated, and free to install, with commercial production use covered by GetPageSpeed Ultra.
Patching PHP is only half of an aging server. The NGINX in front of it drifts too, one config change at a time. GetPageSpeed Amplify runs scheduled gixy scans across every host and ties findings to live NGINX runtime metrics. Drop-in compatible with the deprecated nginx-amplify-agent (EOL January 2026).