What to Do with a Website on an Outdated PHP Version or Old Node.js?

The short answer is this: a website on an outdated PHP version or an old Node.js version has three paths. The paths are to adapt the code to a supported release, to rebuild the website from scratch, or to keep the website for a time on a platform that still backports security patches for the old runtime, and meanwhile to plan the move calmly. There is in fact no fourth path, the path of leaving everything as it is because the website still works, because the PHP 8.1 and older release branches no longer receive fixes from the PHP project, nor do the 18 and 20 release lines of Node.js, and October 2026 showed in both cases what that means in practice.

A website on an outdated PHP version is usually neither an exception nor some particular neglect. It was built five or eight years ago, the developer who built it has long been working somewhere else, and through all those years the website has served without major problems: it has accepted enquiries, shown prices and sent invoices. According to W3Techs data, in October 2026 26.8% of the websites that use PHP were running on PHP 7 and a further 7.7% on PHP 5, so more than a third of them use PHP that reached end of life several years ago. The question usually arises only when the hosting provider sends a warning, or when some vulnerability reaches the news.

When a PHP or Node.js version becomes old

Node.js publishes a schedule, and so does PHP, and "old" here is not a matter of taste, because that schedule states the date until which each release branch or release line still receives fixes. For each release branch, PHP gives two years of Active support and a further two years of security-only support, in which only fixes for critical security bugs come out, and after that the release branch is not supported in any way. Long-term support release lines end in a Maintenance LTS phase, and when that phase ends the release line receives nothing further at all, even when a new vulnerability affects that particular line.

The table lists the release branches and release lines that one meets most often today, together with their status in October 2026. The dates are taken from PHP's end-of-life list and from the Node.js release schedule, and both sources should be checked again later, because every year new rows appear in them.

Two rows in this table are worth reading again. PHP 8.2 reaches end of life on 31 December 2026, so a website that looks current in autumn 2026 will, in January 2027, be in the same situation as a website on PHP 7.4, and the move is worth planning now, while it can still be done without a rush. The Node.js 20 release line was still the Active LTS line in autumn 2024, the line on which many new projects were started, but on 30 April 2026 it reached end of life. Ageing does not happen gradually: on one particular day the runtime passes from "receiving fixes" to "receiving nothing", and at that moment nothing changes on the website that anyone would notice.

Why a website that works is still at risk

A version past end of life does not become dangerous on the day it reaches end of life, but on the day a vulnerability is published that affects it as well. The fix for the supported release branches comes out together with a description, and as soon as that description is public, attackers can compare the fixed code with the unfixed code and work out where the hole is. Node.js says this directly on its end-of-life page: if a vulnerability also affects a release line that is past end of life, nothing new will come out for that line, and those who remain on it are immediately unprotected against attacks that use the published vulnerability.

In October 2026 that is exactly what happened to both platforms, almost at the same time. On 21 October PHP issued emergency fixes for two critical vulnerabilities known as PHP2Shell, and official releases went only to the release branches from 8.2 to 8.5, while for the 7.4, 8.0 and 8.1 release branches the security team, as an exception, prepared only minimal source-code fixes for the people who build PHP themselves. On the same day Node.js issued fixes for ten vulnerabilities, and the 18 and 20 release lines received none of those fixes from the project itself. We have described both cases in more detail separately, in the article on PHP2Shell and in the article on the Node.js security update.

The second risk is less visible, but over the long term it is the larger of the two. An old runtime does not allow anything that sits above it to be updated: WordPress plugins, Composer packages, npm packages and the framework itself gradually stop supporting old PHP and old Node.js in the versions that come later, so the website cannot receive their fixes either. WordPress itself recommends PHP 8.3 or newer, and of the older release branches it writes that they have reached official end of life and that they can leave the website unprotected. The old runtime is then no longer one separate problem, but the layer that stops every other problem from being solved.

When something does happen, the cost is considerably higher than the cost of a planned update. A hacked website means the clean-up, a restore from backup, the changing of passwords and keys and, if customers' personal data were affected, also an assessment of whether a personal data breach has to be reported to the supervisory authority, and all of that happens in a rush, while the website is down or is showing visitors someone else's content. The move still has to be made in that situation, only now it has to be done after the break-in rather than before it, and without the chance to check everything calmly in a test environment.

