PHP 7.4 is Dead. Node.js 18 is Dead. Is Your Stack Running on Ghosts?
Two of the most widely deployed runtimes in the world are past end-of-life — and most teams have no idea.
There's a category of security risk that doesn't show up in your vulnerability scanner, doesn't trigger your SIEM, and won't appear in your next penetration test report.
It's not a zero-day. It's not a misconfiguration. It's something quieter and more pervasive: running software that the people who built it have stopped caring about.
Right now, millions of production applications are running on Node.js 18 and PHP 7.4. Both are end-of-life. Neither is getting security patches. And if you're relying on automated tooling to catch this, there's a good chance it already failed you.
Node.js 18: EOL Since April 2025
Node.js 18 entered Long Term Support in October 2022. It was the responsible choice for two solid years. Teams upgraded to it, CI pipelines were built around it, Docker base images were pinned to it.
Then, on April 30, 2025, it went end-of-life.
No more security patches. No more bug fixes. No more anything from the Node.js release team.
That was over a year ago. A meaningful percentage of Node.js deployments worldwide are still on 18 — because it still works, because upgrades take time, because "we'll get to it."
Here's the part that should concern you more than the EOL date itself: some of the most widely used vulnerability scanners return zero results for Node.js 18. Not "no critical vulnerabilities." Not "no new CVEs this month." Zero results — as if the runtime doesn't exist as an attack surface.
This is how the tooling ecosystem handles EOL software: once a version falls off the supported list, it often falls off the scanner's radar too. The CVEs that will affect Node.js 18 going forward simply won't be catalogued against it, because the upstream project isn't issuing advisories for it anymore.
Your scanner gives you a green checkmark. Your stack has a ghost in it.
Node.js 16: Already Ancient History
If Node.js 18 is a ghost, Node.js 16 is a fossil.
Node.js 16 went EOL on September 11, 2023 — nearly three years ago. It lost OpenSSL 1.1.1 support before its own EOL date, when OpenSSL itself went end-of-life.
Yet "node.js 16 end of life date" is still one of the most-searched EOL queries on the web in 2026. Teams are still looking it up. Which means teams are still running it, still evaluating whether they need to act, still in the assessment phase for a runtime that should have been migrated years ago.
If you're on Node 16, you're not behind on maintenance. You're behind on security.
PHP 7.4: EOL Since December 2022
PHP 7.4 reached end-of-life on December 28, 2022 — over three years ago.
And yet it remains one of the most searched EOL queries of 2026.
The reason is structural. PHP 7.4 is deeply embedded in shared hosting environments, legacy CMSes, and applications that were never architected for easy runtime upgrades. WordPress hosting providers dragged their feet. Legacy codebases written against PHP 7.x syntax require real migration effort to move forward. For many teams, the upgrade path from 7.4 to 8.x isn't just a version bump — it's a project.
So it sits. And sits. Running on servers, processing requests, handling user data, with no security patches coming and no eyes from the PHP team watching for vulnerabilities.
PHP 7.4 is past the point where "we should upgrade soon" is an acceptable answer. It's in the territory where "we haven't upgraded yet" is a liability.
PHP 8.2: The Next Ghost You're Not Watching
Here's the one that catches teams off guard: PHP 8.2 reaches end-of-life on December 31, 2026.
That's seven months away.
PHP 8.2 was the responsible choice in 2022 and 2023. Teams that did the right thing and migrated off 7.4 often landed on 8.2. It felt like solid ground.
It still works fine today. But the EOL clock is running, and December 31 has a way of arriving faster than any migration timeline expects.
PHP 8.3 is the current active release. PHP 8.4 is in active development. The upgrade path from 8.2 to 8.3 is significantly smoother than the 7.x to 8.x jump — there are no major breaking changes for most codebases. This is the migration to do while it's still calm.
Why Your Scanner Won't Save You
The CVE model is built around supported software. A vulnerability is discovered, a vendor issues an advisory, a CVE ID is assigned, scanners catalogue it, teams patch it. The whole system depends on vendors actively triaging and disclosing vulnerabilities.
When software goes EOL, that chain breaks. The vendor stops issuing advisories. New vulnerabilities in EOL software often get discovered but never formally catalogued against the EOL version — because who would officially track it? Researchers move on. The scanner has nothing to match against. You get a clean report.
This is the CVE blind spot: the absence of vulnerability data is not evidence of the absence of vulnerabilities. It's evidence that no one is looking anymore.
For EOL runtimes, the risk isn't hypothetical. It's structural. Every new vulnerability discovered in a similar codebase, every technique that works against a shared dependency, every researcher who finds something and doesn't bother filing a CVE for a dead version — that's exposure your tooling will never show you.
What To Do About It
If you're on Node.js 18:
Migrate to Node.js 22 (current LTS, supported until April 2027) or Node.js 20 (supported until April 2026 — but act fast, that's soon). Node.js 22 is the right target. The migration from 18 to 22 is straightforward for most applications. Check your dependencies for compatibility, update your Docker base images, update your CI pipelines.
If a migration isn't immediately possible, HeroDevs offers extended security support for Node.js with commercial patches — worth evaluating for compliance-sensitive environments.
If you're on Node.js 16:
Stop reading this article and schedule the migration. There's no scenario where Node 16 is the right answer in 2026.
If you're on PHP 7.4:
The PHP 8.x migration requires real work — there are breaking changes in how PHP handles type coercion, some deprecated functions were removed, and code written with PHP 7.x idioms may need adjustment. But the work is finite and well-documented. PHP 8.3 is stable and widely supported.
If you're running PHP 7.4 on Linux and need more time, TuxCare provides extended lifecycle support with security patches for EOL PHP versions — a bridge option for teams managing complex migrations.
If you're on PHP 8.2:
Plan the 8.3 migration now, before December. It's one of the easier PHP upgrades in recent history. Don't let a manageable migration become an urgent one.
Check Your Stack
The honest answer for most teams is that they don't have complete visibility into what runtime versions are running where. It's not negligence — it's complexity. Microservices, third-party hosted tools, legacy applications maintained by teams that turned over years ago, Docker images that haven't been rebuilt since they were first pushed.
The first step is knowing what you have.
You can check any software product's current EOL status, supported versions, and release schedule at endoflife.ai — a free public tool covering 450+ products including every major runtime, framework, OS, and database.
The platform also has a stack scanner if you want to check multiple components at once.
The Bottom Line
Node.js 18 has been EOL for over a year. Node.js 16 for nearly three. PHP 7.4 for three and a half. Your vulnerability scanner is almost certainly not flagging any of them.
EOL software isn't a theoretical risk you manage in a future sprint. It's a current exposure you're carrying right now, in production, with no patches coming and no alerts firing.
The ghosts in your stack don't announce themselves.
Want to stay on top of EOL dates before they become incidents? endoflife.ai tracks 450+ products — free, no account required.
Tags: security node php devops webdev
Top comments (0)