Newsletter #012: New Node.js Release Schedule, AI Stress-Testing Security & CVE Season 🔐

Written by Ulises Gascón

Mar 08, 2026 — 9 min read

This post was originally shared with my GitHub Sponsors. If you'd like to get early access to updates like this and support my open source work, consider becoming a sponsor here. 🙌

Hola everyone! 🎉

Hope you've all been doing awesome since our last catch-up. February was one of those months that felt both short and relentless: big structural changes coming to Node.js releases, a reality check on how AI is reshaping security triage, and more CVEs than I'd like to count across multiple projects.

Let's dive in! ✨

📣 Evolving the Node.js Release Schedule

The Node.js Release team is preparing some meaningful changes to how Node.js ships, starting with 27.x. We drafted a blog post (recording) ahead of the upcoming Collab Summit in London, where we'll have a dedicated session to dig into the details, just as we did at the previous one. Official announcement coming soon!

The key changes:

  • One major release per year (April), with LTS promotion in October
  • Every release becomes LTS, no more odd/even distinction
  • New Alpha channel for early testing, with semver-major changes allowed
  • Version numbers align with the calendar year: Node 27 in 2027, Node 28 in 2028, and so on. A neat side effect: the latest LTS version will always match the current year

New Node.js Release Schedule

If you already upgrade only to LTS versions, the practical impact is minimal beyond the version numbering. Library authors: please integrate Alpha releases into your CI as early as possible so you can catch and report issues before they reach your users.

Already picked up by Node Weekly #614 and JavaScript Weekly #775. For the full discussion and background, see nodejs/Release#1113.

🔐 Security State of the Ecosystem

February was a tough month for security triage. The OpenJS Foundation published AI Is Stress-Testing Open Source, and I can confirm it firsthand.

Not long ago, most AI-generated security reports were easy to filter out. That experience led to the New HackerOne Signal Requirement for Node.js. But the landscape is shifting: AI reports are now starting to surface real vulnerabilities (often the same one reported repeatedly until resolved) and we're limited in how fast we can respond when the team largely relies on volunteers.

This is why we're now discussing moving Node.js security reports to a more public workflow. The private triage, patching, and release process is fundamentally different from regular project work, and it's becoming unsustainable at this scale. If LLMs can find these vulnerabilities, they're arguably not as private as they once were.

We're not the only ones adapting. The curl project moved back to HackerOne for better tooling, without re-enabling the bug bounty. Better tooling for security teams and maintainers is becoming critical across the whole ecosystem.

On the offensive side, I spent time this month scanning orgs to prevent HackerBot Claw GitHub Actions exploitation. I put together a quick scanning gist (AI-assisted, naturally) that might evolve into a proper repo someday.

We need to find a way to make security triage sustainable before we burn out the teams and maintainers holding everything together. I shared my thoughts on this at the Security Collab Space (at 38:12). Rafael Gonzaga has also proposed a session titled Node.js Security: State of the Ecosystem & What's Next at the Node.js Collaboration Summit in London to dig into this further.

📦 Release Backlog Updates

Here is what I released recently:

Most of this short month was spent on security triage as part of my role as an OpenJS CNA member and maintainer:

I also published a recap for the Express project: February 2026 Security Releases.

📚 What Else?

The State of JS 2025 results are out. Express remains the most popular backend framework and Lodash still holds strong in libraries. These numbers are a good reminder of why investing in the long-term maintenance and security of these projects actually matters.

Turns out I'm a magpie developer. I was reading the es-toolkit performance docs and got immediately distracted by the fact they use Vitest for benchmarking. One fork and an AI-assisted coding session later, I published lodash-benchmarks, a tool to benchmark Lodash against itself: compare across forks, npm versions, and even PRs before merging. It includes a minimalist CLI and generates output in JSON and Markdown for team analysis. Still a POC, but I'm happy with where the results are heading.

NodeSource joined the OpenJS Foundation's LTS Upgrade & Modernization program as inaugural partner. Too many enterprises are still running legacy or EOL Node.js versions, and this program is tackling that with a secure, AI-powered upgrade path. As part of the partnership, NodeSource is sharing 15% of program revenue to support the Node.js ecosystem. Full announcement here.

The new Node.js API docs tooling was finally merged upstream after months of work by Claudio Wunder, flakey5, Augustin Mauroy, Guilherme Araújo, Aviv Keller, and others. This will eventually bring beta.docs.nodejs.org into the official docs, with new output formats like LLMs.txt and meaningful DX improvements for contributors.

The Webpack 2026 Roadmap is out with some exciting plans: native CSS support without mini-css-extract-plugin, TypeScript without ts-loader, HTML as entry points without html-webpack-plugin, and a universal target for Node.js, Deno, Bun, and browsers. Most of these will land as experimental flags before graduating to webpack 6. As mentioned in issue #011, I joined the Webpack Security Triage team, so expect more Webpack updates in future issues.

Great to see the Python Security Response Team formalizing their governance with PEP 811: clear member responsibilities, a proper onboarding process, and open recruitment for security folks beyond core developers. They published 16 vulnerability advisories last year, the most in a single year to date. More ecosystems leveling up their security posture is always good news.

The "JavaScript Security Snapshot" series with the OpenJS Foundation and Alpha Omega continues. My last contribution: What is even a CVE?

The OpenJS Foundation Security Program: Annual Report 2025 is out. A great read if you want to see how far the ecosystem's security posture has come over the past year.

I was interviewed by Socket about the Lodash security reset and what it actually took to rebuild the project's foundations. If you want the full picture beyond what I shared in issue #011, this one goes deeper into the governance and infrastructure side.

"The code itself was never the main problem. The problem was that something used by millions of systems had no organizational backbone."

Also, Socket has joined the OpenJS Foundation as a Silver Member. Great move!

🎖️ Awesome People Doing Awesome Things

Chris de Almeida has just released CVE Kit, a simple but excellent tool that has already made our work on the OpenJS CNA noticeably faster and less painful. We have more refinements in the backlog, but we already put it to use this month. A great (and opinionated) alternative to Vulnogram.

Matteo Collina shared a skills repo with AI-assisted coding prompts tuned for Node.js Core work, Fastify development, streams, and other common scenarios. Worth bookmarking if you spend time in that corner of the ecosystem.

Joan León published WebPerf Snippets as Agent SKILLs: 47 performance snippets turned into deterministic tools for Chrome DevTools MCP. Instead of inlining JavaScript in markdown where an LLM can reinterpret it, scripts live as .js files the agent reads and executes directly. The SKILLs include 8 workflows with decision trees for automated diagnosis. Really clever approach.

Chip Morningstar wrote a great essay on AI, software development, and why the human job is increasingly about knowing what you want: Adventures In LLM Land, With Thoughts On The AI Revolution. "Learn to be a good wanter" is a line that has stuck with me.

Steven J. Vaughan-Nichols covered the reality of open source maintainer burnout in detail (including some folks I know well) in Workaholic open source developers need to take breaks:

"Many maintainers report they're underpaid or, all too often, not paid at all, despite the enormous downstream value they create. That often means holding a day job and then maintaining critical infrastructure at night. All of which leads to 60-80 hour weeks."

Sometimes we forget the hidden human cost of open source.

🔗 Interesting Stuff

Some awesome reads from my network:

🙌 Thank You!

As always, your support as a sponsor makes all of this possible 💖

Whether you're contributing code, giving feedback, or just following along, thank you!

Stay awesome, Ulises Gascón