PHP Version Maintenance in 2026: EOL Dates, Security Risks, and What to Do Next

Every few years the PHP discourse cycles back around. Someone publishes a “PHP is dead” post, developers quote it on LinkedIn, and business owners start wondering whether their site is built on a liability. The runtime debate follows the same pattern: FrankenPHP versus PHP-FPM versus Octane versus RoadRunner, argued with conviction by people who have not yet confirmed what version their production environment is actually running.

The runtime question matters. But the maintenance question matters more. Here is where things actually stand in 2026, and what a proper PHP maintenance plan looks like for Australian businesses running PHP-based sites.

PHP Is Fine. The Conversation About It Usually Is Not.

PHP powers 70.6% of websites with a known server-side language, according to W3Techs (July 2026). The next closest alternative is Ruby at 6.7%. The gap is not a recent development and it is not closing. PHP’s share has been remarkably stable for years despite multiple hype cycles built around alternatives.

WordPress alone accounts for over 43% of all websites on the internet. Add Drupal, Joomla, Magento, and the enormous Laravel and Symfony application layer, and the picture becomes clear: PHP is not a legacy technology on the way out. It is the default infrastructure for a large portion of the web, running modern PHP 8.x with JIT compilation, typed properties, named arguments, and performance characteristics that would surprise anyone whose mental model of PHP was formed in 2010.

The “PHP is dead” narrative has always leaned on developer sentiment rather than production data. Once you check the market share numbers, the narrative does not hold. What does hold, and what is worth paying close attention to right now, is the version question.

Where Things Stand Right Now (August 2026)

PHP releases a new minor version every November. Each version follows a predictable support lifecycle: two years of active support, then one to two years of security-only support, then end of life. Once a version reaches end of life, no more patches ship for it. Any CVE discovered after that date is an unpatched vulnerability in your production environment. The full release schedule is published at php.net.

URL Structures and Redirects

Redesigns restructure URLs without anyone meaning to. Designers build a new sitemap around how the site looks and reads on screen, organised by visual hierarchy and user flow, not around what Google has already indexed and ranked over years of accumulated signals.

Pages get renamed, folders get reorganised for clarity, and categories get merged or split to match the new navigation. Unless someone maps every old URL to its replacement before launch, Google follows the ones it trusted straight into a 404, with no way of knowing the page still exists somewhere on the new site.

This is a design decision as well as a technical one. Designers make it at the information architecture stage, long before a developer ever touches a redirect rule.

PHP 8.2 reaches end of life on December 31, 2026. If you are running PHP 8.2, you have roughly four months to plan and execute an upgrade before the PHP project stops shipping security patches for it. Given that enterprise upgrade cycles rarely move quickly, now is the time to start that conversation.

What Running PHP Past EOL Actually Exposes You To

End of life does not mean the software stops working. Your site keeps running. That is part of the problem. The risks accumulate invisibly, and most business owners do not see them until something goes wrong.

Security: vulnerabilities that will never be patched

PHP sees roughly 15 new CVEs disclosed per year, according to eolrisk.com. Every one of those CVEs is patched in supported versions within the PHP release cycle. For EOL versions, they are never patched. The vulnerability is documented publicly, available to anyone who wants to find it, and permanent.

For PHP 7.4, which reached end of life in November 2022, that means nearly four years of accumulated, unpatched CVEs as of August 2026. HeroDevs confirms that PHP 7.4 has not received any security patches for over three years and is vulnerable to multiple actively exploited CVEs, including CVE-2024-4577 (CVSS 9.8). Every security researcher who finds a new PHP flaw, every automated scanner that maps the attack surface, every threat actor looking for entry points: they all have access to a growing list of vulnerabilities in PHP 7.4 that will never be fixed.

CVE-2024-4577, CVSS score 9.8 (critical). This vulnerability allows remote code execution on Windows-based PHP-CGI installations. Disclosed June 2024 and patched for all supported PHP versions immediately. PHP 7.4 received no patch. GreyNoise detected 1,089 unique IP addresses actively exploiting CVE-2024-4577 in January 2025 alone, across the US, UK, Singapore, Indonesia, Spain, and India. It was used as an entry vector by the TellYourPass ransomware campaign. PHP 7.4 remains permanently vulnerable to this attack. Linux-based installations are not affected by this specific CVE, but PHP 7.4 carries dozens of other unpatched CVEs that do apply.

CVE-2024-4577 is not an isolated case. It is an example of the category of risk. Any CVE affecting PHP that is discovered after your version reaches EOL applies to your site indefinitely. Attackers specifically scan the web for outdated PHP versions and target the sites running them. Running EOL PHP is not a theoretical risk. It is a publicly advertised attack surface.

Performance: a gap that compounds across versions

Security is the primary argument for staying current on PHP. Performance is a secondary one that is often overlooked because the gap between adjacent versions is modest. The gap between PHP 7.4 and current PHP 8.x is not modest.

WordPress running on PHP 8.x executes 20 to 40% faster than on PHP 7.4 with no code changes required, per MassiveGRID benchmarks (March 2026). PHP 8.0 introduced the JIT (Just-In-Time) compiler, delivering up to 30% faster execution over PHP 7.4 for typical web workloads. PHP 8.5 with JIT enabled produces a 61% performance improvement on CPU-intensive tasks versus PHP 7.4, per PHPBenchLab (April 2026).

For most WordPress and WooCommerce sites, the performance difference translates directly to page load times, server capacity, and hosting cost. A site on PHP 7.4 is working noticeably harder to serve each page than it would on PHP 8.4. That gap grows with every PHP release it misses.

Hosting, compliance, and forced migrations

