PHP Extended Support: Coverage & Top Providers in 2026

Key Takeaways

• PHP extended support backports security patches for PHP versions past their end of life (EOL), letting you keep production applications secure without a forced migration.
• Extended support doesn’t change your PHP version or application behavior. It closes known security holes while your migration happens on your schedule.
• As of August 2026, PHP 8.1 and every version below it are EOL and get zero community patches. PHP 8.2, 8.3, 8.4, and 8.5 are still supported, but each has a fixed expiry date.
• Running EOL PHP without extended support means unpatched CVEs, greater audit and compliance risk, and a widening attack surface.

If you run PHP in production, end of life puts you in a familiar, ugly spot: upgrade an application that hasn’t been touched in years, or keep shipping a runtime that no longer gets security patches. Neither option is great.

PHP extended support is the third path.

This article covers what extended support actually includes (and what it doesn’t), the compliance and CVE risks of skipping it, which PHP versions need it right now, how to weigh it against upgrading, and the providers worth knowing in 2026.

What Is PHP Extended Support?

PHP extended support is a vendor-provided service that continues shipping security patches for a PHP version after the PHP project itself stops. When a PHP version reaches end of life, the PHP project closes the book on it: no more CVE fixes, no more patches, nothing.

Extended support reopens that book. A vendor monitors newly disclosed vulnerabilities and backports the fixes into the EOL runtime, so your application keeps running on a patched runtime while you plan a migration on your own schedule rather than someone else’s.

How the PHP Release Lifecycle Works

PHP releases now follow a four-year lifecycle: two years of active support, then two years of security support. That window came from a March 2024 change to PHP’s release cycle and applies to PHP 8.1 and later. Older branches such as PHP 7.4 and 8.0 kept the previous three-year lifecycle of two years of active support plus one year of security support.

Lifecycle phase	Duration	What you get
Active support	First 2 years	Bug fixes, performance fixes, security patches
Security support	Next 2 years	Critical security fixes only
End of life	After 4 years	Nothing. No patches of any kind.

Here’s where each PHP version sits:

PHP version	Released	End of life	Status (August 2026)
7.4	Nov 2019	Nov 28, 2022	EOL – no community patches
8.0	Nov 2020	Nov 26, 2023	EOL – no community patches
8.1	Nov 2021	Dec 31, 2025	EOL – no community patches
8.2	Dec 2022	Dec 31, 2026	Security-only (EOL end of 2026)
8.3	Nov 2023	Dec 31, 2027	Security-only
8.4	Nov 2024	Dec 31, 2028	Active support until Dec 31, 2026, then security-only
8.5	Nov 2025	Dec 31, 2029	Active support

Did You Know: The PHP project now aligns every EOL to December 31 of the relevant year. PHP 8.1 was the first version to benefit from the extended cycle, with its EOL shifted from November 2024 to December 31, 2025.

What PHP Extended Support Actually Provides

Extended support is narrow on purpose. The job is to keep an EOL PHP version secure, not to modernize it, refactor it, or add features. It delivers the security patches the community stopped shipping, in a form you can deploy without breaking the application that depends on that exact runtime.

 

Reality Check: Extended support is not a free pass to never upgrade. It buys you time to migrate without an emergency. Treat it as a runway, not a destination.

Backported security patches

The core service is backporting. When a new CVE lands against a still-supported PHP branch, the provider analyzes whether the EOL version is affected, then ports the fix back into your old runtime without changing its behavior. You stay on PHP 7.4 or 8.1, but the vulnerability is closed.

Compatibility testing and non-disruptive delivery

A backported patch still has to preserve application stability. Good extended PHP support includes regression testing against the EOL version, so the fix doesn’t introduce behavior changes. Depending on the provider and platform, patches ship as native packages – RPM or DEB on Linux – that install through your existing package manager, with equivalent installers where Windows is covered.

Version and OS scope

