What Happens If Your Website Runs an End of Life PHP Version

A website running an end of life PHP version keeps working, but it stops receiving security fixes from the PHP project and every flaw found after that date stays open. When boards and IT leads ask about end of life PHP support for UK organisations, the risk being described is not a sudden failure. It is exposure that grows a little more every month the server is left alone.

PHP is used by around 70% of websites whose server side language is known, according to W3Techs. A large share of those run WordPress. Plenty of them are still on PHP 8.1, 8.0, 7.4 or something older. The consequences fall into four areas, which are security, compatibility, hosting and compliance. Each one has a practical answer. The post on how much of the internet runs on PHP looks at those usage figures in more detail.

Which PHP Versions Are End of Life

Every PHP branch older than 8.2 is end of life, according to the official list of unsupported branches on php.net. PHP 7.4 reached end of life on 28 November 2022, PHP 8.0 on 26 November 2023 and PHP 8.1 on 31 December 2025. Each branch now gets two years of active support followed by two years of security fixes only, as the supported versions page sets out.

PHP 8.2 is the next branch to drop off. The PHP 8.2 end of life deadline is now less than three months away. PHP 8.3 follows a year later, which is why planning for PHP 8.3 end of life belongs in next year’s budget rather than the year after. For a plain explanation of how the branches relate to each other, see PHP versions explained.

What Changes When PHP Reaches End of Life

Nothing visible changes on the day a PHP branch reaches end of life, which is why it is so easy to ignore. Pages still load and forms still send. What stops is the flow of releases from the PHP project, so any new vulnerability in the language is fixed in the supported branches and left open in the rest. The guide to what PHP is and what it is used for covers the jobs it does behind the scenes.

A June 2024 alert from NHS England Digital shows how this plays out. It covered CVE-2024-4577, a flaw rated 9.8 out of 10 for severity that affected PHP running on Windows servers in a particular setup. Fixes were released for PHP 8.1, 8.2 and 8.3, while the alert confirmed that end of life versions were also affected and gave no fixed release for them.

Once a fix is public, it also tells attackers exactly what to look for on servers that have not been updated. Automated tools scan the internet for known weaknesses around the clock. An unpatched PHP version sits alongside outdated plugins and weak passwords as one of the easier ways in. The wider steps for preventing a WordPress website being hacked all assume the server software underneath is still supported.

Plugin and Theme Compatibility Drift

Older PHP versions gradually lose access to new plugin and theme releases, because developers stop testing against them and raise their minimum requirements. Plugins in the WordPress directory declare the oldest PHP version they work with in a “Requires PHP” field, as the WordPress plugin handbook explains. When a plugin raises that minimum above the version a server runs, WordPress will not install the update.

The result is a website frozen on older plugin versions. Those older versions carry their own security flaws. WordPress itself still runs on PHP 7.4 or newer, but its hosting requirements recommend PHP 8.3 or greater and warn that end of life versions may leave a website open to vulnerabilities. The way these pieces fit together is covered in more detail in the guide to WordPress and PHP compatibility.

Custom code drifts in the same way. A bespoke theme or integration written for PHP 7.4 can carry functions that were deprecated in later branches, so the gap between the code and a supported version widens each year it is left. The longer the wait, the bigger the eventual upgrade. Some owners use the moment to ask whether PHP is still relevant for business websites at all.

Hosts Withdraw Old Versions and Force Upgrades

Hosting providers remove end of life PHP versions from their platforms. They do it on their own timetable rather than the website owner’s. Server operating systems ship with particular PHP versions. When the operating system itself reaches the end of its support the host has to move everything onto newer software.

The danger is a forced upgrade with short notice and no testing. A website that jumps from PHP 7.4 to PHP 8.3 overnight can hit fatal errors from removed functions or plugins that were never updated. The first sign is a broken website on a Monday morning. Choosing the timing yourself, with a test copy, costs far less disruption than having it chosen for you.

What Cyber Essentials Says About Unsupported Software

