Newsletter #015: A Break from Survival Mode 🥹

Written by Ulises Gascón

Jul 01, 2026 — 14 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. Honestly, this one is a relief to write. It has been a rough, overloaded stretch, but that is finally changing: I have taken on a new role focused entirely on security, and for the first time in ages I have room to build instead of just keeping up. A good chunk of this issue is what that already made possible: an API for the OpenJS CNA I have wanted to build for a long time, a look at how npm@12 blocks install-time attacks while execution-time becomes the next trigger, and the usual heavy run of CVEs.

Let's dive in! ✨

🛡️ A New Chapter: Node.js AI Security Engineer in Residence

I have been appointed the Node.js AI Security Engineer in Residence, a role funded by Alpha-Omega and structured as a partnership between the OpenJS Foundation and NodeSource.

Announcement graphic with the Alpha-Omega, OpenJS Foundation, and Node.js logos and the title "Announcing the Node.js AI Security Engineer in Residence", alongside a photo of Ulises Gascón holding a microphone and a "Meet Ulises Gascón" button.

The announcement graphic, shared by Alpha-Omega.

If you have read the last few issues, you already know the backdrop. The volume of security reports hitting open source has gone through the roof, much of it LLM-generated noise, and the people doing triage are mostly volunteers running on fumes. For a while now, I have been one of them, going from report to report in the cracks between everything else and, honestly, on my way to burnout. What I love is that the grant does not start this work, it makes it sustainable. Now, through the end of the year, I can breathe again: room to think long-term and build proper systems, instead of staying in survival mode. As I put it in the announcement, "this grant lets me do that work properly: with the bandwidth to scale it, share it, and make it useful to maintainers across the ecosystem."

Concretely, the work narrows to three overlapping problems:

  • High-volume AI-generated report intake: triaging and validating a flood of reports faster, without burning out the people on the other end.
  • AI-assisted patch review: using AI as a quality gate that runs alongside human review, rather than as one more firehose of reports.
  • Supply-chain incident response: moving fast when something urgent and high-risk hits.

The throughline across all three is to take real weight off maintainers: coaching them through triage, standing with them during incidents, and leaving behind durable playbooks and an open library of tools so the support outlasts my time in the role.

And I am only one of many. Alpha-Omega funds Security Engineers in Residence (SEIRs) across the open source landscape, and the part I am most excited about is that we are doing this together: aligning, comparing notes, sharing, and learning from each other. That matters more than it sounds. Most security work, surprisingly, happens asynchronously and in isolation, ecosystem by ecosystem. We cross paths in working groups and at events, but having the time and a shared room to actually dig in together is a different thing entirely, and I think it will change how we understand security across the ecosystem.

I am grateful to Alpha-Omega, the OpenJS Foundation, and NodeSource for making it real.

🛠️ Building an API for the OpenJS CNA

The OpenJS Foundation CNA just passed its first year, and the growth has been wild. In all of 2025 we issued three CVEs. This year we are already past 49. We went from occasionally checking the docs to remember how to reserve and publish one, to needing real tooling for the repetitive parts. That is what finally pushed me to build something I have wanted for a while: an API for the OpenJS CNA.

The honest motivation is that I am a bottleneck, and I would rather not be. Today most CVE management runs through a small group of us by hand, which tangles two very different requests: "I need a human expert with this security report" and "I just need a CVE." The API decouples them, letting projects manage their own CVEs directly while keeping the CNA in the loop, so a handful of people stop being the rate limiter for the whole foundation.

The harder part is not the code, it is landing it in open source. This is not a hierarchy where you can simply decide. You have to build consensus, win people over, and actually get the thing adopted, and that is the real work. So I built a fully working PoC before the kickoff session, on purpose: it is much easier to agree on the boundaries and the goals when there is something concrete in front of everyone, before anyone starts arguing about technical details. And because it already works, other SEIRs can pick it up or fork it for their own ecosystems without waiting for our process to land. Now that we are happy with the direction, the plan is to make it real PR by PR. Plenty will change along the way, but technical problems are far easier to solve than disagreements about objectives or philosophy.

The architecture itself is, admittedly, a little exotic: Git as the database, GitHub Actions as the backend, and bucket-and-hash auth with no database and no JWTs, so the repo can even be public without leaking a single credential. The architecture doc has the full tour if that is your kind of fun.