Why an outdated PHP version cannot simply be switched in the hosting panel

In the hosting panel, a move to a newer PHP version takes a single click, and that is exactly why the click is a trap: if the code is not ready for the newer version, the website stops working in the next second, often with a blank page or with an error message. On the move to the next major release, PHP deliberately removes functions that had been obsolete for many years. PHP 7.0 removed the old mysql PHP extension, which many older websites were built on, while PHP 8.0, in its list of incompatible changes, among other things removed the functions each() and create_function(), which are still found in older code.

A classic example from Node.js, the 17 release line, is the one in which the runtime moved to OpenSSL 3.0. In the release announcement, Node.js warned that an application which itself, or whose modules, uses an algorithm or a key length that OpenSSL 3.0 no longer allows by default will receive the error ERR_OSSL_EVP_UNSUPPORTED, and as a temporary workaround it offered the launch option --openssl-legacy-provider. The error was often caused not by the project's own code but by one of its dependencies, so the fix had to be made in code that the project team had not written at all.

The move is therefore development work, not a setting in a panel. The code has to be checked against the new runtime, the obsolete functions have to be replaced, the dependencies have to be updated to versions that support the new runtime, and everything has to be tried in a test environment before clients see it. For a small website on a maintained platform that can be a few hours of work, but for a system whose framework reached end of life several years ago the move often means replacing the framework as well, and then it is already a project with its own budget and its own schedule, not a task that can be finished in between other jobs.

Three paths: update, rebuild, or keep it protected

Which path fits is decided by two things: how far the code has fallen behind a supported version, and how long the website still has to serve. If the website is going to be replaced with a new one after a year in any case, a large move inside the old code is not worth doing, but if the website is the company's everyday working tool and will still be used for at least five years, a temporary solution only postpones the inevitable and makes that inevitable more expensive. The table sets out the three paths that are actually available, and it sets out what each of them solves and what it does not.

Updating is the right choice when the website is built on a maintained platform, for example WordPress or Laravel, and one or two major steps separate it from a supported release branch. The work is then predictable: the framework and the plugins have to be updated, whatever the checking tools find has to be fixed, and PHP has to be switched. A rebuild is the more honest path when the framework itself is without support, when the website was written on PHP 5.x with no framework at all, or when nobody understands the code any more, because the cost of updating then quickly approaches the cost of a new website, while the result is still old code.

The third path is discussed less often than the other two. An old website can be kept on a platform that still backports security patches for its runtime, isolates that website from the others, and blocks known attack patterns even before a fix is available. That is not a substitute for the move, and Node.js itself calls support of this kind a temporary solution, but it is an honest way to gain time: the move can be carried out at a planned pace, rather than in the week after the next security announcement. The most important word here is "deadline", because without a deadline a temporary solution becomes a permanent one.

What a backport is, and why the version number says nothing about it

A backport means that a security patch developed for a newer release is adapted by someone and built into an older release that the user is already running. Red Hat, which maintains the packages of its Linux distributions in this way, writes that the version number alone does not let the customer judge whether the system is vulnerable, because the fix changes the package but does not change the version number. That is exactly why vulnerability scanners that look only at the number tend, on such systems, to erroneously report problems that have already been fixed.

For PHP, and for Node.js, several vendors do this work. Linux distributions backport fixes into their own PHP packages and Node.js packages for the whole of the distribution's support period. CloudLinux, for its alt-php packages, which are what hosting servers running CloudLinux use, also backports fixes into release branches whose PHP reached end of life long ago: in the PHP2Shell case, its status page announced on 21 October that it was preparing patched packages for every alt-php release branch from 5.2 to 8.5, and during the following night those packages were available. These packages are now part of the extended support offered by the company TuxCare, whose terms name, as the target for vulnerabilities of high and critical severity, a fix within 14 days of publication.