Cyber Essentials requires all software on in scope devices to be licensed and supported. Software that becomes unsupported has to be removed or taken out of scope, as set out in the current Cyber Essentials Requirements for IT Infrastructure published by the NCSC.

The certification body IASME explains that updates must be applied within 14 days of release where they fix vulnerabilities the vendor calls critical or high risk, or that score 7 or above on CVSS v3, the common scale used to rate how severe a vulnerability is. A PHP branch that no longer receives fixes cannot meet that deadline, because there is no update to apply.

Servers and cloud services are listed as in scope. Publicly available commercial web applications are in scope by default, while bespoke components developed in house are not. A cloud server the organisation manages that still runs PHP 7.4 is therefore likely to be raised at assessment. For organisations that rely on the certificate to win contracts, an old PHP version on a forgotten server is a real commercial risk as well as a technical one.

UK data protection law adds a second layer. Article 32 of the UK GDPR requires appropriate technical measures to protect personal data. A website that collects enquiries or patient details on software with no security fixes is hard to defend after a breach. The NCSC’s vulnerability management guidance treats updating as business as usual and recognises that organisations hold back because they fear updates will break things, which is a problem solved by testing rather than by waiting.

Your Options If You Cannot Upgrade Yet

There are three realistic options for a website on an end of life PHP version: upgrade, buy commercial extended support or run on a Linux distribution that backports security fixes. Each answers a different problem and they are not equal.

Commercial PHP extended support is a legitimate route for websites that cannot move yet. It keeps security patches coming for a branch the PHP project has stopped maintaining. TuxCare Endless Lifecycle Support supplies security patches for end of life branches from PHP 5.2 up to PHP 7.4. Zend PHP long term support covers PHP 7.2, 7.3, 7.4 and 8.1. Zend states that PHP 8.0 is not part of that service, so websites on 8.0 have fewer choices than those on 7.4.

Extended support can also count as supported software for Cyber Essentials. The NCSC requirements define it as software a vendor has committed to fix. The vendor does not need to have written the software in the first place, provided it can create fixes and publishes the date that support ends. Confirm the position with the certification body before relying on it. Treat the contract as a bridge to an upgrade rather than a permanent home.

Why the Version Number Can Mislead

A PHP version number on its own does not prove whether a server is patched, because some vendors copy security fixes into older version numbers instead of moving to a new release. Copying fixes into older releases in this way is known as backporting. The Debian security FAQ explains that Debian applies fixes to the version shipped with a stable release, so a package can look old and still be patched.

The effect works in both directions. Red Hat notes that scanners comparing version strings will flag patched systems as vulnerable, which creates false alarms in security reports. The reverse is more worrying, because a host can reassure a client that PHP 7.4 is “patched” when nobody has checked what that means.

A clear answer to those three questions separates a managed bridge from wishful thinking. If the host cannot name a vendor or an end date, the server should be treated as unsupported.

Planning the Move to a Supported Version

The dependable answer to PHP end of life is a tested upgrade to PHP 8.3 or PHP 8.4, both of which have security support running into 2027 and 2028. PHP 8.6 is scheduled for general release on 19 November 2026, according to the PHP 8.6 release schedule, so most organisations will be better served by a stable branch now and a planned move later. The guide to what is changing in PHP 8.6 covers the new release.

The work itself is predictable when it is done in the right order. Most of the effort goes into finding the plugins, themes and custom code that will not run on the newer version, then fixing them before the live server changes. Where a rebuild is on the table instead, the comparison of PHP, Python or Next.js for a business website is a useful starting point.

PHP version upgrades are included in the WordPress support retainer from Priority Pixels, with updates tested against a staging copy before they touch the live website. Whoever does the work, the same four stages apply. The PHP upgrade checklist goes into each one in more detail.

Running an end of life PHP version is a decision, even when nobody has made it on purpose. Putting the end dates in the risk register and the upgrade in the plan turns an open exposure into a scheduled piece of maintenance.