If your app runs on Node.js, update it this week

If you have a web app, an API or a self-hosted tool that runs on Node.js, update Node this week. On 21 October the Node.js project fixed ten security flaws, and the worst of them could let an attacker run their own code on your server.

After a week of PHP, I know nobody wants to hear about another update. This one is calmer. There's no mention of attacks so far. But it's worth half an hour to check where you stand.

What happened

The Node.js security release put out new versions for every release line the project still supports: 22.23.4, 24.22.1 and 26.12.1.

The one that matters most is CVE-2026-111497, a flaw in the code Node uses to unpack Brotli, a common compression format on the web. Node says that an attacker who can feed your app Brotli data it decompresses "can corrupt process memory, which can lead to a crash, disclosure of process memory, or remote code execution."

Node rates it high. Singapore's Cyber Security Agency, in its alert on 23 October, gives it 9.8 out of 10 and advises updating "immediately".

The other nine fixes are smaller. Three more are rated high: two tricks that get round the check that a secure connection is going to the right place, and a DNS lookup bug. Node lists no workarounds for any of them.

Does it affect you?

Node.js sits underneath far more things than people realise. Custom web apps and APIs, self-hosted Next.js sites, and plenty of open-source tools, including Uptime Kuma, which I mentioned in my post on building my own server monitor.

You're on a managed platform. Check your provider's notes. Vercel's bulletin, for example, says projects on Node 22 or 24 don't need to change anything, but projects on Node 20 need moving to 22 or 24 and redeploying.

You run Node on your own server. This one's yours. The fix only helps once it's installed and your app has been restarted.

You're on Node 20 or older. Node 20 reached end of life on 30 April 2026, according to the project's release schedule, so there's no upstream fix for it. Node's advisory says end-of-life versions "are always affected" when a security release comes out. Moving to 22 or 24 is the answer, and that's a bigger job than an update.

What to do this week

1. Find out which version you're running. On the server:

node -v

Anything below the fixed versions above needs updating. Don't forget servers where Node runs an app quietly in the background. This lists Node processes running right now:

ps aux | grep -i node

2. Check your Docker containers separately. A container carries its own copy of Node, so updating the server does nothing for it. For each one:

docker exec <container-name> node -v

If it's your own app, rebuild the image on a fixed Node version and redeploy. If it's someone else's open-source tool, pull their latest image once they've released one, and recreate the container.

3. Update Node the way you installed it. If you used the NodeSource packages on Debian or Ubuntu, sudo apt update && sudo apt upgrade will pick up the new version. If you used nvm, install the new version and switch your app over to it. If you downloaded it from nodejs.org, download the new one.

4. If you use your distribution's own Node, it's a bit different. Debian's security tracker notes that its Node.js packages use the system Brotli library, and lists that library as fixed in Debian 12 and 13. So installing your normal security updates should cover the Brotli flaw there. When I checked Ubuntu's CVE page on 24 October, every release was still listed as "Needs evaluation". Keep an eye on it and install the update when it arrives.

5. Restart your apps. Like PHP last week, a running Node app keeps using the old code until it restarts. If you use pm2, pm2 restart all does it. If your app runs as a systemd service, restart that. Then run node -v again and check the number.

6. Test something afterwards. A minor update within the same line rarely breaks anything, but load the site, log in, and check the bits that make money still work.

Why this one is easy to miss

Most servers get their updates through the system package manager, and plenty of Node installs don't. They came from nvm, a download or a Docker image, so normal security updates never touch them. That's an easy way for a Node server to end up a long way behind without anyone noticing.

The same goes for Docker. A container built last spring is still running last spring's Node, however up to date the server underneath it is.

The bigger point

None of this needs heroics. It needs someone to know which servers run Node, where it came from, and who's going to update it and restart the app.

If nobody in your business is going to do that, that's what a support retainer is for. I keep your servers updated, restart what needs restarting, and tell you about it in plain English.