PHP end of life: which branches still receive patches

Supported branches (php.net, October 2026)

Each branch gets two years of active support — bugs and security fixes in regular point releases — followed by two years of security-only support for critical issues. After four years the branch is closed.

Closed branches: 8.1 reached end of life on 31 December 2025, 8.0 on 26 November 2023, 7.4 on 28 November 2022. Everything older has been unsupported for years.

What “security support only” means in practice

Security-only support is not slower support — it is narrower. The branch still receives fixes for critical issues, but no ordinary bug fixes, and releases appear only when someone reports something serious. Two things follow that people often miss:

• 8.2 is the last supported branch to be patched for this month's RCEs, and it closes on 31 December 2026. After that date a new critical bug will arrive with no fix at all — which is exactly the situation owners of 8.1 sites are in today.
• End-of-life branches still get reported vulnerabilities. This month PHP published minimal source backports for 7.4, 8.0 and 8.1 — you can only use them by building PHP yourself, which almost nobody running a website is set up to do.

Why an outdated branch is a business problem

• It is unpatched by definition. With CVE-2026-109618 and CVE-2026-109619 there is no configuration that closes the hole — no header, no firewall rule, no session.upload_progress setting. The build is the fix.
• Compliance takes the date literally. PCI DSS requires critical patches to be applied within a defined period; “the vendor no longer supports it” is not an accepted exception for a system that handles card data.
• Hosting panels drop old builds. Over time cPanel, Plesk and shared hosts remove end-of-life branches from their selectors, and a site that depends on one either breaks or stops receiving updates with nobody noticing.
• The upgrade gets more expensive with time. Two or three major versions of deprecations in one step is a project. One version at a time is maintenance.

How to move off an end-of-life branch

1. Inventory first. Find every application on the server and the branch each one uses: ls /etc/php on Debian-family systems, the panel's per-site PHP selector, your containers. One server often serves three sites on three branches.
2. Create a copy and test there. A staging copy of the site on the target branch, with a database snapshot. Most breakage shows up on the first page load: removed mysql_* calls in old code, deprecated dynamic properties, changed string functions.
3. Check the platform, not just PHP. WordPress, Bitrix, Laravel and every plugin have their own supported range. Running a platform outside its supported PHP range is how a working site turns into an unsupported one.
4. Move branch by branch. 8.1 → 8.2 → 8.3 in sequence, testing between steps, is cheaper than jumping to the newest version and debugging everything at once.
5. After the switch, verify on the server (php -v in the pool the site uses) and re-run an outside check to confirm the published version moved too.

If the site discloses an end-of-life version, our checker flags it as critical. If it discloses nothing, the checker says so and you read the version on the server — that is the only honest path.

Sources

• php.net — supported versions and support policy
• php.net — end-of-life branches
• php.net — security releases, October 2026