How we handle security releases
In one week of October 2026, Node.js and Next.js both shipped serious security fixes. Here is what we patched, how fast, and how each deploy proved it was live.
Every site we build runs on two pieces of open-source software: Node.js runs the server, and Next.js renders the pages. In the second half of October 2026 both projects published security fixes: Node.js rated its issues high, and Next.js rated two of its issues critical. This post describes what we did about them, including the part where we were late.
Node.js 24.22.1, patched on 22 October
On 21 October Node.js published security releases 22.23.4, 24.22.1 and 26.12.1. The highest severity fixed was high, and four issues carried it:
an out-of-bounds write in the Brotli decoder that permits remote code execution (CVE-2026-111497);
a DNS issue with NUL characters (CVE-2026-105482);
two ways to bypass TLS hostname checks (CVE-2026-105483 and CVE-2026-106069).
We run Node 24, so our fixed version is 24.22.1.
Our servers run inside Docker images built on the official node:24-alpine image. The day after the release, we rebuilt and redeployed every service that runs on Node: the API, the notification service, the admin panel and every client site.
The rebuild found a weakness in our own pipeline. A build could reuse a base image cached on the build machine, so "rebuilt" did not guarantee "rebuilt on the patched Node". We added --pull to the build step of every pipeline and to the template new sites start from. A build now always fetches the current base image, and the build log records which one it used. We checked the log of every redeploy for the patched image before calling the work done.
Next.js 16.4.2, patched on 23 October
On 14 October the Next.js team published three advisories, fixed in version 16.4.1:
two critical ones that let an attacker run code on the server without logging in: one in cached functions that return typed arrays, one in image optimisation when SVG files are used;
one high-severity denial of service through Server Actions.
We found them on 23 October, nine days after they were published. The entries in the global GitHub Advisory Database appeared only on 22 October, which is the most likely reason our automated dependency updates did not raise them sooner. We are now looking at why our update bot missed the original advisories.
The same day, every live site, the admin panel and all three site templates moved to Next.js 16.4.2, the latest release. Each change touched only the Next.js packages; we checked every lockfile against the npm registry before merging. None of our sites allow SVG in image optimisation, but all of them use cached functions, so we treated every site as exposed.
How we know a fix is live
A merged fix only protects anyone once it runs. Every site we deploy through our pipeline answers /api/version with its version and the exact commit it was built from. After each deploy, the pipeline asks the live site that question and fails the build if the answer is not the new commit. Every security deploy above passed that check before we marked it done.
One older site builds on a separate pipeline that does not have this check yet. It was rebuilt and deployed, but its live version was not checked automatically.
What you need to do
Nothing. If your site runs on CMS Craft, it was patched as described above. If you want to see it for yourself, open https://your-site.com/api/version and compare the date with this post.