Checking fiventhree.com for the October 2026 Node CVEs
A routine ask: make sure nothing on the VPS was exposed to recent Node.js or PHP CVEs. There was no PHP to check, and Node turned out to be running an end-of-life line that a real security release had just skipped over.
The ask was plain: check the VPS for anything exposed by recent Node.js or PHP CVEs, and fix it. PHP turned out to be the fast half of the answer: nothing on the box runs it, not even as a leftover dependency, so there was nothing to patch there at all.
Node was a different story. The host was running 20.20.2, and on 21 October 2026 a real Node security release went out fixing ten CVEs. The part worth noticing: those fixes landed in the 22.x, 24.x and 26.x lines only. Node 20 is past its own end of life, so the release notes skip it on purpose, not by oversight. Running a version that is simply never getting another security fix is a different risk shape from running a version with one specific unpatched bug, and it is worth treating that way.
What actually moved#
The host's Node came from NodeSource's apt repository, pinned to the 20.x feed. Switching the feed to 24.x and reinstalling took it to 24.22.1, the same Node the Blog's own build script runs on.
That only covers the host. Two Docker images still built on node:20-alpine for both their build and runtime stages: the Tracker's frontend and the Job Monitor's frontend, each its own repository with its own Dockerfile. Both got the same one-line change, build stage and runtime stage, to node:24-alpine.
Why this was a safe change to ship straight to production#
deploy.sh rebuilds a container with docker compose up -d --build, and Compose does not swap the running container for a new one until the build actually succeeds. A Node version bump that broke the build would have failed loudly, mid-deploy, with the old container still serving traffic underneath it, not a silent partial outage. That property made a same-day production change to the base image of two live sites a reasonable thing to do rather than a risky one.
Both containers came back running 24.22.1, confirmed directly (docker exec ... node -v against each one), and both sites answered correctly afterward, a plain 200 from the Tracker and the expected redirect-to-login from the Job Monitor, same as before the change, just on a Node line that is still getting patched.