End-of-Life PHP Versions: The Risks, How to Check Yours and How to Upgrade
PHP 8.1 and older no longer get security fixes, and 8.2 support ends December 31, 2026. Here is how to check your sites and plan a safe upgrade.
If your website or web app runs on a PHP version that has reached end of life (EOL), the PHP project no longer fixes security problems in it, even serious ones. As of late 2026, the supported branches on php.net are 8.2, 8.3, 8.4 and 8.5, and PHP 8.2 stops receiving security fixes on December 31, 2026. Anything on 8.1 or older (7.4, 7.x, 5.6) is already unsupported. The fix is straightforward: find out which version each site uses, test the site on a supported version, and switch. This guide walks you through all three steps.
What "end of life" means for PHP
The PHP project follows a predictable lifecycle that it publishes on its supported versions page:
- Active support (2 years): each new branch gets regular bug fixes and security fixes.
- Security-only support (2 more years): only critical security issues are fixed, in releases made as needed.
- End of life (after about 4 years): no more releases of any kind.
Here is where things stand according to php.net:
| Branch | Active support until | Security support until | Status (late 2026) |
|---|---|---|---|
| 8.5 | Dec 31, 2027 | Dec 31, 2029 | Active support |
| 8.4 | Dec 31, 2026 | Dec 31, 2028 | Active support |
| 8.3 | Dec 31, 2025 | Dec 31, 2027 | Security fixes only |
| 8.2 | Dec 31, 2024 | Dec 31, 2026 | Security fixes only, ending soon |
| 8.1 | — | Ended Dec 31, 2025 | End of life |
| 8.0 | — | Ended Nov 26, 2023 | End of life |
| 7.4 | — | Ended Nov 28, 2022 | End of life |
Always confirm the current dates on php.net before you plan, because the table above will age.
Why an unsupported PHP version is a business risk
An EOL version does not break the day support ends. The site keeps loading, which is exactly why many businesses leave it alone. The problem is what happens over time:
- New vulnerabilities stay open. When a flaw is found in PHP itself, the fix ships only for supported branches. Your version stays exposed indefinitely.
- Plugins and libraries move on. WordPress plugins, Laravel packages and other dependencies drop support for old PHP versions, so you stop receiving their security updates too.
- Hosting gets harder. Hosting providers and control panels gradually remove old PHP builds, which can force a rushed upgrade on someone else's schedule.
- Compliance questions. Security questionnaires, cyber insurance applications and frameworks such as PCI DSS generally expect supported, patched software on systems that handle customer data.
None of this means your site will be hacked tomorrow. It means your margin of safety shrinks every month, and the eventual upgrade gets bigger the longer you wait.
A note on Linux distribution packages
Some enterprise Linux distributions ship their own PHP packages and backport security fixes to them for the life of the distribution, even when the version number looks old. If your server uses PHP from your distribution's official repositories, check that vendor's lifecycle, not only php.net. If PHP came from a third-party repository, a control panel or a custom build, assume the php.net dates apply.
How to check which PHP version your site uses
The server and the website can run different versions, and one server can host several sites on different versions. Check each site.
In a control panel
- cPanel: open MultiPHP Manager to see the version assigned to each domain.
- Plesk: open the domain and go to PHP Settings.
- Managed hosting dashboards usually show the PHP version per site in the site's settings.
In WordPress
Go to Tools › Site Health › Info › Server. The "PHP version" line shows the version WordPress is actually running on. Site Health also warns you when the version is outdated.
From the command line
Run php -v over SSH. Be careful: the command-line PHP can differ from the version your web server uses. For the web version, create a temporary file containing <?php echo PHP_VERSION;, load it once in a browser, then delete it immediately. Never leave a phpinfo() page on a live site.
From the outside
Run curl -I https://yourdomain.com and look for an X-Powered-By: PHP/… header. If it appears, it also tells the rest of the internet your version, which is a good reason to set expose_php = Off. If it does not appear, use one of the methods above.
How to plan the upgrade
Most upgrades are uneventful when they are tested first. A practical plan for a small business looks like this.
1. Inventory
List every site and app, its current PHP version, who maintains it and what it depends on (WordPress version, theme, plugins, framework, custom code). Note anything business-critical, such as online payments, booking forms or client portals.
2. Choose the target version
Pick a branch with plenty of runway. Jumping straight to 8.4 or 8.5 usually saves you a second upgrade soon after. Check what your software supports: WordPress recommends PHP 8.3 or greater, and frameworks and major plugins publish their own compatibility notes.
3. Update the application first
Update WordPress core, themes and plugins (or framework and Composer packages) while still on the old PHP version, as far as they allow. Replace abandoned plugins that have not been updated in a long time. This step alone resolves most compatibility problems.
4. Test on a staging copy
Clone the site to a staging environment running the target PHP version. Then:
- Turn on error logging (not on-screen errors) and watch the log.
- Click through key pages and run every form, checkout and login.
- Read the official PHP migration guides for each version you skip. They list removed features and backward-incompatible changes.
- For custom code, ask your developer to run a static analysis or compatibility scan against the target version.
5. Switch production with a way back
Take a full backup of files and database, schedule the change for a quiet time, switch the PHP version, and test again right away. In most control panels, switching back is one click if something unexpected appears.
6. Put the next upgrade on the calendar
Once you are current, record the security-support end date of your new branch and plan to review it a year before. Upgrading one version at a time, on schedule, is far easier than jumping four versions under pressure.
Common upgrade problems (and what they mean)
- White screen or "critical error": usually an old plugin or theme using removed functions. The error log names the file.
- Deprecation notices in the log: not urgent, but a sign the code will break in a later version. Schedule the fix.
- Missing extensions: each PHP version has its own set of enabled extensions. Make sure the ones your site needs (for example
intl,gdorimagick,mbstring) are enabled on the new version.
Checklist
- Every site's PHP version recorded
- Sites on 8.1 or older scheduled for upgrade now
- Sites on 8.2 scheduled before December 31, 2026
- Applications, themes and plugins updated first
- Staging test completed, error log clean
- Backup taken, production switched, re-tested
- Next review date on the calendar
Need a hand?
Core Florida IT helps businesses in Miami-Dade and across South Florida inventory their websites and servers, test PHP upgrades on staging and switch production safely, with remote support nationwide. If you are not sure which version your sites run, request a free IT assessment and we will check it with you.
