Node.js shipped security releases on January 13 for every active line: 25.x, 24.x, 22.x, and 20.x. Three high severity issues, four medium, one low.
Two of the high severity fixes are worth reading even if you never look at release notes. One is a permission model bypass: a script granted file access only to its current directory could escape it with crafted symlinks. The other is a crash from a malformed HTTP/2 HEADERS frame that takes down the whole process instead of closing one connection. A medium one makes a stack overflow uncatchable when async_hooks are in use, which is the machinery under AsyncLocalStorage and a lot of tracing and monitoring libraries.
The release was first announced for December 15 and landed a month later. I think that is the part for managers. If a team's patching plan is to update when Node updates, the project's calendar is the team's calendar, and it moves.
My view is that a runtime patch should be a routine the team owns: a known path to rebuild and ship every Node line it runs, within days, without anyone being a hero. The vulnerabilities change every time. The routine should not.
How long does it take your team to get a Node security release into production?
Photo source: https://photos.robertstowe.com/dolomites