For release lines past end of life, the same kind of service is offered by commercial partners that Node.js itself names on its end-of-life page: HeroDevs, NodeSource and TuxCare. Node.js adds, in the same place, that support of this kind is to be regarded as a temporary solution, and that the aim must always be a move to a supported version. In October 2026, CloudLinux backported the fixes into its own packages for the 16, 18 and 20 release lines as well, which are the packages hosting customers choose in the cPanel section Setup Node.js App.

None of this can be checked from the version number. The command php -v or the command node -v shows exactly the same thing after a backport as it showed before, and CloudLinux writes this openly in its announcement: for release lines past end of life, the number does not change after the update. What does change is the package's release number, which only the server administrator can see, so on shared hosting the only party who can give the answer is the hosting provider.

The limit has to be stated just as clearly as the mechanism. A backport protects PHP itself, or Node.js itself, but it does not protect a WordPress plugin whose author has stopped updating it, it does not protect self-written code that contains an SQL injection, and it does not protect an npm package whose later versions no longer support an old release line. Vendors also backport the fixes for each release line separately, so each particular release line has to be checked to see whether it is on the list at all, and in its terms TuxCare reserves the right to offer a risk-reducing measure instead of a fix.

When the platform is old, not the runtime

Sometimes the problem is not in the runtime but in the platform the website is built on, and then backported PHP fixes help only in part. The clearest example is Drupal 7: its security support ended on 5 January 2025, and since that date the Drupal project itself no longer publishes either security updates or compatibility updates for it. A website on Drupal 7 can run on PHP that has been fully patched, but its Drupal core, its modules and its theme still carry every vulnerability that is yet to be found in them, because nobody fixes those free of charge any more.

A paid temporary solution is available in this case as well. The Drupal Association has set up an Extended Security Support Provider Program, in which vetted vendors, for example HeroDevs and Tag1 Consulting, offer paid support. It is the same principle as a backport for PHP, only one layer higher, and it carries the same limits: it postpones the move but does not complete it, and each year spent on the old platform makes the eventual move more expensive, because the distance to the current version grows and the number of developers who still know the old platform shrinks.

Before any decision, then, every layer is worth checking, not only the PHP release branch: the runtime, the platform or the framework, the plugins or the modules, and the self-written code. If only PHP is old, while WordPress, Laravel or another platform is still maintained, the move is usually predictable work. If the platform itself is old, the question is no longer which release branch to choose, but whether to move the website onto the new version of the platform or to build the website anew, and it is exactly here that a backport has the job of giving time for that decision to be taken without a rush.

How we keep old PHP and Node.js on our server

Our managed hosting is a place on our own server, which runs on CloudLinux, and the PHP version for each website is chosen separately in the hosting panel. PHP from 5.4 to 8.4 is available there at the moment, and for applications there are both the supported 22 and 24 release lines and the old 16, 18 and 20 release lines of Node.js. An old website can therefore be moved to us on the same PHP it runs on now, or the same Node.js it runs on now, and it can be stabilised first, rather than having its code changed as well on the day of the move, which is the safest way to break nothing while the move is under way.

How this works in practice is something we were able to measure ourselves in October 2026. The PHP2Shell fixes came out on the afternoon of 21 October, and on our server every old PHP release branch from 5.4 to 8.1 now runs on packages that CloudLinux rebuilt that same night, less than a day after PHP published them, with the fix backported into those packages. The release branches from 8.2 to 8.4 moved onto the official fixed versions 8.2.35, 8.3.36 and 8.4.27, while, for Node.js, the 16, 18 and 20 release lines received CloudLinux packages with backported fixes on 22 October, even though the project itself issued no fixes for those lines. On the old release branches the number did not change, so we checked them not by the number but by the moment at which the executable files had been rebuilt.

That is not the whole of what the platform does. CloudLinux places each hosting account in its own isolated environment, called CageFS, and inside that environment users cannot see the other users on the server, or even those users' usernames, which makes it harder for a break-in to spread from one account to the others. In the PHP2Shell case, the Imunify360 web application firewall (WAF) started blocking the known attack patterns on 21 October, several hours before the patched PHP was published. None of these layers makes an old website invulnerable, but taken together they narrow the time during which a known vulnerability can be exploited, and they limit how far the consequences of a break-in can reach.

