Node.js shipped security releases on March 24 for every active line, 20.x through 25.x: two high severity issues, five medium, two low. The two high ones are both crashes a remote client can trigger with malformed input a server should have rejected. The medium ones include a permission model bypass, a timing weakness in signature verification, and a memory leak in HTTP/2 handling.
The detail I find most instructive is that two of the nine are bypasses of earlier fixes. One high severity crash is an incomplete earlier fix. A low severity file permission gap was left by a 2024 fix that patched the callback versions of two operations and not the promise versions.
I think that is the argument against treating patching as an event. These releases are a reminder that a fix is a claim about one path through the code, not a guarantee about all of them. The next release can reopen the question.
My view is the one I keep coming back to with runtime security: the team needs a routine that gets every Node line it runs rebuilt and shipped within days of a release, every time, with nobody having to decide whether this one matters. The deciding is where the delays come from.
How long after a Node.js security release does your team have it in production?
Photo source: https://photos.robertstowe.com/eclipse