This is a proposal and a kickoff, not something in the real workflows yet, and the backend PoC and client tools are public. What matters most is Node.js itself: the project is on its way to adopting the OpenJS CNA, and we have started a dedicated initiative in the Node.js Security Working Group to fold the new API into its existing security workflows and tooling. Other projects could follow, something Matteo Collina has floated for Fastify and undici. I demoed the whole thing end to end at the OpenJS Security Working Group meeting on June 22 (the CNA part starts around the four-minute mark):

🧨 npm@12 Blocks Install Scripts. That Is Not the Whole Story.

npm@12 is about to ship a meaningful change: install scripts will be disabled by default. No more automatic preinstall, install, or postinstall hooks firing the moment you npm install, including the implicit node-gyp rebuild. Git and remote URL dependencies get the same treatment, gated behind explicit approval. You opt back in deliberately with npm approve-scripts and commit the allowlist to your package.json. This is a good default, and it closes a door attackers have walked through many times.

I wrote up why it is still not a silver bullet. Blocking install scripts only stops install-time execution, but it does nothing about execution-time attacks: the code that runs when you import or require a package in your actual application. Malicious payloads do not need a lifecycle hook. They can sit in top-level module code and fire the first time the package is loaded, fingerprinting the host, harvesting environment variables, and exfiltrating whatever they find. We have already seen this play out: Shai-Hulud moved payloads earlier in the install phase, and the Miasma packages slipped past postinstall restrictions through binding.gyp.

The point is that npm@12 removes a trigger completely, but not a capability. Node's threat model trusts code by default, so a package still ships and still runs the moment you import it, with the full privileges of your process. The real answer is layered: the install-time gate is one control, the Node.js permission model constrains what running code can do, and OS sandboxing and network egress rules decide what it can reach. No single one is a security boundary on its own. The mindset that ties it together is to assume the code is hostile and let the environment, not your goodwill, draw the boundary.

The post was kindly featured in Node Weekly and JavaScript Weekly. With the new role giving me more room, I have more security-focused blog posts and videos planned soon.

📦 Release Backlog Updates

Here is what I released recently:

Security Releases

🔐 Security Updates

Another busy period on the security front. I helped triage and patch 13 CVEs across the ecosystem, with undici accounting for eight of them and a critical middleware bypass in @fastify/express as the standout.

undici

  • CVE-2026-9697 — High-severity. ProxyAgent silently drops the requestTls option with a SOCKS5 proxy, falling back to Node's default trust store and ignoring user TLS settings (GHSA-vmh5-mc38-953g)
  • CVE-2026-6734 — High-severity. Socks5ProxyAgent reuses a single connection pool across origins without verifying the pool's origin (GHSA-hm92-r4w5-c3mj)
  • CVE-2026-9675 — High-severity. The WebSocket client does not enforce a cumulative size limit on fragmented messages, allowing memory exhaustion via many small fragments (GHSA-38rv-x7px-6hhq)
  • CVE-2026-12151 — High-severity. The WebSocket client fails to limit fragmentation count, allowing memory exhaustion via unbounded continuation frames (GHSA-vxpw-j846-p89q)
  • CVE-2026-9678 — Medium-severity. The cache interceptor mis-classifies whitespace-padded Cache-Control directives as cacheable, serving authenticated data from a shared cache (GHSA-pr7r-676h-xcf6)
  • CVE-2026-9679 — Medium-severity. parseSetCookie percent-decodes cookie values, enabling HTTP response header injection when parsed cookies are forwarded into response headers (GHSA-p88m-4jfj-68fv)
  • CVE-2026-11525 — Low-severity. SameSite is matched as a substring rather than an exact value, allowing a cookie security policy downgrade (GHSA-g8m3-5g58-fq7m)
  • CVE-2026-6733 — Low-severity. The HTTP/1.1 client is vulnerable to response queue poisoning on reused keep-alive sockets (GHSA-35p6-xmwp-9g52)

@fastify/express

  • CVE-2026-6556 — Critical-severity. Non-string mount paths (arrays and RegExp) are not rewritten to include the Fastify plugin prefix, allowing a middleware bypass that can expose protected routes in prefixed plugins (GHSA-3wf5-7852-vcfq)

