Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- Once a Node.js version reaches end of life, upstream stops checking whether new vulnerabilities affect it.
- Starting with Node.js 27, the project ships one major release a year, and every release line becomes LTS.
- AI tools are finding real Node.js bugs, but duplicate reports now bury the volunteers doing triage.
- Teams that can’t upgrade on schedule need a patched runtime, not hope that nothing gets disclosed.
A Node.js application doesn’t stop running when its version reaches end of life. The upstream project just stops looking after it. And as Node.js Technical Steering Committee member James Snell explained in a recent fireside chat with TuxCare, that difference is a lot bigger than it sounds.
“No backports, no fixes,” he said. When a new vulnerability report comes in, the team doesn’t even test whether it affects an EOL line. A service can look perfectly healthy in production while the security work happening upstream has quietly moved on without it.
That was one of several candid moments in “Keepers of the Runtime,” where Snell sat down with TuxCare senior developer advocate Chris DeMars. No slides, no product demo. They covered why Node.js is moving to one major release a year, what AI-generated security reports are doing to a volunteer security team, and how much human work sits behind a routine-looking security update. Here’s what matters most if you run Node.js in production, though it’s worth taking half an hour to watch the full replay.
Node.js End of Life Is the End of Upstream Security Work
Snell’s description of end of life was blunt. Once a major version leaves support, nothing else gets pushed to it. No security fixes, no ordinary bug fixes, no backports from newer branches. “Other people might, but we’re not going to,” he said of testing old lines against new reports. “Once it’s end of life, it is off our radar.”
The project’s own guidance on EOL vulnerabilities draws the same line. An old release may well be affected by a vulnerability disclosed in a maintained version, but upstream generally won’t investigate the old branch to confirm the impact, let alone build a fix.
Think about what that means for your scanner. Since 2025, new Node.js CVEs list EOL lines as affected by default unless the project learns otherwise. That keeps the warning visible, but nobody upstream confirmed the flaw on your version, and nobody upstream is building the fix.
An EOL runtime doesn’t sit in isolation, either. Node.js bundles components like V8 and OpenSSL, and Snell pointed out that V8 zero-days come out all the time, sandbox escapes included. Not every browser-side V8 flaw reaches Node.js, but someone has to work out which ones do, and on an EOL line that someone isn’t upstream. Meanwhile, libraries and tooling keep dropping support for older Node.js versions, so a postponed upgrade gets harder every month.
None of this makes every EOL deployment automatically exploitable. Exposure depends on the specific vulnerability, configuration, and reachable code paths. What changes at EOL is that the upstream answers and patches stop coming, and that leaves your team with more investigation to do at exactly the point where its options are narrowing.
Why Upstream Won’t Keep Old Versions Alive Longer
People do ask upstream to keep an old line going a little longer. The answer comes down to people and machines. Node.js is maintained primarily by volunteers. A few contributors are sponsored, but by Snell’s account nearly everyone who releases, backports, and contributes does it on their own time. “We’re not going to just blanket support things forever,” Snell said. “We can’t. It’s impossible.”
Then there’s CI. According to Snell, a full CI run covers about 55 platform, architecture, and OS combinations, with something like 7,800 tests on each, and a single run can take up to an hour. Companies donate that infrastructure, and its capacity is fixed. Multiply that by every old release line and the math stops working fast. As Snell put it, “End of life is end of life because we just physically cannot dedicate the resources to maintaining it.”
That’s a fair position; it’s hard to argue with. It does leave a gap, though, and the gap belongs to whoever still runs the old version.
Why Node.js Is Switching to One Major Release a Year
The same capacity problem explains the new release calendar. The old schedule was a compromise born during the io.js reunification: short-lived odd-numbered releases, supported for only about eight months, so library and framework authors could see what was coming, plus even-numbered releases that became LTS for companies.
Ten years of download data told a different story. “Nobody actually used the short-term ones,” Snell said. Enterprises were already upgrading roughly once a year, if that. Maintainers, meanwhile, were sometimes juggling four or five active release lines at once, and every security fix had to be traced through branches that had drifted in different ways.
Under the official Node.js release plan, Node.js 27 is the first line on the new model. Each year brings one major release in April, promoted to LTS that October, so every release line ends up as LTS. An Alpha channel takes over the early-testing role odd releases used to play, and after six months in Alpha, each line gets 36 months of support from its first Current release to end of life. Snell’s summary of the upside was simple: far fewer lines to juggle, with roughly three in flight at a time.
| Release line | Alpha begins | First release | Enters LTS | End of life |
|---|---|---|---|---|
| Node.js 26 (last on the old model) | Not applicable | May 2026 | October 2026 | April 2029 |
| Node.js 27 | October 2026 | April 2027 | October 2027 | April 2030 |
| Node.js 28 | October 2027 | April 2028 | October 2028 | April 2031 |
If your team already deploys only LTS releases, little changes beyond version numbering. If you build products on Node.js, Snell’s advice was to stop waiting for April to find out what broke. Major changes and deprecations land on main constantly. Add a smoke-test job in CI that runs against upcoming Alpha builds without blocking merges, and have someone actually read the results. Alpha builds aren’t meant for production, but finding a problem three or four months early is far cheaper than discovering it during a migration window.
What Happens Between a Node.js Security Report and a Fix
Node.js takes vulnerability reports through HackerOne. A triager first establishes whether the behavior is real, then decides whether it crosses a security boundary defined by the project’s threat model.
That second judgment is easy to overlook. Node’s trust model is blunt: if the code runs, it’s trusted. A segfault you can only trigger by running your own code locally is probably a regular bug, fixed in the open. Something reachable through untrusted remote input, like remote code execution or a remote denial of service, gets treated as a vulnerability.
Those fixes are developed, reviewed, and landed in a private fork of Node, and the security release is cut from there. Only after it ships do the changes move into the public repository. That keeps the gap between disclosure and an available patch close to zero for supported lines, but it also means the clock is already running for you the moment an advisory goes public. The October 21, 2026, release is a good example – ten CVEs across the 22.x, 24.x, and 26.x lines, four of them rated High. TuxCare’s “10 Node.js CVEs, a Brotli RCE, and What to Do If Your Version Is EOL” breaks down what it means for anyone on an EOL line. The next round is already lined up, too. Node.js has announced another security release for November 11, 2026, or shortly after, again covering 22.x, 24.x, and 26.x with the worst issue rated High. The advisory spells out that EOL versions are always affected when a security release occurs.
AI Is Finding Real Bugs and Flooding the Triage Queue
This was where Snell got the most animated. AI-assisted scanning works. “It absolutely is finding real bugs,” he said. Accuracy isn’t the main problem. Volume is.
Researchers running similar tools tend to find the same bug at the same moment and submit it independently. Snell described getting 10 or 20 reports about one issue, with more still arriving while the fix was underway and a long tail trickling in after disclosure. During one recent stretch of triage, he estimated that “probably nine out of every 10 reports were a duplicate” – his estimate from that workload, not a measured rate.
The OpenJS Foundation’s Q2 2026 security update backs up the trend. Node.js received 352 HackerOne reports in the two years before that quarter. Then reports jumped 4.6x in February 2026 after AI-assisted scanning tools arrived, and March alone brought 65. By the time of the chat, Snell said, Node.js had already released fixes for more than 50 vulnerabilities in 2026, a record.
His advice to researchers was practical. Read the project’s security policy and threat model. Search HackerOne’s publicly disclosed reports to see whether the issue has already been handled. And if your agent turns up 20 candidates, don’t file 20 reports in one burst. Rank them and send the critical ones first.
The Work That Doesn’t Show Up in Release Notes
Snell didn’t arrive at Node.js through some grand plan. In 2013, while at IBM, he found a bug where Node treated a mangled HTTP method like P?T as a real method instead of rejecting it. With no security reporting process yet, he opened a public issue, got told he didn’t understand how this kind of software worked, fixed it himself, and walked away. The io.js fork pulled him back when IBM needed a technical lead for everything Node, and he joined the TSC around March 2015.
The daily work is less glamorous than the title. Mornings start with an hour or more of GitHub notifications, sometimes 800 or 900 in a day. Code review takes even more of his time. “I read every line of every PR, even the large ones,” he said, whether it’s ten lines or 20,000, often in two or three passes. AI now writes most of his tests, but it hasn’t replaced the judgment.
Snell also pushed back on the idea that Node.js has a product roadmap. “There’s no product manager. There’s not even a project manager.” Nobody can buy a feature into Node. Once CI passes, a pull request can land with two approvals after at least 48 hours, or with one approval after a week, as long as nobody objects. So if you want Node to do something, his advice is to open a PR and do it yourself, not demand that volunteers build it for free.
What This Means for Teams Still Running Older Node.js Versions
Start with what’s actually deployed. Not what the current Dockerfile says or what the migration ticket claims, but the Node.js versions running in production, including the services nobody has touched in a while. Check them against the Node.js release schedule, flag the ones already past EOL, and give each one an owner. Node.js 20 reached end of life on April 30, 2026, and Node.js 22 follows in April 2027, so this isn’t only a problem for teams on ancient versions.
If you can upgrade now, do it. A supported LTS line is the cleanest answer, and routine runtime upgrades beat an emergency every few years.
Some applications can’t move on that timetable. Picture a payments service pinned to Node.js 18 because a native addon breaks on newer V8, with the migration waiting on a vendor rewrite two quarters out. In cases like that, “we’ll upgrade later” isn’t a security plan unless the old runtime still has a way to receive fixes.
That’s the gap TuxCare Endless Lifecycle Support (ELS) for Node.js fills. Part of ELS for Runtimes, it backports security fixes into covered EOL Node.js versions under SLA and delivers them as package updates, so your applications keep running on the runtime they were built for while you finish the migration on your schedule. Just restart the affected Node.js processes after an update so they pick up the patched runtime. Coverage goes back as far as Node.js 10 on Enterprise Linux and spans Ubuntu, Debian, and Alpine Linux too, with supported versions varying by OS, so check the version matrix in the docs. It doesn’t remove the need to upgrade eventually. It covers the stretch between the day upstream stops fixing a version and the day you can safely retire it.
There’s no need to wait on a sales call, either. Buy ELS for Runtimes online, install it, and get your EOL Node.js versions back on a patch stream.
Frequently Asked Questions
What happens when a Node.js version reaches end of life?
Upstream stops all commits to that line, including security fixes, and doesn’t check whether newly reported vulnerabilities affect it. From that point on, the risk falls to the team running it.
When does Node.js 27 come out?
The Node.js 27 Alpha began in October 2026. The first Current release is scheduled for April 2027, with LTS promotion in October 2027 and end of life in April 2030.
Can you keep running Node.js 18 or Node.js 20 after end of life?
Yes. Commercial support such as TuxCare’s Endless Lifecycle Support for Node.js keeps delivering security fixes for covered EOL versions while you plan your upgrade, as long as you install the updates and restart affected processes.
Watch the Full Fireside Chat
The replay has the stories this post skipped, plus the live Q&A on duplicate reports and volunteer retention. Watch “Keepers of the Runtime” with James Snell and Chris DeMars.
And if part of your stack is still on a Node.js version upstream has stopped patching, don’t wait for the next advisory to make the decision for you. Get ELS for Runtimes and keep covered versions getting security fixes while you upgrade on your terms.
