Newsletter #014: A Flood of Reports and a Fresh Coat of Paint 🎨🔐

Written by Ulises Gascón

Jun 09, 2026 — 15 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. It has been a while, so go ahead and grab a coffee, this one is an extra large. A lot has happened: the flood of AI-generated security reports reached a new level, we gave Express a brand new look, the Node.js Collaborators Summit tackled some uncomfortable questions, and May was Maintainer Month, which this year felt more like a rallying call than a celebration.

Let's dive in! ✨

🎨 A New Look for Express

We gave Express a brand new look! The website is now fully migrated to Astro, with versioned docs, a smarter Orama-powered search, and a fresh logo to match. It finally looks and feels like 2026, and yes, that makes us very happy. It is one more milestone on the long path we started back in 2024.

The Express website before and after the redesign. Left: the previous dark Jekyll site. Right: the new Astro site with refreshed branding and the tagline "Fast, unopinionated, minimalist web framework for Node.js".

The Express website, before and after the redesign.

We were even featured in Node Weekly. This one was a real team effort. Special thanks to Sebastian Beltran, who led the redesign, and to Francesca Giannino for the technical migration; to the Orama team behind the new brand, Angela Angelini, Michele Riva, and Davide Spaziani; and to Shubham Oulkar, the Express TC team, and everyone who chipped in with reviews, issues, and comments along the way. If the Orama name rings a bell, it is because they are also the team behind the Node.js website search experience, so working with them again felt like a natural fit.

The new Express brand assets. Left: the favicon, an "ex" monogram inside a rounded square. Right: the full "express" wordmark logo.

The new Express logo and favicon.

But the part that stuck with me was not the logo vectorization headaches or the UX problems we set out to solve. The Orama team ran a workshop that pushed us to deep dive into what Express actually values, and why those values drive us forward. It turned into a massive retrospective with the people who have carried Express over the last years, and it connected directly to my talk about what comes after chaos, which I first shared back in issue #10. Getting that deep alignment on our mission, vision, and values made it much clearer, as a TC, what really drives our decisions and our work with the community. It was an immense gift, and it is lighting our way.

Our vision is that "Express is a minimal, scalable, and stable web framework for Node.js with a welcoming community that empowers developers of all levels." Our mission is to make it easier for developers to build great software by clearing away the complexity of server-side development in Node.js. And three values hold it together: Established (the default choice, not a question mark), Dependable (built to last, trusted to work), and Approachable (start fast, stay flexible).

So next time you wonder why our source code still supports legacy versions like Node 0.7, or why we are so strict about semver, you can trace it straight back to "Dependable". People build on certain expectations, and we honor that deeply.

And honestly? The new website is gorgeous. The next step is to review and refresh the content. We have also started kicking around the idea of a merch store to support the project, think t-shirts, hoodies, and stickers. Because let's be real, we all love good merch. 😄

🎤 Node.js Collaborators Summit in London

In mid-April, a big part of the project gathered in London, hosted by Bloomberg, for our 26H1 Collaborators Summit. Two days of conversations about where Node.js is heading, and a lot of them kept circling back to the same question: how do we keep this sustainable?

Two-photo composition from the Node.js Collaboration Summit in London: on the left, collaborators gathered around tables with laptops in a conference room; on the right, a laptop showing a remote participant on a video call next to a slide titled "A Controversial Proposal: Public Workflow".

Thanks to NodeSource for the photo composition from the summit (London, April 14–15) 🙌

The session I keep thinking about was the one on security. Rafael Gonzaga walked us through the current state of vulnerability reporting, and the numbers tell the story on their own: 352 reports in two years, with a 4.6x spike after AI agent teams arrived in February 2026. In March alone, 65 reports. We have tried raising signal thresholds, auto-closing low-quality reports, expanding the threat model, and pausing the bounty program. None of it has been enough.

