What PHP End of Maintenance Means
PHP end of maintenance, or End of Life, means that release will no longer receive official security updates. By November 2026, 7.4, 8.0, and 8.1 have already ended, and 8.2 also stops on 31 December 2026. If a site remains on these releases, security issues found later will not get an official patch.
PHP can be compared to a building’s load-bearing frame, with pages and features built on top of it. The end of maintenance is like the contractor saying they will no longer send anyone to inspect or repair it. The building can still be occupied, but later structural defects have to be handled on your own.
Owners often ask why they should upgrade a site that is not broken. That question sounds reasonable most of the time, until the day a vulnerability is actually disclosed.
Lessons from the October 2026 PHP2Shell Case
On 21 October 2026, the PHP project urgently addressed two flaws grouped as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), both scored CVSS 9.2. The defect sits in the stage that parses incoming requests, so it can be abused before the site’s own code runs. An attacker does not need an account, and the site’s existing login and form checks cannot block it.
Three points from this incident are worth remembering:
- Official patched builds were issued only for 8.2 and above: 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Releases 7.4, 8.0, and 8.1 received source-level fixes only, and then had to wait for a host or operating-system vendor to repackage them. Some respond slowly; others never do.
- Intrusion attempts began before the public notice: overseas cloud services saw attack activity four days before the announcement, and automated scanning rose quickly within days afterward. Scans cover the whole internet and do not skip companies by size.
- A host changing PHP does not mean the site is out of danger: many sites stay on an old release because the application breaks on a newer one, so the host is unwilling to change it.
Put plainly, the risk of ended maintenance is hard to see day to day. The loss shows up all at once when the next flaw like PHP2Shell appears.
How Long Each Release Stays Supported
A current PHP release usually gets about two years of general maintenance, covering both bugs and security issues, then about two more years of security updates only, roughly four years in total. The table below shows where each release stands:
| Release | Security support ends | Status in November 2026 | Suggested direction |
|---|---|---|---|
| 7.4 | support ends">2022-11-28 | ✗ Ended four years ago | Upgrade soon; the framework usually must move too |
| 8.0 | support ends">2023-11-26 | ✗ Maintenance has ended | Arrange an upgrade early |
| 8.1 | support ends">2025-12-31 | ✗ Maintenance has ended | Move up promptly |
| 8.2 | support ends">2026-12-31 | ! Less than two months left | Put it on the schedule before year-end |
| 8.3 | support ends">2027-12-31 | ✓ Security updates only | Still usable; plan again next year |
| 8.4 | support ends">2028-12-31 | ✓ Still maintained | Preferred release for new work and upgrades |
| 8.5 | support ends">2029-12-31 | ✓ Still maintained | Preferred release for new work and upgrades |
The steadier choice is to move in one step to 8.4 or 8.5. Stopping at 8.3 often means another full test cycle by the end of next year, so the same verification is paid for twice.
How to Find the PHP Version in Use
A common situation is that the person in charge does not know which release the site runs, and the original vendor can no longer be reached. There are roughly three ways to check:
- Ask the maintainer or the host: request the PHP release the site is actually running. One server may have several releases installed, and what the control panel shows is not always the one serving the site.
- Open the hosting admin panel: interfaces such as cPanel and Plesk usually have a PHP version or PHP settings page.
- Inspect the response headers: some sites include the version number in the response, but most hosts hide it for safety. Finding nothing is normal.
Also confirm which content system or application framework the site uses, and that framework’s own version. Frameworks have separate maintenance windows, and older ones often cannot run with a newer PHP, so the two usually need to be upgraded together.
Stay, Buy Extended Care, or Upgrade
Once you confirm the site is on a release whose maintenance has ended, there are essentially three paths:
| Comparison | Keep the old release | Pay for extended security care | Move to 8.4 or newer |
|---|---|---|---|
| Security fixes available | ✗ None | security care">! Depends on the vendor, often delayed | ✓ Official fixes |
| Short-term cost | ✓ No spend now | security care">! A yearly fee | ! A one-time upgrade cost |
| Long-term cost | ✗ Recovery cost after an incident is hard to estimate | security care">✗ Yearly fees, problem remains | ✓ Later work is routine minor updates |
| New plugins and features | ✗ More new packages drop old releases | security care">✗ Still unusable | ✓ Available |
| Will the host keep offering it | ✗ Many hosts force old releases off | security care">! Confirm the host will cooperate | ✓ Yes |
| When it fits | The site will shut down or be rebuilt | security care">A rebuild within three to six months needs a bridge | The site will be used for more than two years |
The decision can be direct: if the site will be used for more than two more years, schedule an upgrade; if a full rebuild is due within six months, keep the budget for that rebuild, and ask the host to apply temporary protection during the gap. The weakest choice is to leave it until something goes wrong. Cleaning up and restoring a compromised site usually costs more, and causes more downtime, than an upgrade.
What Must Change in a PHP Upgrade
Many people assume a PHP upgrade is only a button at the host. The button exists, but on an older site pressing it often produces a blank screen, an admin area that will not sign in, or errors at checkout. That happens because several layers have to be adjusted together:
- The site’s own code: newer PHP removes some older syntax, and the earlier a site was written, the more must change. Crossing from 7.4 to 8.4 spans several releases, so the workload is very different from moving from 8.2 to 8.4.
- Plugins and packages: every add-on and library must be replaced with a build that supports the new release. Plugins that are no longer updated need a substitute.
- Payments and e-invoicing: packages from payment and e-invoice providers usually need updating as well. In a test environment, complete one real payment and issue one invoice, then confirm that payment status and notification mail are both correct.
- Database queries: a few older query styles fail under the newer connection methods.
Duration depends on the size of the site. Membership, a cart, payments, or multiple languages mean more items to verify and a longer schedule. Sites still on 8.2 should ask a vendor to estimate the timeline now, so there is a chance to finish before year-end.
Questions to Check Before and After
When you commission an upgrade, use the table below as the questions to ask. A specific answer means the work has been planned; a vague answer means the risk stays with you:
| Question to ask | A reassuring answer | An answer to watch |
|---|---|---|
| Will there be a backup before the work? | Code and database are fully backed up and can be restored | “The host probably has a backup” |
| Where will the upgrade happen? | Finish it on a test site, then switch production after acceptance | “Change production directly; it is faster” |
| Which features will be verified? | A list based on real features, including forms, members, cart, and each payment method | “It is fine if the homepage opens” |
| How will payments be confirmed? | One test order per payment method, checking status and notification mail | Payments are not mentioned at all |
| What if problems appear afterward? | A clear warranty period and response time | “We can discuss it later” |
| Will the framework and plugins move too? | Yes, with a note on which plugins must be replaced | “Only the PHP release will change” |
During the first week after the upgrade, watch error logs, whether form notification mail still goes out, and order and payment status. It also helps to include the PHP release in yearly site maintenance and schedule the next upgrade a year before support ends, instead of waiting for a vulnerability notice each time. Maintenance budget can be estimated from the yearly care a custom site actually needs.
Upgrade Before the Next Flaw Appears
Few people find a PHP upgrade interesting, yet it is one of the rare website-security tasks that lowers risk once it is done. Keep these three points in mind:
- Check the version before deciding whether to spend: risk can be judged only after you know the PHP and framework releases the site and server actually use.
- If it will be used for two more years, upgrade, and go straight to 8.4 or newer: that avoids repeating the same test cycle next year.
- The upgrade must be finished on a test site first: back up, accept each item, then switch over, while the live site keeps operating during the work.
If the current state is still unclear, start with a security review of the site, or ask the current maintainer to check the version and the scope of changes required.
