PHP 8.2 reaches end of security support on 31 December 2026 — after that date no new interpreter vulnerability will get a patch. This is not a "someday it would be good" — it is a deadline with a concrete date: two months left, and the upgrade from 8.2 to 8.4 is one of the easiest migrations in PHP history — code written for 8.2 usually needs cosmetic fixes. This article shows how to check whether the problem affects your system, what options you have and how to plan the work before the end of the year.
Key takeaway: PHP 8.2 joins 8.1, 8.0, 7.4 and older in the unsupported category on 31.12.2026. The way out is an upgrade to 8.3 or 8.4. For most applications this is days of work, not months: compatibility audit, deprecation fixes, tests and a staging rollout, then production.
What exactly ends on 31 December 2026
PHP 8.2 was released on 8 December 2022. Under the PHP release cycle (four years since 2024: two years of bug fixes and two years of security fixes), version 8.2 has security support until the end of 2026.
Until 31 December 2026 PHP 8.2 still receives critical security fixes — if a vulnerability is reported and fixed before that date, the patch reaches 8.2 too. After 31 December 2026 the branch moves to the archive: no patches, no releases, not even for critical vulnerabilities.
What this means in practice for a system on 8.2.
- New interpreter vulnerabilities stay unpatched forever — the system becomes a target, not a "theoretical risk".
- You also stop receiving bug fixes — problems the community finds and fixes in 8.4 will stay in 8.2 forever.
- More and more libraries will raise their minimum PHP version — package updates will become impossible without a migration.
- Hosting providers start retiring old versions — after EOL they usually stay on servers for a year or two, then disappear or become a paid "legacy add-on".
The history of previous EOLs is visible in numbers: PHP 7.4 stopped receiving patches in November 2022, PHP 8.0 in November 2023, PHP 8.1 at the end of 2025. Each of those dates is the moment when the cost of staying put jumps. The full date table is in the article on PHP versions and support dates.
Who the deadline affects
A broad group of systems runs on PHP 8.2 today — and it is not only about "old applications".
- Custom applications and internal systems — built in 2023–2024 on what was then the current PHP version. Nobody updated them because "it works".
- Stores and sites on popular platforms — PrestaShop 8.x supports PHP 8.2 (and newer), WordPress runs on 8.2 without problems. But the platform is not everything — plugins, modules and themes decide.
- Framework applications — Laravel 10/11 support PHP 8.2; if the application is on an older framework version, a framework upgrade is waiting before the PHP upgrade.
- Systems on managed hosting — some hosts keep 8.2 as a "safe compromise" between newness and compatibility. After EOL that attitude will change.
If you do not know which version your system runs, you can check it in a minute.
How to check your system's PHP version
The simplest methods, from least to most invasive.
# From the command line (SSH)
php -v
# Or via a query to the application (if you have file access)
php -r "echo PHP_VERSION;"
Without server access, read the version from the hosting panel ("PHP versions" or "PHP configuration") or from inside the application — WordPress shows it under Tools → Site Health → Info, PrestaShop under Advanced → Information, and custom applications often in the admin panel footer.
Tip: If you manage several projects, do a one-off review of all of them — PHP version, framework/platform version and the date of the last dependency update. It takes 15 minutes and gives you a risk map for the coming months.
Three scenarios — what to do before the end of the year
For a system on PHP 8.2 you have three paths. The first two are sensible; the third is postponing the problem.
Scenario A — upgrade to PHP 8.3 or 8.4. The default and usually cheapest path. The 8.2 → 8.3 → 8.4 transition is the smallest jump between versions in the history of PHP 8 — most changes are deprecations that keep working but clutter the logs. For a typical application: compatibility audit, fixes, tests, deployment. Days to two weeks of work, depending on project size and test state. The details of the transition are in the article on the PHP 7.4 to 8.x migration — the 8.2 → 8.4 section covers exactly this scenario.
Scenario B — stay on 8.2 with commercial extended support. Companies such as Zend or TuxCare sell extended security patches for versions past EOL. This makes sense in one case: the system is so large that migration will take quarters, and you need patches "now". The cost is usually several to a dozen thousand PLN per year and — importantly — it does not replace the migration, it buys time. Vulnerabilities are patched by the vendor, not the PHP community.
Scenario C — leave it and "see what happens". Not recommended. After EOL the risk grows while the migration cost does not shrink — it grows, because more versions pile up to catch up on and more updated libraries require the newer PHP. Add the non-technical dimensions: security audits, GDPR, and insurers and B2B clients increasingly ask about supported component versions.
Action plan until 31 December 2026
Two months is enough time for an orderly 8.2 → 8.4 migration. A realistic work breakdown.
| Timing | Stage | Outcome |
|---|---|---|
| By the end of October | Compatibility audit (PHPCompatibility, PHPStan), dependency inventory | Blocker list and plan |
| First half of November | Deprecation fixes, dependency updates | Code compatible with 8.4, green tests |
| Second half of November | Staging on 8.4 with real data, critical-path tests | Confirmed compatibility |
| December | Production rollout outside peak hours, monitoring | System on 8.4 before EOL |
If the project is small, the whole thing fits in a single week. If the system is large and untested — start right away, and if you will not make it by the end of the year, Scenario B (commercial support) buys a buffer to finish the migration without leaving the system unpatched.
What breaks on the 8.2 → 8.4 transition
Jumping from 8.2 to 8.4 is two versions apart and — good news — neither removed functions that typical applications use. The problems you will actually see are mostly deprecations and a few behavior changes.
- Typed class constants (8.3) — code overriding constants in child classes with a changed type gets an error. In practice this affects mostly libraries — updating them fixes it.
get_class()without an argument (8.3) — deprecated; calls inside a class should becomestatic::classorself::class. Rector does this automatically.- Implicitly nullable parameters (8.4) —
function f(string $x = null)is deprecated since 8.4; the correct form is?string $x = null. A cosmetic change, but it requires going through the signatures — Rector again. - Interpolation and dynamic property deprecations (from 8.2) — if the system only recently moved to 8.2, those warnings are still in the logs; clean them to zero while you are at it, because they clutter monitoring.
- Dependency changes — the most common real problem: raising PHP means raising libraries, and some of them changed APIs between versions. That is work to plan for — not a surprise.
After the migration, keep deprecation monitoring in the logs for a few weeks. Remaining warnings are a to-do list before the next step (8.5, then 8.6, expected at the end of 2026).
How long it takes and what it costs
The 8.2 migration is the cheapest type of PHP migration — the code is already modern and the differences between versions are small.
| Project | Scope of work | Time | Cost |
|---|---|---|---|
| Small app / site | audit, deprecation fixes, smoke tests | 1–3 days | 1,500–5,000 PLN |
| Medium app | audit, fixes, dependency updates, staging | 1–2 weeks | 5,000–15,000 PLN |
| Large untested system | safety-net tests + staged migration | 3–8 weeks | 15,000 PLN+ (staged) |
Add the cost of extended support if you choose Scenario B as a buffer. Ranges for full migrations from old versions (5.6, 7.x) are in the article on the PHP migration cost, and the service scope on the code maintenance and modernization page.
Frequently asked questions
Will PHP 8.2 stop working on 1 January 2027?
No — the system keeps running. Support ends, not operation. After 31 December 2026 PHP 8.2 receives no patches, so newly discovered vulnerabilities stay unpatched. The risk is not immediate, but it grows every month — which is why migrations are planned before EOL, not after.
What is the difference between "active support" and "security support" for PHP?
Active support (the first two years) covers bug and security fixes. Security support (the next two years) is critical security fixes only — no bug fixes. PHP 8.2 has been in security support since 1 January 2025 and leaves it on 31 December 2026.
Can I jump straight from PHP 8.2 to 8.5?
Yes — and it is a sensible option if you want to avoid another migration a year from now. The 8.2 → 8.5 transition spans three steps, but they are still mostly deprecations and dependency changes. One condition: the framework and libraries must support 8.5. If they do not — migrate to 8.4 (full support until the end of 2028) and plan 8.5 later.
Does WordPress still work on PHP 8.2 after end of support?
WordPress runs on 8.2 and will not "stop" — but WordPress itself raises requirements over time, and plugins and themes increasingly require newer PHP. A site on 8.2 after EOL is a growing security risk, especially with unmaintained plugins. The safe upgrade process is covered in the article on WordPress and PHP 8.
Does the 8.2 migration require downtime?
No. You work on staging against a data copy, and in production you only swap the PHP version outside peak hours, with an instant rollback (the old version stays on the server). All verification happens before the rollout.
What does staying on PHP 8.2 after EOL cost?
Directly — nothing, until a exploitable vulnerability is discovered. Indirectly: commercial support usually costs several to a dozen thousand PLN per year, and the incident risk in an unpatched system grows over time. In practice the most expensive option is "do nothing" — the cost of a security incident and a forced migration under pressure is higher than a planned upgrade.