Quick answer: An End of Life (EOL) runtime is a version for which the vendor no longer ships security patches. On 21 October 2026 both Node.js and PHP released critical fixes for their supported lines, but EOL lines such as Node.js 18 and 20 and PHP 8.0 and 8.1 did NOT receive them. Systems running those versions were left exposed to the same flaws (a Brotli memory write, TLS verification bypasses, PHP core remote code execution) and will stay exposed permanently. The only correct action is not patching but migration: moving to a supported version. Your task today is to build an inventory first, then migrate in a planned way.

The sneakiest risk in security is not the undiscovered vulnerability, because you cannot plan a defense for something nobody has found yet. The truly sneaky risk is the one everyone knows about but nobody prioritizes: carrying production traffic on a runtime the vendor has stopped supporting. The 21 October 2026 releases gave a concrete illustration. On the same day both Node.js and PHP shipped simultaneous patches for high severity flaws. Supported versions were protected. End of life versions were not even on the list, because no patch exists for them. This article is not about the depth of a single CVE. It uses that event as evidence and focuses on how you should manage the runtime lifecycle.

What an EOL (end of life) runtime means

Every major runtime has a lifecycle. For Node.js it moves through active LTS (long term support), maintenance LTS, and then EOL. For PHP each minor branch gets two years of active bug fixes, then one year of security fixes only, after which support ends. Once a version reaches EOL the vendor ships no further security patches. The code stays the same, but the world changes: when a flaw in that code is discovered, an official fix will never arrive.

The critical misconception is this: a working system is not the same as a secure system. Node.js 18 or PHP 8.1 may run flawlessly today. Performance is fine, no errors, the business runs. But from a security standpoint that system has become an undefended target for every newly discovered flaw. The 21 October event showed exactly this.

Why the 21 October 2026 event is proof

Two parallel releases went out that day, and both proved why EOL lines are dangerous.

On the Node.js side ten fixes shipped, four of them high severity. The most serious was an out of bounds write in the Brotli decoder (CVE-2026-111497), which can lead to remote code execution via a crafted Brotli input. Alongside it were two flaws allowing TLS certificate hostname verification bypass (CVE-2026-106069 and CVE-2026-105483). The patches landed in v22.23.4, v24.22.1 and v26.12.1. Node 18 and 20 are absent from that list. For details see our Node.js October 2026 security update guide.

The PHP side was even harsher: two separate remote code execution flaws in PHP core (CVE-2026-109618 and CVE-2026-109619), rated Critical with a CVSS v4.0 score of 9.2, informally nicknamed PHP2Shell. The patch versions were released as 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (confirm exact versions from the php.net announcement). PHP 8.0 and 8.1, being end of life, received no official patch. For the technical depth of this flaw see our PHP critical RCE PHP2Shell analysis, and the detail on the TLS bypass flaws sits in our TLS hostname verification bypass article.

The message is clear: if you are on a supported version, update and stay protected. If you are on an EOL version, there is nothing to update, there is only migration.

Mandatory table: runtime lifecycle and action

The table below summarizes the status of common versions as of 21 October 2026 and the correct action for each. A version match means "may be affected", not "definitely vulnerable", because your distribution may carry a backport or mitigation. On EOL lines, though, the situation is not in doubt: an official fix will never come.

Runtime Version EOL status Correct action
Node.js 18.x EOL (support ended) Migration required, move to 22 or 24 LTS
Node.js 20.x EOL (mid 2026) Migration required, move to 22 or 24 LTS
Node.js 22.x (LTS Jod) Supported Update to v22.23.4
Node.js 24.x (LTS Krypton) Supported Update to v24.22.1
Node.js 26.x (Current) Supported Update to v26.12.1
PHP 8.0 EOL (support ended) Migration required, move to 8.3 or 8.4
PHP 8.1 EOL (support ended) Migration required, move to 8.3 or 8.4
PHP 8.2 Supported (security) Update to 8.2.35
PHP 8.3 Supported Update to 8.3.36
PHP 8.4 Supported Update to 8.4.27
PHP 8.5 Supported Update to 8.5.12

Half the rows say "migration required". That is no accident. Many enterprise systems still sit on an EOL runtime without even knowing it.

How to manage the runtime lifecycle

