PHP 8.2 End of Life: Upgrade Before 31 December 2026

In brief

PHP 8.2 receives security fixes only until 31 December 2026. After that date, no new vulnerability in PHP 8.2 will be fixed by the PHP project. The current release, 8.2.35 from 21 October 2026, fixed two critical remote code execution flaws, a reminder of what an unsupported version would miss. Move to PHP 8.4 (security fixes until 31 December 2028) or PHP 8.5 (until 31 December 2029), and start now: a tested upgrade takes most teams several weeks.

31 Dec 2026 - last day of security support for PHP 8.2
~10 weeks - left from the October security release to end of life
8.4 or 8.5 - the versions to target, supported until 2028 and 2029
2 - critical RCE flaws fixed in 8.2.35, the kind of fix that stops after end of life

The PHP 8.2.35 announcement on 21 October 2026 carried two messages. The first was urgent: it fixed CVE-2026-109618 and CVE-2026-109619 (known as PHP2Shell), two critical flaws that can allow unauthenticated remote code execution (see our guide to the October security release). The second was a deadline: “PHP 8.2 reaches end of life on 31 December 2026 and will receive no further security fixes after that date.”

What end of life means for PHP 8.2

Each PHP version gets two years of active support (bug and security fixes) and two more years of security fixes only. When security support ends, the PHP project stops publishing fixes for that branch altogether. A vulnerability found in January 2027 will be fixed in 8.3, 8.4 and 8.5, and not in 8.2.

VersionActive support untilSecurity fixes untilStatusPHP 8.2Ended 31 Dec 202431 Dec 2026Upgrade nowPHP 8.3Ended 31 Dec 202531 Dec 2027Short-term optionPHP 8.431 Dec 202631 Dec 2028Recommended for mostPHP 8.531 Dec 202731 Dec 2029Longest support

Some Linux distributions and commercial vendors keep patching PHP 8.2 inside their own long-term releases. That buys time on those platforms, but only for what the vendor chooses to backport, and only on their packages: official Docker images and source builds stop with the PHP project.

Which version should you move to?

🪜 PHP 8.3: the smallest step

Fewest changes from 8.2, so the quickest upgrade.
But security fixes end on 31 December 2027: you would repeat the exercise in a year.

✅ PHP 8.4: the right target for most

Security fixes until 31 December 2028.
Mature and widely supported by frameworks, CMSs and hosting platforms.
Adds property hooks and asymmetric visibility.

🚀 PHP 8.5: the longest runway

Security fixes until 31 December 2029.
Adds the pipe operator and a built-in URI extension.
Check that your framework, CMS and extensions support it before you commit.

What changes between 8.2 and 8.4 or 8.5

Most applications that run cleanly on 8.2 move to 8.4 with modest work. The changes to watch, by version:

**PHP 8.3: **typed class constants, json\_validate(), the #\[\\Override\] attribute, and readonly properties that can be reinitialised during cloning.
**PHP 8.4: **property hooks, asymmetric visibility, new without parentheses in method chains, array\_find() and friends, and a deprecation that catches many older codebases: implicitly nullable parameters such as function f(Foo $x = null) must now be written ?Foo $x = null.
**PHP 8.5: **the pipe operator |>, the URI extension, clone with property overrides, the #\[\\NoDiscard\] attribute, array\_first() and array\_last(), and backtraces in fatal errors.

Deprecations are notices, not failures, but they become errors in a later major version. Fix them as part of the upgrade rather than silencing them. Our overview of PHP 8.3 and later covers the new features in more depth.

A five-step upgrade plan

Scan for compatibility problems and apply safe automatic fixes:

# Find code that breaks or is deprecated on PHP 8.4
composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs -p --standard=PHPCompatibility --runtime-set testVersion 8.4 src/

# Preview automatic upgrades (review the diff like any pull request)
composer require --dev rector/rector
vendor/bin/rector process src --dry-run

<?php
// rector.php: upgrade rules for PHP 8.4
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src'])
    ->withPhpSets(php84: true);

While you are changing runtimes, it is a good moment to review your PHP configuration too: our guide to secure PHP settings lists the production defaults worth carrying over.

If you cannot upgrade by 31 December

**Use a vendor that still patches 8.2. **Your Linux distribution’s long-term packages, or a commercial extended-support build. Confirm in writing which fixes they cover and until when.
**Reduce exposure. **Keep unsupported systems off the public internet where possible, behind a VPN or an IP allow-list, and apply the interim hardening from the October advisory.
**Set a date. **End of life does not move. Every month on an unsupported version adds risk, and the next critical flaw will not be fixed for it.

Questions for your team this week

Five questions

Which of our applications, containers and servers still run PHP 8.2 or older?
Are we already on 8.2.35, with the October security fixes?
Does every framework, CMS, plugin and extension we use support PHP 8.4?
Who owns the upgrade, and what is the target date before 31 December?
For anything that will miss the date, what is the interim plan and who signs off the risk?

PHP upgrade