Every PHP version has a defined support lifecycle. It gets two years of active support (bug fixes and security patches), then one year of security-only support (critical security fixes only), and then it reaches end of life. After that date, no patches are released. Known vulnerabilities remain unpatched. You are running a language runtime with publicly documented security holes that will never be fixed.
As of 2026, PHP 7.4 reached end of life in November 2022. PHP 8.0 reached end of life in November 2023. PHP 8.1 reached end of life in December 2025. If your site is running any of these versions, it is running on unsupported software with known, unpatched vulnerabilities.
This matters more than most people realize. PHP is not just another package on your server. It is the runtime that executes every line of your application code. Every WordPress page load, every WooCommerce checkout, every form submission, every API call – all of it runs through PHP. A vulnerability in PHP is a vulnerability in everything.
The PHP support lifecycle#
| Version | Active Support Ended | Security Support Ended | Status |
|---|---|---|---|
| PHP 7.4 | November 2021 | November 2022 | End of life |
| PHP 8.0 | November 2022 | November 2023 | End of life |
| PHP 8.1 | November 2024 | December 2025 | End of life |
| PHP 8.2 | December 2025 | December 2026 | Security fixes only |
| PHP 8.3 | December 2026 | December 2027 | Active support |
| PHP 8.4 | December 2027 | December 2028 | Active support |
| PHP 8.5 | December 2028 | December 2029 | Active support (latest) |
The dates shift by a year with each new release. The pattern is consistent: every PHP version gets roughly three years of total support before it is abandoned.
What "end of life" actually means#
When PHP 7.4 reached end of life, the PHP development team stopped releasing patches for it. Not just feature updates – security patches. If a critical remote code execution vulnerability is found in PHP 7.4 tomorrow, no fix will be released. The vulnerability will be documented publicly (assigned a CVE number, added to vulnerability databases), and every attacker in the world will know about it, but no patch will come.
This is not theoretical. PHP has had serious vulnerabilities disclosed after versions reached end of life. Buffer overflows, type confusion bugs, serialization flaws – the kinds of vulnerabilities that allow an attacker to execute arbitrary code on your server. On supported versions, these get patched within days. On end-of-life versions, they stay open permanently.
The distinction between “active support” and “security-only support” matters too. During the security-only phase, only critical security issues are fixed. Bugs that cause crashes, memory leaks, or incorrect behavior are not fixed. You are running increasingly fragile software that only gets attention for the most severe security problems.
The cascading effect on WordPress#
Running an end-of-life PHP version does not just affect PHP. It creates a chain of problems that compounds over time, especially on WordPress sites.
WordPress drops support for old PHP versions
WordPress itself eventually drops support for older PHP versions. When it does, you can no longer update WordPress core. You are stuck on an older WordPress version that also stops receiving security patches. Now you have two layers of unsupported software – the PHP runtime and the CMS running on it.
WordPress has historically been slow to drop PHP version requirements (it supported PHP 5.6 for years after its end of life), but the trend is accelerating. Running an end-of-life PHP version means you are on a countdown to being unable to update WordPress.
Plugins require newer PHP versions
Plugin developers adopt newer PHP features and eventually set minimum PHP version requirements. A plugin that requires PHP 8.1 will not run on PHP 7.4. When a critical security update for a plugin requires a PHP version you cannot run, you have two choices: leave the vulnerable plugin in place, or remove it entirely. Neither is good.
This is where the cascading effect becomes visible. You cannot update PHP because an old plugin breaks on newer versions. You cannot update the plugin because the new version requires a newer PHP. You cannot replace the plugin because the replacement also requires newer PHP. Everything is stuck.
Themes break on newer PHP versions
Themes that were written for PHP 7.x may use deprecated or removed functions. The
each()
function was removed in PHP 8.0. Dynamic properties were deprecated in PHP 8.2 and produce warnings. The
${var}
string interpolation syntax was deprecated.
utf8_encode()
and
utf8_decode()
were removed in PHP 8.2.
A theme that worked perfectly on PHP 7.4 may produce warnings, errors, or completely break on PHP 8.x. If the theme is no longer maintained (and many themes are abandoned by their developers), there is no updated version to install. You are stuck choosing between a broken theme on a supported PHP version or a working theme on an unsupported one.
The dependency chain freezes
The result is a frozen stack. PHP cannot be updated because the theme or a critical plugin breaks. Plugins cannot be updated because they require newer PHP. WordPress cannot be updated because the plugins are incompatible. Security patches cannot be applied at any level. The entire site becomes a time capsule of software from 2021, running in 2026, with every vulnerability discovered in the intervening years left unpatched.
This is not a rare scenario. It is one of the most common situations on long-running WordPress sites that have not had ongoing maintenance.
Security risks#
Known PHP vulnerabilities go unpatched
PHP CVEs are public. When a vulnerability is found and patched in PHP 8.5, the details of the vulnerability are published. Anyone can read the commit that fixed it, understand the bug, and write an exploit. If you are running an end-of-life version that has the same vulnerability, the exploit works on your server and no patch will ever come.
Attackers specifically scan for servers running outdated PHP versions. The version is often exposed in HTTP response headers (the
X-Powered-By
header) unless explicitly disabled. A server advertising
X-Powered-By: PHP/7.4.33
is telling every scanner that it is running software with known, unpatched vulnerabilities.
WordPress security plugins cannot compensate
A WordPress security plugin like Wordfence operates at the application level. It can block SQL injection attempts, detect malware in PHP files, and limit login attempts. But it cannot patch a vulnerability in the PHP runtime itself. If the vulnerability is in how PHP handles certain types of input, parses certain data formats, or manages memory, no amount of application-level filtering can fix it. The vulnerable code runs before any WordPress plugin has a chance to intervene.
A web application firewall like ModSecurity provides some defense by blocking known attack patterns at the web server level, but it cannot cover every possible exploitation path for every PHP vulnerability.
The attack surface multiplies
An end-of-life PHP version combined with outdated WordPress core, outdated plugins, and an outdated theme creates a multiplicative attack surface. Each layer has its own vulnerabilities, and the combination creates exploitation paths that would not exist if any single layer were current.
For example, a PHP deserialization vulnerability might not be directly exploitable on its own – but combined with a WordPress plugin that passes user input to
unserialize()
, it becomes a complete remote code execution chain. On a current PHP version, the deserialization bug is patched. On an end-of-life version, the chain works.
This is how sites get compromised by malware. The attackers are not finding brilliant zero-day exploits. They are combining known vulnerabilities in outdated software layers, each of which has a documented fix that was never applied.
Performance costs#
End-of-life PHP is not just a security problem. Each major PHP version brings measurable performance improvements.
PHP 8.0 introduced the JIT compiler. PHP 8.1 brought fibers and enum types. PHP 8.2 added readonly classes. PHP 8.3 brought typed class constants. PHP 8.4 added property hooks and asymmetric visibility. Each release also includes internal optimizations to the engine itself.
Benchmarks consistently show 10-30% performance improvements between major PHP versions for WordPress workloads. A site running PHP 7.4 is measurably slower than the same site on PHP 8.5 with identical code, plugins, and content. The same hardware serves fewer concurrent visitors, pages load slower, and the server reaches capacity sooner.
On a hosting platform, this translates directly to resource consumption. A site on PHP 7.4 uses more CPU time per request than the same site on PHP 8.5. You are paying for the performance penalty of running outdated software.
How to check your PHP version#
If you are not sure which PHP version your site is running, check it from the command line, WordPress admin, or a phpinfo file. On WordPress, go to Tools > Site Health > Info > Server to see the current version.
How to upgrade#
Preparation
- Check plugin and theme compatibility. Before changing the PHP version, verify that your plugins and themes support the target version. Check the plugin pages on wordpress.org – most list their PHP requirements. Run a compatibility checker plugin like PHP Compatibility Checker to scan your theme and plugin files for known incompatibilities.
- Take a full backup. Files and database. If the upgrade breaks something, you need to be able to roll back immediately.
- Test in a staging environment. If your hosting provides staging, clone your site and test the PHP upgrade there first. This catches problems before they affect your live site.
The upgrade
If your plugins and themes are compatible with the target PHP version, the upgrade itself is straightforward. Most hosting control panels provide a PHP version selector. On Hostney, the PHP version is managed through the PHP Manager in the control panel – select the version, save, and the change takes effect immediately.
If you manage your own server, install the new PHP version alongside the old one and switch your site’s PHP-FPM pool to the new version.
When plugins or themes are not compatible
This is where the real work is. If a plugin breaks on the newer PHP version:
- Check for an updated version. The plugin developer may have already released a compatible update.
- Check if the plugin is still maintained. If the last update was two or more years ago, the plugin is likely abandoned. Find a replacement.
- Check the specific error. Some incompatibilities are minor (deprecated function warnings) and the plugin still works. Others are fatal (removed functions, changed behavior). Deprecated warnings should be addressed but are not urgent blockers.
If your theme breaks:
- Check for a theme update. Contact the theme developer or check for an updated version.
- If the theme is abandoned, you have a harder choice. You can fix the incompatibilities yourself (or hire a developer to fix them), or you can migrate to a maintained theme. Migration is more work upfront but eliminates the ongoing risk of running abandoned code.
The worst option is doing nothing. Staying on an end-of-life PHP version because one plugin or theme is incompatible means accepting unpatched security vulnerabilities across your entire stack to avoid fixing or replacing a single component.
The version jump problem
If you have been on PHP 7.4 for years and need to get to PHP 8.5, do not jump directly. Each major version introduces changes that can break code. Upgrade one version at a time: 7.4 to 8.0, test, fix issues, then 8.0 to 8.1, test, fix, and so on. This isolates which version change causes which problem and makes debugging manageable.
Common objections#
“My site works fine on the old version”
It does, until it does not. “Works fine” means “has not been exploited yet.” The vulnerabilities exist whether or not they have been used against your specific site. Running end-of-life PHP is like driving without insurance – everything is fine until it is not, and then the cost is catastrophic.
“Upgrading will break my site”
It might. That is what staging environments and backups are for. A controlled upgrade with a rollback plan is infinitely better than a forced upgrade after a security incident, when your site is already compromised and you are rebuilding under pressure.
“My hosting provider still offers PHP 7.4”
Availability is not endorsement. Hosting providers keep old PHP versions available because removing them would break customer sites. That does not mean those versions are safe or recommended. The provider making it available does not make the provider responsible for the security consequences of using it.
“I will upgrade when I rebuild the site”
This is the most common and most dangerous objection. The rebuild is always six months away. Meanwhile, the site runs unpatched software accumulating vulnerabilities. If the site gets compromised before the rebuild happens, you are rebuilding from a hacked state instead of a clean one.
End-of-life PHP on Hostney#
On Hostney, PHP versions are managed through the PHP Manager in the control panel. Multiple PHP versions are available, and switching between them takes effect immediately. The platform supports current, actively maintained PHP versions and provides tools to test compatibility before switching.
If you are running an older PHP version and are unsure about upgrading, the support team can help identify compatibility issues and plan the migration path. The goal is to keep every site on a supported PHP version with active security patches – because no amount of server-level protection fully compensates for a vulnerable runtime.
Server-level protections – bot detection, ModSecurity, container isolation, and real-time malware detection – reduce the risk and limit the blast radius of any compromise. But they are a safety net, not a substitute for running supported software. The most effective security measure is also the simplest: keep PHP current.