Each provider supports a specific set of PHP versions on a specific set of operating systems. For example, TuxCare’s Endless Lifecycle Support (ELS) for PHP spans PHP 5.2 through 8.4, applying ELS security patching to each branch once it reaches EOL – currently 5.2 through 8.1 – across Windows and major Linux distributions, including AlmaLinux, CentOS, Ubuntu, Debian, and Oracle Linux. If you’re stuck on an EOL runtime that doesn’t migrate cleanly, that kind of vendor-backed patching is one of the few ways to close the CVE gap without immediately reworking the application for a newer runtime.

Note: Upgrading from PHP 5.x to PHP 8.x can require substantial code changes, especially for applications relying on removed language features, deprecated APIs, or outdated frameworks.

Security and Compliance Risks of Running EOL PHP Without Extended Support

The site loads, checkout works, logs look clean. But the risk builds quietly as new CVEs land against your version and never get fixed. “It still works” is the trap.

An EOL runtime that runs fine today is also the one with the longest list of unpatched, publicly documented vulnerabilities, which is exactly what attackers scan for.

 

Unpatched CVEs and active exploitation

Once a version is EOL, newly disclosed vulnerabilities that affect it stay unpatched by the PHP project indefinitely. Attackers can identify which versions stopped receiving fixes, and public exploits keep working against systems that never got a backported patch.

The 2026 Verizon DBIR found that exploitation of vulnerabilities is now the leading initial access vector for breaches, accounting for 31% of cases, up from 20% in the previous year’s report. It is the first time in the report’s 19-year history that vulnerability exploitation has ranked first, ahead of credential abuse and phishing. Real PHP CVEs make this concrete: see the writeup on a post-EOL PHP 7 vulnerability (CVE-2023-0568), and CVE-2024-4577, a CGI argument injection flaw rated CVSS 9.8 that landed in CISA’s Known Exploited Vulnerabilities catalog and hit Windows PHP deployments hard. The broader pattern is covered in this PHP vulnerability overview. Without a backport source, upgrading is usually the only reliable way to eliminate the underlying flaw.

Compliance failure

Security and compliance frameworks generally require organizations to identify vulnerabilities, manage risk, and apply security updates within a defined timeframe. PCI DSS sets explicit patching and vulnerability-management requirements, while HIPAA, SOC 2, and FedRAMP reach the same ground through risk analysis and control assessment. Running software that no longer receives upstream fixes makes those obligations harder to meet unless you have a documented source of backported patches and the evidence to show for it.

According to IBM’s 2026 Cost of a Data Breach Report, the global average cost of a breach rose 12% year over year to a record $4.99 million. Extended support can supply the patch records and remediation timelines that demonstrate a consistent vulnerability assessment and patching process. Regulated environments carry separate obligations alongside that – FIPS compliance for validated cryptographic modules, for instance – but on the patching question specifically, a clean record is far easier to produce when patches actually exist.

Supply chain and dependency exposure

PHP rarely runs alone. Your app pulls in Composer packages, extensions, and an OS underneath, and a vulnerability in any layer is your problem. An EOL PHP runtime often sits alongside an end-of-life OS and stale dependencies, multiplying the attack surface.

Which PHP Versions Currently Require Extended Support?

If you’re running PHP 8.1 or older and can’t upgrade promptly, you need a reliable source of backported security patches. Those versions get zero community security patches as of 2026, so newly disclosed vulnerabilities affecting them will not be fixed by the PHP project.

PHP 7.4 is the most pressing case. That version hit EOL in November 2022, so it has gone nearly four years without community patches. It’s still running in a large number of production environments because migrating off it can involve substantial dependency, compatibility, and testing work. Same story for PHP 8.0, which crossed EOL in late 2023, and PHP 8.1 joined that list at the end of 2025.

PHP 8.2 and 8.3 are in security-only mode, still getting patches but on a countdown. PHP 8.2 expires December 31, 2026, and PHP 8.3 follows a year later. Put PHP 8.2’s EOL date on your calendar: after December 31, 2026, no security patches ship from the PHP project for that branch. For a full breakdown of the risks and your options, the PHP 8.2 EOL guide covers it in detail.