Hosting providers progressively phase out EOL PHP versions. Some remove them from control panel options entirely. Others flag them in security audits or remove them from support eligibility. A site that has been quietly running on PHP 7.4 for years may suddenly face a forced migration when the host drops support, without any of the planning or staging environment work that a managed upgrade would involve.

For businesses operating under compliance frameworks such as PCI DSS, SOC 2, or HIPAA, running software with known unpatched CVEs is not just a technical risk. It is a compliance failure. An audit that identifies EOL PHP with publicly disclosed vulnerabilities is a finding that requires remediation, often urgently.

The Real Risk Sitting Inside Most PHP Sites

Most businesses do not know what PHP version their site is running. They know they have a website. They know it works. They have a developer or an agency who built it and occasionally maintains it. Whether that developer has a plan for PHP version currency is a different question entirely.

PHP 7.4 reached end of life in November 2022. As of August 2026, it is nearly four years past EOL. Any security vulnerability discovered in those four years is permanently unpatched for every site still running PHP 7.4. W3Techs data shows 29.7% of PHP-using sites are still running PHP 7.x.

That is not a runtime problem. No choice between FrankenPHP and PHP-FPM changes it. The problem is the absence of a maintenance plan that treats PHP version currency as a routine operational task rather than an optional upgrade.

This is exactly where the “PHP is dead” narrative does real harm. When PHP’s stability gets mistaken for stagnation, version maintenance gets deprioritised. Why upgrade a language that is not going anywhere? Because the version you are on is going somewhere: to end of life, on a predictable schedule published years in advance.

My Developer Says Our PHP Version Is Fine

This is the most common response when the question gets raised internally. And it is almost always incomplete. Not because developers are being dishonest, but because “it is working” is not the same as “it is secure”. A site can run perfectly well on PHP 7.4 right up until the moment someone exploits one of the unpatched CVEs sitting on it.

When a developer says your PHP version is fine, they typically mean: the application is running, there are no errors, no customers are complaining. None of those things say anything about the CVE exposure on your server or when your current version hits EOL.

The right response is not to argue. It is to ask five specific questions:

1. Which PHP version are we running right now?
   • If the answer requires looking it up, that is the first signal. This should be known and documented.
2. When does that version reach end of life?
   • If the answer is “not sure” or “a while away”, ask for the specific date. EOL dates are published years in advance at php.net and do not change.
3. When did you last audit our Composer dependencies against the next PHP version?
   • A PHP upgrade without a dependency audit is how incompatibility issues appear in production. This should be a documented step, not an assumption.
4. Do we have a staging environment to test the upgrade safely?
   • A PHP version change should never be tested in production. If there is no staging environment, building one is part of the upgrade work.
5. What is the plan when our current version reaches EOL?
   • This should have a specific answer with a timeline. “We will deal with it when it comes up” is not a plan. It is how emergency migrations happen.

“A running site is not the same as a maintained site. The difference shows up in security audits, insurance claims, and compliance reviews.”

If the answers include “I am not sure” or “we will deal with it when it comes up” on more than one of those questions, there is no maintenance plan in place. A running site is not the same as a maintained site. The difference shows up in security audits, insurance claims, hosting migrations, and compliance reviews, usually at the least convenient moment.

If you want an independent view on your current PHP environment, version status, and upgrade pathway, our web development team can review it without any commitment to proceed. We will tell you what we find, including if there is nothing that needs to change right now.

What a PHP Maintenance Plan Actually Looks Like

A PHP maintenance plan is a set of questions with documented answers and a responsible owner for each. The businesses that stay out of trouble work through these questions before a version hits EOL, not after.

What PHP version are you running right now?

Check your hosting control panel or ask your developer. If it is 8.1 or below, you are already on an EOL version. If it is 8.2, you have until December 31, 2026.

When does your current version reach end of life?

The schedule is published at php.net. Mark the EOL date in your calendar and start your upgrade plan at least six months before it.

Are your dependencies compatible with the next version?

Composer packages and major frameworks publish compatibility requirements. A dependency audit should happen before any PHP upgrade, not during it.

Does your hosting support the version you need?

Shared hosting often lags behind PHP releases. Confirm your host supports PHP 8.3 or 8.4 before planning an upgrade.

Do you have a staging environment for upgrade testing?

A PHP version change can surface deprecated function calls and plugin conflicts. Testing on a staging copy before touching production is not optional

Who is responsible and when do they review this?

A maintenance plan without an owner is not a plan. Someone should review PHP version status at least once a year and confirm the upgrade pathway before the next EOL date.

A well-maintained codebase with current dependencies can often be tested and upgraded in a matter of days. A neglected codebase with outdated packages, deprecated function calls, and no test coverage can take weeks or months. The upgrade effort compounds with every deferred maintenance cycle.

If your team handles enterprise PHP development in-house, build version review into your release cycle. If you rely on an agency or external developer, ask directly: what is the plan when our current PHP version reaches end of life?

Runtime Choice: Real, but Secondary

The runtime conversation is worth having once the maintenance plan is sorted. PHP-FPM, FrankenPHP, Laravel Octane, and RoadRunner each have legitimate performance advantages depending on your stack and workload. The differences are real. For high-traffic Laravel applications, the right runtime configuration can meaningfully reduce response times and server resource consumption.

But runtime choice is a performance optimisation question. Version maintenance is a security and stability question. Sort the version first. Then read our PHP runtime comparison to understand which runtime makes sense for your specific application architecture.

FAQs

Not Sure What PHP Version You Are On?

Our web development team can audit your current PHP environment, identify version and dependency risks, and put a clear upgrade plan in place. No lock-in contracts. Contact us and we can work. outa plan for you today.