That led to a controversial proposal: move most reports to a public workflow. The logic is uncomfortable but hard to argue with. If any capable LLM can reproduce the same findings on demand, treating them as private secrets only gives a false sense of security. Our 90-day disclosure window offers little protection when the "vulnerability" can be re-discovered in minutes, while a public fix can ship in a regular release the next day.

The same LLMs driving this flood are useful on the defense side too. I use them daily to validate patches and to scan for things I might have missed. During the summit alone, two new issues in userland projects surfaced and are now being patched. The tools cut both ways.

My take: the current system is not sustainable, and not just for Node.js. So far we have never shipped unpatched CVEs on active Node.js versions. That might change. We will likely start seeing major projects carrying known vulnerabilities on their latest releases, simply because triage capacity cannot keep up. It is already broken for maintainers. It will be broken for users soon too. Maybe that is what finally pushes companies to invest in the security work they quietly rely on every day.

The full session, including the open discussion with collaborators, is worth watching:

Security was not the only thread. We also worked through an AI contributions policy that keeps humans accountable for whatever they submit, led by Jacob Smith, and landed a contributing guide for large pull requests to set clear expectations for big changes. The move to a new release schedule is becoming real, with version numbers aligning to the calendar year starting with Node.js 27, building on the shift we flagged last issue.

A couple of sessions stood out to me personally. I have big expectations for how Node.js Collaboratorship evolves, it might be the thread I am most curious about for the long-term health of the project. And a big thank you to Santiago Gimeno for the libuv V2 overview and context. libuv has always been a beautiful, esoteric mystery to me, the kind of thing that amazes and slightly intimidates me at the same time, so finally getting a guided tour was a real treat.

There was plenty more on the agenda:

The official recap and Rafael's write-up have the full picture. Every session was recorded if you want to dig in.

🔐 Security Updates

If the summit gave us the ecosystem-level view, my own triage queue tells the same story up close. Across Lodash and Express, we have handled 120 reports in the last two years, and 7 out of 10 turn out to be invalid. The spike in early 2026 says it all: LLM-generated reports are flooding open source projects with noise. Most are untested, out of scope, or duplicates. March 2026 alone brought 40 reports, and only 7 were accepted.

A clear threat model helps. It lets us close most invalid reports quickly, which is exactly why we documented Lodash's threat-model exclusions for the most common report patterns. But every single report still has to be read, understood, cross-referenced, and answered. That is volunteer time from many people, not spent shipping releases, landing features, or fixing real bugs.

To stay on top of it, I turned the small tool I had been using to track advisories during the spike into something more useful: [email protected], a self-hosted Grafana dashboard for GitHub Security Advisories. It is built for CNAs, maintainers, and security teams coordinating disclosure across many repos, and the goal was simple: make advisory data visible without standing up yet another heavy platform to operate.

The ghsa-dashboard GHSA Overview in Grafana, showing 18 panels: totals by state, severity breakdown, CVSS and CWE rankings, throughput over time, time-to-publish and time-to-close trends, aging advisories, and top reporters and repositories.

ghsa-dashboard: from clone to a populated 18-panel overview in minutes (shown here with mock data).

It ships pre-provisioned, so you go from clone to a populated dashboard in minutes: state distribution, severity, CVSS, CWE ranking, throughput, time-to-publish, and aging in triage. It uses plain Postgres and SQL mirroring the GitHub API one to one in a single table, multi-org filtering from a Grafana dropdown, and just two containers plus a roughly 100-line Node scraper. It is MIT licensed, so grab it if it could help with your own triage. It is also, if I am honest, a happy side effect of getting back into homelabbing, more on that below.

And beyond the noise, there were plenty of real vulnerabilities to solve. I helped triage and patch the following CVEs across the ecosystem this period:

fastify

@fastify/express

@fastify/reply-from

@fastify/middie

@fastify/static

@fastify/accepts-serializer

fast-uri

webpack-dev-server

multiparty

morgan

None of this is unique to our corner of the ecosystem. A recent CSA report on what they call the "AI vulnerability storm" puts it bluntly:

We cannot outwork machine-speed threats. Re-prioritize, automate, and prepare for burnout.

