Runtime
PHP
PHP 8.2 reaches its security end-of-life on December 31, 2026. Active (bug-fix) support already ended December 31, 2024; after the 2026 date the 8.2 branch receives no further releases at all, including security fixes, so applications and container images pinned to `php:8.2` stop getting patched.
departs 31 Dec 2026
Quick answers
- Is it true that PHP 8.2 reaches end of life (security support ends) on December 31, 2026?
- Yes. PHP has officially announced it, effective 31 Dec 2026. PHP versions get roughly two years of active (bug-fix) support followed by one more year of security-only fixes.
- When does it take effect?
- 31 Dec 2026. Verified against the vendor's own announcement.
- What should I use instead?
- Upgrade to a supported PHP release — 8.3 or 8.4 — before December 31, 2026.
What this means for you
PHP versions get roughly two years of active (bug-fix) support followed by one more year of security-only fixes. Per php.net's official support table, PHP 8.2 was released December 8, 2022, its active support ended December 31, 2024, and its **security support ends December 31, 2026**. After that date the PHP project publishes no further 8.2 releases — not even for critical security vulnerabilities — so anything still running 8.2 accumulates unpatched CVEs while continuing to work. This is one of the most widely deployed PHP branches: it underpins a large share of WordPress, Laravel, Symfony, Drupal and general PHP application deployments, and the official `php:8.2` Docker images (including the common `php:8.2-fpm`, `php:8.2-apache`, and `php:8.2-cli` tags) that back countless container builds. It does not affect PHP 8.3 (security support through December 31, 2027) or 8.4 (through December 31, 2028), which remain supported on their own schedules.
Where to go
Upgrade to a supported PHP release — 8.3 or 8.4 — before December 31, 2026. Most PHP 8.2 code runs on 8.3 and 8.4 with few or no changes; review the official migration guides (`UPGRADING` / "Migrating from PHP 8.2.x to 8.3.x" and to 8.4.x) for deprecations and behavior changes, run your test suite against the new runtime, and check that any C-extensions (and PECL modules) you depend on ship builds for the target version. For Dockerized apps, bump the base image from `php:8.2` (and `php:8.2-fpm` / `php:8.2-apache`) to the matching `php:8.3` or `php:8.4` tag and rebuild. If you run PHP through a managed platform (a hosting control panel, a PaaS, or a distro package), confirm that platform offers 8.3/8.4 before the deadline. Staying on 8.2 past its security EOL means running an internet-facing runtime that will never be patched again.
- PHP 8.3 — active support through December 31, 2025, security support through December 31, 2027
- PHP 8.4 — the current release; active support through December 31, 2026, security support through December 31, 2028
- A commercial extended-support offering (e.g. a vendor backporting security fixes) only as a stopgap if an upgrade genuinely cannot be completed in time
PHP 8.2 reaches its security end-of-life on December 31, 2026, per php.net’s official Supported Versions table. Its active (bug-fix) support already ended on December 31, 2024.
What end of support means
Each PHP release gets about two years of active support (bug fixes) and then one more year of security-only fixes. Once a branch passes its security end-of-life, the PHP project stops publishing releases for it entirely — including fixes for critical security vulnerabilities. Code on 8.2 keeps running, but the runtime becomes a patch dead end: newly discovered CVEs in the interpreter and its bundled extensions will never be fixed for 8.2.
Who this affects
PHP 8.2 is one of the most widely deployed PHP branches. It runs a large share of WordPress, Laravel, Symfony, and Drupal sites, and it backs the official php:8.2 Docker images — including the very common php:8.2-fpm, php:8.2-apache, and php:8.2-cli tags used in application and CI containers. Anything internet-facing that stays on 8.2 after the deadline is the highest-priority case to move. PHP 8.3 (security support through December 31, 2027) and 8.4 (through December 31, 2028) are unaffected.
What to do
Before December 31, 2026:
- Inventory where 8.2 runs — server packages,
php:8.2*base images in Dockerfiles and compose files, CI configs, and managed-platform runtime settings. - Upgrade to PHP 8.3 or 8.4. Most 8.2 code runs unchanged; work through the official “Migrating from PHP 8.2.x” upgrade guides for deprecations and behavior changes.
- Rebuild and test — run your test suite on the new runtime and confirm any C-extensions or PECL modules you rely on publish builds for the target version.
Running an internet-facing PHP version past its security EOL means shipping a runtime that will never receive another patch. Treat the upgrade as security maintenance, not a nice-to-have.
This entry tracks php.net’s official Supported Versions table; if the PHP project changes the 8.2 support dates, the entry will be updated with a changelog note.
Entry changelog
- — last reviewed.
- — Entry created from php.net's official Supported Versions table, which lists PHP 8.2 (released 2022-12-08) with active support ending 2024-12-31 and security support ending 2026-12-31. After that date the 8.2 branch receives no further releases, including security fixes. Machine-detectable in a code repository via the `php:8.2` container base image tag (covering `php:8.2`, `php:8.2.x`, and the `php:8.2-fpm` / `php:8.2-apache` / `php:8.2-cli` variants), so an image detect fingerprint was added and validated against the public dataset to confirm it does not collide with `php:8.3`.
Put this countdown in your README
Building on PHP? Drop this badge into a project’s README or docs — it shows the days left and
refreshes on its own every night from this page. 
[](https://lastcall.dev/entries/php-8-2-end-of-life)Spot an error or a changed date? Tell us and it’s corrected the same night.