Every so often a customer forwards us a security scan, or a message from a plugin, warning that their site is running an end of life version of PHP and is therefore insecure. It is a reasonable thing to be worried about, and the warning is usually well intentioned. It is also, on our servers, usually wrong. This article explains why, and more usefully, explains what does decide whether an older PHP version is a problem for you.
The PHP project maintains each major version on a published schedule. A version gets roughly two years of active support, during which bugs and security issues are both fixed, then roughly a further year of security fixes only. After that the PHP project itself stops publishing fixes, and the version is described as end of life.
That is a statement about the PHP project, not about your server. It says that upstream has stopped work. It does not say that the software on your server is unpatched, because the PHP project is not the only party that publishes fixes.
Our servers run PHP builds from CloudLinux, which continues to backport security fixes into older versions long after the PHP project has moved on. When a vulnerability is found in a component that an older version shares with a current one, the fix is applied and a new build of the older version is published. The version number stays the same, because it has to for compatibility, but the code is not the code that shipped years ago.
This is the same model as the long term support Linux distributions, and it is the reason a scanner that decides “insecure” purely from a version number is unreliable. The scanner reads the number, compares it to the PHP project’s schedule, and reports accordingly. It has no way of knowing what has been backported.
None of the above means old PHP is a good place to stay. There are three genuine reasons to move forward, and none of them is the version number on its own.
The backporting eventually stops too. Extended support is long, but it is not infinite. There is a date after which nobody is publishing fixes for your version, and being on it after that date is a real exposure rather than a theoretical one.
Your software will stop supporting it. This tends to bite before the security question does. WordPress, WooCommerce, CubeCart and their plugin ecosystems all raise their minimum PHP version over time. Sooner or later an update you want, possibly a security update, requires a newer PHP than you are running, and at that point the PHP version is blocking you from patching something else.
Newer PHP is substantially faster. This is not a marginal difference. Each recent major version has brought real performance improvements, and for a database-driven shop or a content site with a lot of plugins, that shows up directly in page load times and in how much traffic a given plan can absorb.
Because it breaks sites, and it breaks them in a way that is not always obvious on the day.
PHP removes deprecated behaviour at major versions. Code written for an older version can continue to run for years and then fail on a specific page, or in a specific circumstance, once the version changes. We have seen a site look perfectly healthy after an upgrade and then fail a fortnight later, on a page nobody had visited in the meantime. That is why the version is a per-account setting rather than something we change across a server on a schedule.
The order matters, and it is the opposite of what people usually try.
The one situation that genuinely constrains you is commercial software that is licensed to a specific version and does not support anything newer. In that case the PHP version is fixed by the application, and the honest answer is that the application has to be dealt with first.
If you would like to know which PHP version your account is on, or want a staging copy to test an upgrade against, open a ticket and we will set it up.