They note that existing CVE and NVD infrastructure was "built for dozens of critical CVEs per month, not hundreds," and that Linux kernel maintainers watched their vulnerability reports climb from 2 to 10 per week. The numbers differ, the pattern does not.

Our current tooling was never designed for this volume, and it is directly degrading the capacity of the ecosystem to sustain itself. So I am investing time in better ways to manage a constant stream of noise that shows no sign of stopping, including LLM-assisted triage. The industry is rethinking the publish path too: npm just shipped staged publishing, adding a human approval checkpoint before a release goes live. You can follow every advisory we publish through the OpenJS CNA feed, and the Express monthly security releases continue.

📚 What Else?

May was Maintainer Month, and this year it felt different. It is still a celebration, but more than ever it also felt like a call to team up. The saturation is real, a lot of maintainers are burning out and struggling, and that sadly tracks with the wider picture right now. Keeping open source healthy is collective work, and one of the most direct ways companies can help is by backing the maintainers behind the tools they depend on. The OSI also marked the month with a good reminder of who actually keeps the lights on.

On the policy front, age assurance laws are starting to reach open source. New proposals would push age attestation down to the operating system level, and that matters for the many community-run, volunteer-maintained operating systems out there. The OSI is doing solid work putting maintainers and the open source community into these conversations, alongside the Apereo Foundation, the EFF, the FreeBSD Foundation, and OSTIF. The concern is structural: regulation is touching open source more than it used to, and if these projects get folded into new laws on the same terms as large commercial vendors, the compliance burden could quietly price out exactly the volunteer projects that everyone else builds on. If you want the developer-first version of all this, the GitHub Maintainer Month panel is a great primer:

On the tooling side, NodeSource launched the N|Solid IDE at Web Summit. It brings production telemetry straight into your editor, so you can debug an application with real runtime context without constantly switching back to a dashboard. It ships as a VS Code extension today, with support for other editors on the way.

I also spent time recently with the Orbitant team on their skills marketplace. I learned a lot about AI along the way, especially about making it accessible as a consistent tool for a whole team instead of a pile of one-off prompts. After a good deal of experimenting, we cracked brandable image generation, not just text: a mix of Node and sharp, some contextual prompting (including scraping reference images), and careful tuning for nano banana and friends. Turning a fuzzy "make it on-brand" into something repeatable was the fun part.

On a more personal note, I am back to homelabbing, and that advisory dashboard was one of the first things to come out of it. Back in 2021 I ran a Raspberry Pi cluster, a fun but fairly basic first attempt. A few years on the Node.js Build team taught me a lot about running real infrastructure, so this time I am building something more capable from scratch. The plan is to open source each piece as I go, the self-hosted services, dashboards, and automation that keep it running, so anyone can clone a setup and spin up their own. I even started exploring Fedora. 🤯

🎖️ Awesome People Doing Awesome Things

Sarah Gooding pushed back on the "open source is broken" narrative with a piece I keep coming back to, "Don't Kill the Goose That Lays the Golden Eggs." Her point lands right in the middle of everything in this issue: open source is not under attack because it is failing, it is under attack because of how much value it creates. A 2024 Harvard study put the demand-side value of widely used open source at $8.8 trillion, much of it still carried by unpaid solo developers. As she puts it, that is "an argument for supporting it, not declaring it dead." Exactly.

Pelle Wessman is asking for feedback on the collective-funds guidelines, an effort to capture best practices for how open source projects actually use their funds. He and others started it a couple of years ago to help projects like Mocha align around a shared approach. This is harder than it sounds. Funding in open source is not only about raising more money or landing more sponsors, it is about deciding how to distribute what you already have. That is a genuinely open debate, made harder by the fact that we all bring different cultural, ethical, and social backgrounds to the table, so our individual relationship with money can vary a lot. Initiatives like this one try to solve part of that problem, and they only get better with more eyes on them. So if you have ever wondered how open source money should be shared, go give Pelle your feedback.

🔗 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