We therefore recommend that a move of an old website to us be treated as a temporary solution with a deadline, and not as a final destination. We move the website on the same runtime, we check that everything works as it did before, and then, together with you, we agree the date by which it moves to a supported version and the order in which that happens, so that the temporary solution does not turn into a permanent one. Our managed hosting starts at €45 a month, and maintained runtimes, account isolation and a web application firewall are part of what that sum pays for. If you have a website on an old PHP version, or an old Node.js version, send us its address, and we will say which of the three paths fits it and what to start with.

How to find which PHP or Node.js version your website is on

The fastest path is the hosting panel. On cPanel hosting with CloudLinux, the section Select PHP Version shows the version chosen for the whole account, while MultiPHP Manager shows the version for each domain separately, and if a domain has its own version set there, that domain setting is the one that decides. For each application, the section Setup Node.js App shows the same kind of choice, with its own row. Every website is worth a look, not only the main one, because a single account often holds several websites on different PHP release branches, and a forgotten test copy or an old campaign page is often still reachable from the internet.

On a WordPress website the same fact can be read in the administration panel: under Tools → Site Health, on the Info tab, in the Server block, the PHP version the website runs on is shown. Where there is no panel, a file can be created with the function phpinfo() and opened in the browser, but afterwards that file has to be deleted, because it shows the server configuration to every visitor. The command php -v helps less here than it appears to, because it shows the command-line PHP, whereas web requests are often served by a different release branch, the one selected in the hosting panel. In a project, the desired release line is often named by the package.json field engines, or by the file .nvmrc, but that line is only a wish, and which runtime actually runs the application has to be seen in the place where the process is started.

Where there is no access at all, the question has to be put to the hosting provider, or to the developer who maintains the website. A wording that saves a round of correspondence is this: "Which version of PHP, or of Node.js, serves our website? If it is past end of life, does it receive backported security patches, where do those patches come from, and when was the package last updated? Until which date do you recommend the move?" The answer to that last question says a great deal about the provider as well, because if there is no date, there is usually no plan either.

Moving to a supported version: how to do it without surprises

The move begins with an inventory, not with the switch. What has to be written down is which PHP release branch the website needs, which PHP extensions it needs, which scheduled tasks run it in the background, which external systems it talks to, and which of its parts are critical to the business, for example the order form, the payments, or the sending of invoices. The target version is worth choosing with a margin: PHP 8.4 will receive security patches until 31 December 2028 and PHP 8.3 until the end of 2027, whereas a move to PHP 8.2, which reaches end of life already at the end of 2026, would mean yet another move very soon. For Node.js, in most cases the target is the 24 release line.

The second step is a check of the code, and for PHP that check can be automated to a large extent. PHPCompatibility is a set of rules for PHP_CodeSniffer that checks whether code is compatible with one particular PHP version, while Rector can carry out some of the changes that the check shows are necessary. Neither tool replaces a check by a person, but the two of them quickly show whether the amount of work is measured in hours or in weeks, and that is exactly what is needed when the choice is between an update and a rebuild. On a WordPress website the plugins and the theme have to be updated first, and only after that is the PHP version switched.

The third step is a test environment, that is, a copy of the website running the new PHP, or the new Node.js, on which every critical action is tried: the forms, the payments, the sending of email, the import and the export. At this stage the error log matters more than a visual check, because warnings about obsolete functions show up in that log long before anything actually stops. The fourth step is the switch itself, made when the load is low and with a way back: on hosting that offers a version choice, the way back is the same single click that made the switch, so the risk stays small as long as the backup is fresh and someone follows the error log through the first week.

For a Node.js application the logic is the same, and only the tools are different. A move between major release lines is worth making one line at a time, with the application's own tests run after each line, and particular attention has to go to packages that contain compiled code, because those packages are built for one specific release line and have to be rebuilt once the move is done. Dependencies that do not yet support the new release line have to be updated first, and only then is the runtime itself changed, since otherwise the errors from the two sides mix and it becomes hard to tell which of them caused what.