fast-uri

  • CVE-2026-13676 — High-severity. Fails to canonicalize Unicode/IDN hostnames for HTTP URLs, allowing host-based policy bypass via a canonicalization mismatch with Node's URL parser (GHSA-4c8g-83qw-93j6)

webpack-dev-server

  • CVE-2026-9595 — Medium-severity. A user-configured broad-context WebSocket proxy can intercept the dev server's HMR WebSocket, leaking browser credentials and bypassing origin validation (GHSA-mx8g-39q3-5c79)

multer

  • CVE-2026-5079 — High-severity. Deeply nested field names in multipart form data consume excessive CPU and memory, causing denial of service (GHSA-72gw-mp4g-v24j)
  • CVE-2026-5038 — Medium-severity. Aborted or malformed multipart uploads leave orphaned partial files accumulating on disk when using diskStorage (GHSA-3p4h-7m6x-2hcm)

On the coordination side, the Express team's June security releases bundled the multer fixes above alongside a morgan update, part of the steady monthly cadence we have kept up.

📚 What Else?

The big gathering this period was the second edition of United Nations Open Source Week, at the UN headquarters in New York in late June, and I think open source came out of it very well represented. Germany's Sovereign Tech Agency brought a delegation of nine maintainers and co-ran a second Maintain-a-thon with the UN Office for Digital and Emerging Technologies, putting the people who actually build and maintain critical infrastructure in a room where it is usually discussed without them. Several reflections came out of the week, each worth reading for a different reason. Mirko Swillus writes for Alpha-Omega on why human trust, not more automation, is the durable answer to the LLM vulnerability flood, and on the Security Engineers in Residence program, around 30 paid experts across ten ecosystems, that funds my new role. Andrew Nesbitt makes the case for taking "roads and bridges" literally, swapping goodwill sponsorship for the mandatory inspections and service contracts that keep real infrastructure standing. And Seth Larson connects open source to the UN's Sustainable Development Goals and asks the question that sits at the center of my own work: if public LLMs can surface vulnerabilities regardless of any embargo, who does the secrecy of coordinated disclosure actually protect?

On the Express side, cookie shipped its 2.0.0 release and is now ESM-only, with more libraries set to follow and releases now going out through GitHub Actions. That nudged me to open an issue to revisit our npm publishing posture in the OpenJS Security WG. When we first wrote our guidance on publishing securely, staged publication was one of the major blockers we ran into. npm has since shipped exactly that, so it feels like the right time to update where we stand.

James Snell is looking to advance the TC-39 Error code property proposal at next month's plenary, a small but useful addition to error handling, and he wrote up a fun thought experiment asking what npm might look like if it ran on AT Protocol. I think it is a great exercise to get familiar with the protocol, and a good reminder that decentralized resources might be the right choice more often than we think. Andrew Nesbitt goes deeper on the practical trade-offs in his deep dive into federated package management.

Finally, on the tooling side, the NodeSource Dev Sessions team published a follow-up to their N|Solid IDE work, this time digging into how the extension was actually built. Estefany Aguilar sits down with Cesar Diaz to walk through the architecture behind bringing production debugging into VS Code, Cursor, and Windsurf in a few weeks, leaning heavily on MCP-powered workflows and AI-assisted development. The recurring theme: AI accelerates iteration, but planning matters more than ever.

🎖️ Awesome People Doing Awesome Things

A few months ago I found the SISTECH LAB channel, and it stood out fast: there are not many Spanish channels explaining electronic engineering at this level, and for actual humans. This video walks through the full journey from a roughly working prototype to a finished product, designing the PCB in KiCad and prepping it for manufacturing. It is a great reminder of how much the stack and tooling have evolved over the last decade, and that shipping hardware is still very serious business.

Javier Sáez Gallego built an eclipse visualizer that maps exactly where and when a solar eclipse will be visible from any point on the map. I am planning to watch the total solar eclipse crossing northern Spain on August 12, and his tool made it much easier to picture how it will unfold from my area and find the perfect spot. I even scouted a few locations ahead of time by checking dates when the sun followed a similar trajectory. With all the sky events this year, I think I might have a new hobby 🔭.

🔗 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