Patch week for Node.js, Python and Next.js: my update routine on production servers

In a single week Node.js, Python and .NET shipped security fixes, and Next.js released a backport of bug fixes to its supported branch. If you have your own server, website or integrations, something has to be done, and the person responsible for the server has to do it, in an order they know in advance. Below is what came out and how I update.

What came out

On October 21, Node.js published three security releases: 26.12.1, 24.22.1 LTS and 22.23.4 LTS. 26.12.1 closes nine CVEs, 24.22.1 eight, 22.23.4 seven. Each line has High-severity issues: tls rejecting non-canonical IP addresses, dns checking resolve input for null bytes, and a hole in Brotli decompression, CVE-2026-111497. All three releases update the root certificate list to NSS 3.131.1 and reject chains with blocked public keys. The release notes don't give the reason, but by the dates it is the eMudhra certificate authority story I wrote about a few days earlier.

On October 25, Python released 3.14.10 and 3.13.18. Both are expedited releases, and the reason is eMudhra: the ssl module now blocks the compromised keys, and plain pip, including updating pip itself, is protected from attacks with those keys even if pip hasn't been updated yet. 3.14.10 also carries about 120 fixes from 63 contributors and a closed hole in tarfile.tar_filter, CVE-2026-114583. The 3.13 branch is already in security-fixes-only mode until October 2028; there are no installers for it anymore, only source.

On October 25, Microsoft released out-of-band .NET updates: 8.0.33, 9.0.22, 10.0.14 and .NET 11 RC3. It is the same CVE-2026-111497 in Brotli as in Node.js: a buffer overflow during decompression that reads or corrupts process memory. In .NET it only triggers where the application decompresses Brotli: in ASP.NET Core request decompression, in HttpClient's automatic response decompression or through System.IO.Compression. The same post has a list of actions that works beyond .NET: framework-dependent applications update the runtime and restart, self-contained ones get rebuilt, containers get rebuilt from updated images.

On October 23, Next.js released 16.4.3. It is a backport of fixes to the active LTS branch, with no new features; the fixes include Google font URLs and OpenTelemetry traces. It says nothing about security. My site kononov.dev runs on Next.js and Node.js 24, so this update lands in the same cycle as Node.

Why updates get postponed

Take a service company of 30 people. It has a website, an app for salespeople, telephony and document parsers, all on one server. Updating Node.js means restarting the API that both the website and the app run through. Customers call during the day, nobody is around to watch at night, and the update gets pushed to next week. A month passes that way, then the next batch of patches comes out, and now you need to jump two versions at once.

The conclusion: updates get postponed when they haven't been rehearsed. If the order is known and takes an hour, it gets done the same day.

How I update

My servers: a PDR company in the US, where a Node.js API, the website, telephony and Python document parsers run on Debian in Google Cloud; a manufacturing company, where order calculation lives on a server with Node.js and Express under PM2; my site on Next.js and Node.js 24 in Docker; and the “Coffee Together” service on the same shared studio server with 2 GB of memory. The order is the same everywhere.

Inventory first. I write down which runtime version is where: in the system, in each Docker image, in the parsers' virtual environment. Without that list there is no way to say whether the holes closed in the release are closed on our side.

Then I read what was fixed and check it against my code. Brotli is decompressed wherever an HTTP client accepts compressed responses, so it concerns the API and everything that calls external services. The dns hole concerns everything that resolves addresses from user data. That makes it clear what to update first.

Then the build. For containers I change the base image, build and run the application locally. On the studio server the build sometimes runs out of memory, so I build the image elsewhere and upload it ready. The previous image stays in place so there is something to roll back to.

Startup. In “Coffee Together” the old instance stops before the new one starts during an update: two copies are a tight fit in 2 GB, so the containers have hard memory limits. For the parsers I first check that nothing is hanging in processing, and only then restart.

After startup I look at the logs and run one working scenario by hand. If something is off, I bring back the previous image. Once the order has been rehearsed, the whole patch week fits into a few hours.

What I would do in your place

Ask whoever runs the server which versions of Node.js, Python or .NET you have and exactly where. If there is no answer within a day, that is the first problem.

Agree on an update window: when the system can be restarted and who checks that it came back up.

Ask for updates to go through rebuilding images, with the previous version kept at hand.

Write the order down once. Next time a week like this comes around, you will need it again, and the update will take an hour.

On how background jobs survive a restart: the article Workers: background jobs and retries. Infrastructure that can be released and restored: DevOps and infrastructure. The server and API in question are described in the technical partner to a PDR company case and on the page about a custom API for several applications. From neighboring reviews: PHP2Shell and checking your own servers, the blast radius of an update and the backup nobody ever restored; earlier I wrote about releasing a Docker application with a version rollback. If you have a server and no update routine, tell me what runs on it and I'll suggest where to start. Discuss your task.