This is not a one time repair, it is a continuous process. A sound program rests on four steps.

The first step is inventory. You must keep a written answer to the question of which server, which container, which function runs which runtime version. For Node you pull the node version from each host, for PHP you ask each web server for its CLI and FPM version separately, because they can differ. You cannot manage what you cannot see, so inventory is the foundation of everything.

The second step is turning that inventory into a machine readable software bill of materials (SBOM). An SBOM records which component runs at which version in a standard format and lets you answer "are we affected" within minutes when a new CVE drops. How to combine an SBOM with vulnerability prioritization and supplier evidence is covered in our vulnerability prioritization with SBOM and VEX article. The runtime is the lowest layer of your supply chain, so your defense against supply chain attacks strategy must also cover EOL runtimes.

The third step is a regular patch management process. On supported versions patching should be fast and low risk, while versions approaching EOL must be scheduled in advance. The right move is to place a version's EOL date on your plan at least two quarters before it arrives, not on the day itself. The end to end design of patch management is in our patch management guide.

The fourth step is risk prioritization. Systems that are internet facing, reachable without authentication, and processing critical data come first. A flaw like PHP2Shell, which can be triggered by any multipart form POST request, pushes an internet facing EOL PHP server to the very top of the list.

Migration plan: test first, then production

Migration is not a panicked production change, it is controlled engineering work.

First, stand up the target version in a test environment. When moving from Node 18 to 22 or PHP 8.1 to 8.3, the breaking points are usually removed APIs, changed default behaviors, and dependency incompatibilities. Your automated tests save your life here. If you use containers, rebuild the base image, because nothing inside the container changes until the runtime in the image changes. Running a package update (apt or similar) often does not change the production image, a frequent mistake.

Then deploy gradually: one instance first, then the rest in stages. Keep a rollback plan ready. Runtime migration should be thought of together with infrastructure hardening, so add our Linux server hardening guide to your post migration checklist. When migration is done, remember to update the inventory and the SBOM, otherwise the next CVE will leave you in the dark again.

The KAOS and DSET approach

KAOS, DSET's local artificial intelligence engine, first tries to detect runtime versions when assessing a system: through HTTP headers, error pages, behavioral fingerprints, and clues from exposed endpoints. The detected version is matched against known CVE databases and, where available, KEV (known exploited vulnerabilities) lists, then prioritized by factors such as internet exposure and data sensitivity.

Honesty matters here: version detection is a hypothesis, not a confirmation. A server signaling "Node 20" does not rule out that it runs a distribution with backported patches. That is why KAOS has an over-claim brake: it reports a version match as "may be affected", not "definitely vulnerable". Firm confirmation requires controlled and authorized active validation. EOL status, however, sits outside this uncertainty because it is factual: there is no official patch for Node 18 or PHP 8.1 and there will not be one, which is a calendar, not a guess.

Frequently asked questions

If an EOL version still works, why do I need to migrate? Because "working" and "being secure" are not the same thing. Every new flaw found in an EOL runtime stays open permanently, since the vendor ships no fix. The Node and PHP flaws of 21 October 2026 showed exactly this: supported versions received patches, EOL versions were left exposed to the same flaws. Your system may run fine today, but that does not mean it will not be a target for the next vulnerability.

I use an EOL version in a system too critical to migrate, what should I do? In the short term you can reduce the risk but not remove it. Isolate the system from the internet or place it behind a WAF, narrow the attack surface, bind access to strong authentication, and monitor suspicious request patterns. For PHP2Shell, for example, disabling session.upload_progress closes one suspected path but does not fully remove the flaw. These are measures that buy time, not permanent solutions. Migration to a supported version must be planned in every case.

Where should I track the EOL calendar? For Node.js you can follow the official release schedule on nodejs.org and aggregator sources such as endoflife.date. For PHP the supported versions page on php.net gives each branch's active support and security support end dates. Matching those dates against your own inventory and triggering the migration plan at least two quarters before a version reaches EOL lets you make a controlled transition instead of an emergency patch.

Sources

To build your runtime inventory, prioritize EOL risks, and set up a controlled migration plan, contact DSET. Our team provides end to end support for your enterprise infrastructure lifecycle management from the Ankara Hacettepe Teknokent center.