PHP Versions and Support Dates — Which Version Is Safe [2026]

Which PHP versions are still safe, and which are past end of support?

This page collects the full PHP support schedule — release dates, ends of bug-fix and security support — plus a practical answer to which version a project should target in 2026. Treat it as a reference point for planning upgrades, security audits and conversations with your hosting provider.

Key takeaway: In 2026 three versions are safe: PHP 8.4 and 8.5 (full support) and 8.3 (security fixes only until the end of 2027). PHP 8.2 reaches end of support on 31 December 2026. Everything older — 8.1, 8.0, 7.x, 5.6 — is past EOL and receives no patches.

How the PHP release cycle works

PHP ships a new major version once a year, in November or December. Every branch gets four years of support — the cycle was extended from three to four years in March 2024 (the "release cycle update" RFC):

• years 1–2: full support (active support) — bug and security fixes,
• years 3–4: security support — critical security fixes only, no bug fixes,
• after 4 years: end of life (EOL) — no patches, no releases.

Point releases (8.4.1, 8.4.2…) appear every few weeks within an active branch. After EOL a branch receives not even critical patches — that is the fundamental difference between an "old version" and an "unsupported version".

• ## Table: PHP versions and support dates

Dates come from the official php.net schedule and the endoflife.date listing (as of October 2026). The next release — PHP 8.6 — is expected at the end of 2026.

Warning: If your system runs on PHP 8.2, two months remain until the end of security support. If it runs on 8.3 — a year. Every version below 8.2 is unpatched today. Check your version with php -v or in the hosting panel.

Which PHP version a project should target

The choice is a trade-off between newness and dependency compatibility. Practical recommendations for 2026.

The practical rule is simple: target a version with full support if your dependencies allow it. If not — pick the newest version the whole stack supports and plan the next step. "Staying on the old version because it works" postpones the cost rather than avoiding it.

What happens to a system after its PHP version reaches EOL

The system itself keeps running — the interpreter executes code as before. What changes is the environment.

• Vulnerabilities stay unpatched. Every new flaw in the interpreter and standard libraries stays open forever. Some can be exploited remotely, without server access.

• Dependencies stop updating. New library versions require newer PHP — without a migration you lose security fixes in dependencies too, not just the interpreter.

• Hosts retire old versions. After EOL versions survive on servers for a year or two, then disappear or become a paid add-on. A migration under a hosting deadline costs more than a planned one.

• The cost of people rises. Developers who know old versions are increasingly rare — maintenance rates climb and finding a contractor takes longer.

• Formal requirements appear. Security audits, GDPR, and B2B client and insurer requirements increasingly ask about supported component versions. A system past EOL is a risk item in every such review.

• The flip side: every upgrade is also a gain. PHP 8.x is significantly faster than 7.x and 5.6 (engine optimizations, JIT), and newer versions bring features that simplify code — from enums and readonly to property hooks. A migration is not just "patches", it is also performance and newer libraries.

How to plan an upgrade step by step

The order of work is the same regardless of the starting version.

1. Check the state — PHP version, framework/platform version, dependency list and their requirements. composer outdated, hosting panel, php -v.
2. Run a compatibility audit — PHPCompatibility and PHPStan show what will stop working on the target version. The result is a blocker list, i.e. the migration plan.
3. Protect yourself with tests — critical-path tests before the migration; without them every behavior change surfaces in production.
4. Refactor automatically — Rector ships rulesets for version transitions and does 80–90% of the mechanical work.
5. Deploy through staging — the target version with the same extensions as production, tests, then production outside peak hours with a rollback plan.

The full description of each stage — with commands and configuration — is in the PHP migration guide. If you are on 8.2 and looking at the 31 December 2026 deadline, the scenario and timeline are in the article on the PHP 8.2 end of life.

PHP versions in numbers — what the data says

It is worth knowing how version adoption looks in practice, because it drives library and hosting support.

• PHP 5.6 died in 2018 but kept appearing in production for years — today it is rare, mostly in internal systems and "frozen" deployments.
• PHP 7.x dominated 2016–2022 — many applications from that era still run, often on 7.4.
• PHP 8.x is the current standard — 8.1 and older 8.x releases are gradually being replaced by 8.2–8.4.
• WordPress has recommended PHP 8.x since version 6.x, and PrestaShop 8/9 supports 8.1–8.4 — platforms pull the ecosystem upward.

For a system owner the conclusion is one: the further from current versions, the less support is available — libraries, contractors, hosts. Upgrading "one version" every two years is far cheaper than jumping three generations every six years.

Frequently asked questions

Which PHP version is the safest in 2026?

PHP 8.5 and 8.4 — both have full support (bug and security fixes). PHP 8.3 receives security fixes only, until the end of 2027. All versions 8.2 and older are in security support with an expiring term (8.2) or past EOL.

Is PHP 7.4 still supported?

No. PHP 7.4 ended security support on 28 November 2022. A system on 7.4 runs, but receives no patches — neither in the interpreter nor (through version requirements) in most updated libraries. Migrating from 7.4 to 8.x typically takes 1–2 weeks of work.

What is end of life (EOL) for a PHP version?

EOL is the moment a PHP branch stops receiving any updates — including critical security fixes. After EOL, newly discovered vulnerabilities stay unpatched. The EOL date is known in advance, which sets PHP apart from many open-source projects — you can prepare for it.

Can my hosting provider force me to upgrade PHP?

Indirectly, yes. Hosts retire support for versions past EOL — first they stop updating them, then remove them from servers or move them to paid "legacy add-ons". If the system does not run on a newer version, changing hosts is an additional cost and migration risk.

Can I buy extended support after a PHP version reaches EOL?

Yes — companies such as Zend or TuxCare sell commercial security patches for versions past EOL (extended support). This is a buffer solution for large systems mid-migration; it usually costs several to a dozen thousand PLN per year and does not replace the target upgrade.

How often should PHP be upgraded?

• Realistically: every 2–3 years, jumping one or two versions. Each single-version upgrade is cheap (days of work), while a jump across three generations is expensive and risky. The best rhythm is an upgrade a year or two before the current version's EOL, when libraries are already ready.

Sources

• PHP.net — supported versions
• PHP.net — unsupported branches (EOL)
• endoflife.date — PHP schedule
• PHP RFC — extending the release cycle to 4 years
• PHP.Watch — PHP version status and changes