Each PHP branch gets about two years of active support and two years of security-only fixes, ending on December 31. As of October 2026, 8.2 to 8.5 are supported; 8.1 and older receive no fixes, including for the critical CVEs patched on 2026-10-21.
The three phases of a PHP branch
Every PHP minor version, such as 8.3 or 8.4, is a branch. Each branch moves through three phases after its first general-availability release.
| Phase | Approximate length | What you get |
|---|---|---|
| Active support | About 2 years | Bug fixes and security fixes, in regular patch releases |
| Security support | About 2 years | Fixes for security issues only, released as needed |
| End of life (EOL) | Indefinite | Nothing. No fixes of any kind from the PHP project |
Under the current policy, adopted around the PHP 8.1 era, support periods end on December 31 of the relevant year rather than on the anniversary of the release date. This makes planning simpler: you can treat each phase change as a year-end deadline.
Where each branch stands in October 2026
| Branch | Status (Oct 2026) | Active support until | Security support until |
|---|---|---|---|
| 8.5 | Active | 2027-12-31 | 2029-12-31 |
| 8.4 | Active | 2026-12-31 | 2028-12-31 |
| 8.3 | Security only | Ended | 2027-12-31 |
| 8.2 | Security only | Ended | 2026-12-31 |
| 8.1 | End of life | Ended | Ended 2025-12-31 (last release 8.1.34) |
| 8.0 and 7.x | End of life | Ended | Ended |
PHP 8.6 is at the release-candidate stage in October 2026. Release candidates are for testing, not production.
Always confirm against the official supported versions page, which is the authoritative source and is updated when dates change.
What “active” and “security-only” mean in practice
Active support
During active support, the branch receives regular patch releases. These fix ordinary bugs (crashes, incorrect behaviour, regressions) as well as security problems. If you hit a bug in PHP itself, an active branch is where it can be fixed.
Security-only support
In the security phase, only security issues are fixed. A non-security bug that affects your application will generally not be addressed in this branch; the answer is to upgrade. Releases also become less frequent and happen when a security fix is ready.
Security-only does not mean “unsafe”. A fully patched security-only branch is a reasonable production choice, especially if you have a dated upgrade plan. It does mean your remaining runway is short.
End of life
Once a branch is EOL, newly discovered vulnerabilities are not fixed by the PHP project. This is not hypothetical. On 2026-10-21, PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619 (CVSS v4.0 9.2). The advisories list PHP 5.4 through 8.5.11 as affected. Branches 8.1 and older received no fix, because they were already end of life.
A server running PHP 8.1.34, the final 8.1 release, is therefore affected by both vulnerabilities, and there is no upstream patch version to move to within 8.1.
A note on vendor and distribution support
The PHP project’s lifecycle is not the only one that matters. Some operating system vendors support the PHP package they ship for the lifetime of their own release, which can extend well beyond the upstream EOL date.
- Long-term-support Linux distributions such as Ubuntu LTS, Debian stable and Red Hat Enterprise Linux may backport security fixes into older PHP packages.
- Some hosting providers and commercial vendors maintain patched builds of EOL branches.
If you rely on this, verify it rather than assume it. Check whether your vendor has actually published a fix for each relevant CVE, using trackers such as the Ubuntu CVE tracker, the Debian security tracker or Red Hat security updates. Coverage varies by package, repository and release, and not every CVE is fixed for every branch. Packages from third-party repositories (for example PPAs or community repositories) follow their maintainer’s own policy, which may differ.
The guide on checking whether a PHP security patch is installed explains how to verify a backported fix on your own server.
Turning the lifecycle into a plan
Treat the lifecycle table as a calendar, not reference trivia.
- Inventory every PHP runtime you run. Include CLI, PHP-FPM pools, cron jobs, containers and staging. Different sites on the same server can use different versions. The how to check your PHP version guide covers each method.
- Mark the security-support end date for each branch. In October 2026, anything on 8.2 has roughly ten weeks left. Anything on 8.1 or older is already unsupported.
- Choose a target branch with runway. Upgrading to the newest stable branch gives the longest support window. In late 2026, 8.4 or 8.5 gives you security fixes into 2028 or 2029.
- Allow time for testing. A minor-version upgrade can surface deprecations and behaviour changes in your code and dependencies. Plan for staging, testing and a rollback path. See PHP upgrade planning.
- Keep patching within the branch. Being on a supported branch only helps if you install its patch releases. A server on 8.3.10 is on a supported branch but is missing many fixes.
Suggested deadlines
| If you run | Recommended action |
|---|---|
| 7.x or 8.0 | Treat as urgent. Upgrade, or confirm in writing that your vendor supplies patched builds |
| 8.1 | Unsupported upstream since 2025-12-31 and affected by the October 2026 RCEs. Upgrade now |
| 8.2 | Patch to 8.2.35 immediately, and complete an upgrade before 2026-12-31 |
| 8.3 | Patch to 8.3.36, and schedule an upgrade during 2027 |
| 8.4 or 8.5 | Patch to 8.4.27 or 8.5.12, and keep following patch releases |
How PatchScope uses the lifecycle
The PHP version checker reports a branch’s lifecycle status alongside known vulnerabilities, so an EOL branch is flagged even when no CVE has been matched yet. It works from upstream version numbers and upstream dates, as described on the methodology page. If your PHP comes from a distribution with its own support policy, read the result together with your vendor’s security tracker.