PHP 8.4 and 8.5 are the two branches in active support today, and 8.4 moves to security-only at the end of 2026. Extended support is for teams that can’t move off 7.4, 8.0, or 8.1 on the timeline their auditors or risk teams demand.

PHP Extended Support vs. Upgrading: How to Choose

Upgrading is the right long-term answer. Extended support is the right short-term answer when upgrading right now would be reckless. The decision comes down to how much migration work stands between you and a supported version, and how much risk you’re carrying in the meantime.

A well-maintained application may move from PHP 8.1 to a currently supported release with limited dependency and deprecation work, though the effort depends on its frameworks, extensions, and test coverage. Moving a legacy 7.4 app with 200,000 lines of untouched code and abandoned dependencies to PHP 8.4 is a project, not an afternoon. The cost of underestimating that gap is real.

From the Trenches: A one-time upgrade doesn’t solve lifecycle risk permanently. Teams that moved from 7.4 to 8.0 years ago, called it done, and never planned the next step are now sitting on another EOL branch. “We already upgraded once” is how you end up EOL twice.

Use this to decide:

Scenario	Recommended approach
On 8.1, modern dependencies, small codebase	Upgrade now to a release in active support, ideally PHP 8.4 or 8.5
On 7.4 or 8.0, large legacy app, no test coverage	Extended support, then migrate in phases
Hard audit deadline, migration not finished	Extended support to stay compliant during migration
Third-party app the vendor hasn’t updated	Extended support until the vendor ships a fix

 

3 Top PHP Extended Support Providers

A handful of vendors backport security fixes to EOL PHP. They differ on which versions they cover, how patches are delivered, and what compliance documentation they hand you. Here are three worth comparing. The coverage lists below reflect each vendor’s published information as of August 2026; confirm current scope with the provider before you buy.

TuxCare

TuxCare’s Endless Lifecycle Support for PHP spans PHP 5.2 through 8.4 from a single repository, with ELS security patching applied to each branch as it reaches EOL – currently 5.2 through 8.1, with 8.2, 8.3, and 8.4 to follow as their EOL dates arrive. Packages are vendor-built and security-patched for Windows and major Linux distributions, regression-tested before release, and installed through your existing package manager without forcing a runtime swap or a rebuild of your application.

For teams managing multiple PHP sites through cPanel, TuxCare’s PHP ELS integrates with PHP Selector in supported cPanel environments, letting you set PHP versions on a site-by-site basis from the administrative interface without dropping to the command line.

Zend by Perforce

Zend has supported PHP commercially for years and offers long-term support runtimes for EOL versions, backed by a vendor with a long history in the PHP ecosystem. Coverage is focused: Zend currently lists PHP 7.2, 7.3, 7.4, and 8.1 under its PHP LTS offering. It’s a credible option for teams already standardized on Zend tooling or Laminas.

HeroDevs

HeroDevs delivers PHP long-term support through a partnership with Zend by Perforce, combining ZendPHP runtimes with its own Never-Ending Support subscription, SLAs, and compliance documentation. Coverage spans PHP 7.2, 7.3, 7.4, 8.0, 8.1, and 8.2, delivered as native packages across major Linux distributions and Windows.

Patch EOL PHP, Avoid Security Risks & Stay Compliant

EOL PHP doesn’t announce itself. It keeps serving traffic right up until an attacker exploits a publicly documented vulnerability that was never patched in your branch. Extended PHP support closes that gap: you stay on the runtime your application depends on, covered vulnerabilities receive backported fixes, and you migrate when it’s safe rather than when you’re forced to.

If you’re on PHP 7.4, 8.0, or 8.1 and an immediate upgrade isn’t practical, secure the existing runtime with backported patches while you plan the migration. TuxCare’s Endless Lifecycle Support (ELS) currently covers every EOL branch from 5.2 through 8.1, and is committed to extending the same coverage to 8.2, 8.3, and 8.4 as each reaches its own EOL date.

FAQs