Your PHP or Node.js version no longer gets fixes: what it means and what you can do

PHP2Shell and the October 2026 Node.js vulnerability were only fixed in supported versions. What end of life means and your options, from backports to migration.

On 21 October 2026, two important security updates arrived for the languages behind many business websites and applications. PHP fixed two critical vulnerabilities known as PHP2Shell. Node.js fixed, among other things, a serious flaw in its Brotli compression decoder (CVE-2026-111497). The fixes, however, only came for versions that are still supported. Anyone running an older version got the same vulnerability, but no fix.

This article explains, for owners and managers, what an "unsupported" version means, why it matters right now and what options you have, from the quickest to the most expensive.

Every major version of PHP or Node.js follows a public schedule. For a while it gets improvements and fixes, then only security fixes, and finally it reaches end of life (EOL). After that date, the team maintaining the language publishes nothing more for it, not even when a critical vulnerability appears.

For PHP, the official schedule currently looks like this:

• PHP 8.5: security fixes until 31 December 2029;
• PHP 8.4: until 31 December 2028;
• PHP 8.3: security fixes only, until 31 December 2027;
• PHP 8.2: security fixes only, until 31 December 2026;
• PHP 8.1: unsupported since 31 December 2025;
• PHP 8.0: unsupported since 26 November 2023;
• PHP 7.4: unsupported since 28 November 2022;
• PHP 5.6: unsupported since 31 December 2018.

For Node.js, production applications should run a long-term support (LTS) version:

• Node.js 18: unsupported since 30 April 2025;
• Node.js 20: unsupported since 30 April 2026;
• Node.js 22: supported until 30 April 2027;
• Node.js 24: supported until 30 April 2028;
• Node.js 26: becomes LTS on 28 October 2026, supported until 30 April 2029.

The 21 October fixes were released for PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and for Node.js 26.12.1, 24.22.1 and 22.23.4. The Node.js team states explicitly that end-of-life versions are affected by every security release, even when they are not listed in the announcement.

This is not a theoretical problem. According to Modat data reported by The Hacker News, of roughly 4.38 million PHP services exposed to the internet, about 79% were running unsupported branches. VulnCheck counted more than 700,000 servers still on PHP 3.x to 7.3. Romania's national cyber security directorate, DNSC, notes that end-of-life installations carry the highest risk and recommends fixing them through backports, isolating them and migrating them as a priority.

Ask your hosting provider or whoever manages your application which version actually runs on the server, rather than what an old document says. On WordPress, the PHP version is shown under Tools → Site Health → Info → Server. For a Node.js application, whoever manages it can see it straight away on the server or in the build configuration. It is worth asking for the answer in writing, with the date it was checked.

If you are on PHP 8.2–8.5 or on Node.js 22, 24 or 26, you are in luck: you install the fixed version from the same branch and restart the processes. Usually nothing changes in the code. It is a job of hours, not days, provided there is a backup and a check afterwards.

Be careful with PHP 8.2, though: it receives the fix now, but its support ends on 31 December 2026. If you are making a change anyway, it is cheaper to plan the move to 8.4 or 8.5 now.

For PHP 7.4, 8.0 and 8.1, the PHP team published minimal fixes as source code. These are not ready-to-install releases: someone has to build PHP, test it and maintain it. Some Linux distributions and extended-support vendors offer patched packages for old versions. For Node.js, the project points to commercial partners in the OpenJS programme for end-of-life versions.

This is a good way to buy time, not a permanent state. You pay for support, and the date by which you must migrate simply moves further out.

If the application cannot be fixed immediately, it can be taken off the public internet: access only through a VPN or from an internal network, a web application firewall (WAF) in front, unused features switched off. DNSC recommends this for critical systems that cannot be updated quickly. It fixes nothing; it only limits who can reach the vulnerability.

This is the lasting solution for most companies. In short, it means:

• Dependencies: the libraries the application uses have to be brought to versions compatible with the new PHP or Node.js, and some have been abandoned and must be replaced.
• Deprecated code: functions that were removed or behaviour that changed between versions, which has to be rewritten in place.
• Testing: checking the important flows (orders, invoices, sign-in, forms) before and after, ideally on a copy of the application.
• Going live: with a backup, a rollback plan and a period of close monitoring afterwards.

For a WordPress site that has been kept up to date, migration is often a setting in the hosting panel plus testing. For an application written ten years ago for PHP 5.6 or 7.x, it is a project in its own right, because the differences between versions have piled up.

Sometimes the code is so old or so tangled that migrating costs almost as much as a new application. In that case a rewrite may be the more honest option, especially if you want new features anyway. But it is a big decision: it costs more, takes longer and carries its own risks. You do not choose it in a panic, but after an assessment of the code.

Three simple questions help:

1. How exposed is the application? A public site with forms and customer accounts is more urgent than an internal tool used from the office.
2. How far is your version from a supported one? Going from 8.1 to 8.4 is a small step; going from 5.6 to 8.4 is a long road.
3. How much longer do you want the application to live? If you are replacing it within a few months anyway, isolation and a backport may be enough. If it is the backbone of the business, migration is an investment.

In practice, a sensible order is: isolate or fix what is exposed now, then plan the migration with a clear budget and timeline, before the next vulnerability arrives.

At ME Digital we take companies through exactly this path: we assess the code, apply the available fixes, isolate what cannot wait and migrate older applications to supported versions, through our security and updates services. If you are not sure which version your application runs on, get in touch and we will check it together.

• PHP, supported versions
• PHP, unsupported branches
• PHP, security announcement of 21 October 2026
• Node.js, release schedule
• Node.js, previous releases and support
• Node.js, October 2026 security releases
• The Hacker News, exposure of PHP servers (Modat and VulnCheck data)
• DNSC, Alert: critical vulnerabilities in PHP (in Romanian)