You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[NEXT-SECURITY-RELEASE] Heads up on upcoming Node.js security release 2025/12/15 #2330
Will all of the supported images be updated rather soon? I kind of expected to have the new images by the time it got public to update immediately but it seems its not the case yet
Also waiting for the builds to be updated in docker and surprised they aren't there. I have no idea how this process works, but it looks like the action that opens the automated PR with the updates is getting blocked by the fact that the latest versions don't have a "musl" release yet on https://unofficial-builds.nodejs.org/download/release/index.json.
Maybe that's just normal and something that takes time? The fact it's "unofficial" makes me wonder though if a step has been missed? Or do we just have to wait?
Reacted by Takumi Oyamada and Matheus Robert Lichtnow
Would it be possible, in general and for future releases, to de-couple the release of official builds from unofficial builds, so that releasing official builds is never held up because of problems with prerequisites for unofficial builds?
Yeah, this really needs to be cut alongside the release if possible - many people deploy to production on these images. There should be coordination here.
Can someone point me to documentation that explains the rough workflow for a new docker NodeJS release so I can understand this unofficial/official build problem better?
Because I'm a bit shocked to learn that NodeJS docker images are not available for around 24h after CVE fixes got released + the big blog entry dropped that urges to update ASAP.
I would have assumed that the docker images are published either together or a few hours after the binaries dropped, as they are understandably needed for the docker images themselves.
Reacted by Nik, Mikael Mattsson, K.Matsuzawa, Rafael Violato, Matheus Robert Lichtnow, Théo LUDWIG, Nicolas Morel, hehe, Mayank Chauhan, Pavan Prakash and 14 more
Can someone point me to documentation that explains the rough workflow for a new docker NodeJS release so I can understand this unofficial/official build problem better?
Because I'm a bit shocked to learn that NodeJS docker images are not available for around 24h after CVE fixes got released + the big blog entry dropped that urges to update ASAP.
I would have assumed that the docker images are published either together or a few hours after the binaries dropped, as they are understandably needed for the docker images themselves.
Code is inspectable in this repo, nodejs/docker-node/build-automation.mjs. to put it short, the -alpine variant requires MUSL build from the unofficial repo. If for some reason this MUSL build does not exist for that version (e.g., 22.x), all variants of that version is deferred/skipped (this includes all debian & debian-slim). This is probably to prevent the split-version scenario (e.g., 22-alpine points to 22.21.1 while 22-trixie points to 22.22.0)
The unofficial build is slow and sequential. as of now 20.20 is still running and 24.13 is in queue
Can someone point me to documentation that explains the rough workflow for a new docker NodeJS release so I can understand this unofficial/official build problem better?
Because I'm a bit shocked to learn that NodeJS docker images are not available for around 24h after CVE fixes got released + the big blog entry dropped that urges to update ASAP.
I would have assumed that the docker images are published either together or a few hours after the binaries dropped, as they are understandably needed for the docker images themselves.
Glad there is recognition of chicken and egg here. Yes, there will always be a critical path of infrastructure that coincides with any release. They stack up then when a security event creates four. I suppose the blog post could wait until after docker is ready, but then we are not communicating availability. On balance, that might be better, given the creation of urgency in the current sequencing. I've shared this feedback and thread with a broader team.
Reacted by Harta Angkasa, fbjaras, Claudio Wunder, Sylvestre Bouchot, Diesmon, Cilooth and Hugo Maestá
@MikeMcC399 Can you create an issue describing the workflow you'd like to see in #2330 (comment)? I think that should be certainly doable (I don't want to take attribution for the idea). Otherwise let us know and we'll create.
Can you create an issue describing the workflow you'd like to see in #2330 (comment)? I think that should be certainly doable (I don't want to take attribution for the idea). Otherwise let us know and we'll create.
You're right that this should be separated out from this issue which is about the current security release only.
I would be far happier if somebody from the core team picked this up, as I don't have in-depth experience and understanding of how this all fits together. I'm not worried at all about attribution!
It's more than 24 hours since the build started. I don't want to point fingers and show problems so can someone tell us how can we help make this fast going ahead? My company can give coding help or money to get faster servers.
ERROR: failed to build: failed to solve: node:25.3.0-alpine: failed to resolve source metadata for docker.io/library/node:25.3.0-alpine: docker.io/library/node:25.3.0-alpine: not found
λ docker run --pull=always -it --entrypoint=/bin/bash node:20-trixie-slim
20-trixie-slim: Pulling from library/node
Digest: sha256:82dc9bc5be425c01adeaf315b0b54bcf5dd3d75d6a6ebb69906590439e3b5a10
Status: Image is up to date for node:20-trixie-slim
root@f04afff0afa8:/# node --version
v20.19.6
root@f04afff0afa8:/# env | grep NODE_VERSION
NODE_VERSION=20.19.6
It works for node:20
λ docker run --pull=always -it --entrypoint=/bin/bash node:20
20: Pulling from library/node
Digest: sha256:d27ddcc66c7a184e7d5023fe77c853f4b4f9292c3a2a65ff8378ff273edae9d3
Status: Image is up to date for node:20
root@fcfa3605c329:/# node --version
v20.20.0
root@fcfa3605c329:/# env | grep NODE_VERSION
NODE_VERSION=20.20.0
λ docker run --platform=linux/amd64 --pull=always -it --entrypoint=/bin/bash node:20-trixie-slim
20-trixie-slim: Pulling from library/node
Digest: sha256:82dc9bc5be425c01adeaf315b0b54bcf5dd3d75d6a6ebb69906590439e3b5a10
Status: Image is up to date for node:20-trixie-slim
root@85a4afd53c5f:/# node --version
v20.20.0
Activity
MikeMcC399 commentedon Jan 9, 2026
@marco-ippolito
The security release has been delayed multiple times so that it is now going to be almost one month late (see https://nodejs.org/en/blog/vulnerability/december-2025-security-releases).
Will the release only address the security issues mentioned or it is going to include also other commits, such as an update to the version of npm?
marco-ippolito commentedon Jan 9, 2026
It will include a few more commits
RafaelGSS commentedon Jan 13, 2026
Security release is now available.
adrianvaillant commentedon Jan 13, 2026
Will all of the supported images be updated rather soon? I kind of expected to have the new images by the time it got public to update immediately but it seems its not the case yet
marco-ippolito commentedon Jan 13, 2026
Security release is out
latentflip commentedon Jan 13, 2026
Also waiting for the builds to be updated in docker and surprised they aren't there. I have no idea how this process works, but it looks like the action that opens the automated PR with the updates is getting blocked by the fact that the latest versions don't have a "musl" release yet on https://unofficial-builds.nodejs.org/download/release/index.json.
Maybe that's just normal and something that takes time? The fact it's "unofficial" makes me wonder though if a step has been missed? Or do we just have to wait?
takumi0706 commentedon Jan 13, 2026
@latentflip You're right - unofficial-builds is missing the musl builds for this security release.
I've opened nodejs/unofficial-builds#199 to request the missing builds.
MikeMcC399 commentedon Jan 13, 2026
Would it be possible, in general and for future releases, to de-couple the release of official builds from unofficial builds, so that releasing official builds is never held up because of problems with prerequisites for unofficial builds?
https://github.com/nodejs/unofficial-builds/ links to https://unofficial-builds.nodejs.org/ and shows:
switz commentedon Jan 13, 2026
Yeah, this really needs to be cut alongside the release if possible - many people deploy to production on these images. There should be coordination here.
yzhe554 commentedon Jan 14, 2026
25.3.0 and 22.22.0 have done. It's building 20.20.0 now
mdavidsen commentedon Jan 14, 2026
20.20 is still building, and 24 is still not started according to https://unofficial-builds.nodejs.org/logs/
Diesmon commentedon Jan 14, 2026
Can someone point me to documentation that explains the rough workflow for a new docker NodeJS release so I can understand this unofficial/official build problem better?
Because I'm a bit shocked to learn that NodeJS docker images are not available for around 24h after CVE fixes got released + the big blog entry dropped that urges to update ASAP.
I would have assumed that the docker images are published either together or a few hours after the binaries dropped, as they are understandably needed for the docker images themselves.
loganaden commentedon Jan 14, 2026
A lot of apps are still on 20 LTS releases.
ItsHarta commentedon Jan 14, 2026
Code is inspectable in this repo, nodejs/docker-node/build-automation.mjs. to put it short, the -alpine variant requires MUSL build from the unofficial repo. If for some reason this MUSL build does not exist for that version (e.g., 22.x), all variants of that version is deferred/skipped (this includes all debian & debian-slim). This is probably to prevent the split-version scenario (e.g., 22-alpine points to 22.21.1 while 22-trixie points to 22.22.0)
The unofficial build is slow and sequential. as of now 20.20 is still running and 24.13 is in queue
bmuenzenmeyer commentedon Jan 14, 2026
I opened #2345
edit (my two cents as a website maintainer):
Glad there is recognition of chicken and egg here. Yes, there will always be a critical path of infrastructure that coincides with any release. They stack up then when a security event creates four. I suppose the blog post could wait until after docker is ready, but then we are not communicating availability. On balance, that might be better, given the creation of urgency in the current sequencing. I've shared this feedback and thread with a broader team.
7 remaining items
adrianvaillant commentedon Jan 14, 2026
Ahh all right, thanks for clarifying!
mcollina commentedon Jan 14, 2026
@MikeMcC399 Can you create an issue describing the workflow you'd like to see in #2330 (comment)? I think that should be certainly doable (I don't want to take attribution for the idea). Otherwise let us know and we'll create.
MikeMcC399 commentedon Jan 14, 2026
@mcollina
You're right that this should be separated out from this issue which is about the current security release only.
I would be far happier if somebody from the core team picked this up, as I don't have in-depth experience and understanding of how this all fits together. I'm not worried at all about attribution!
adityapatadia commentedon Jan 14, 2026
It's more than 24 hours since the build started. I don't want to point fingers and show problems so can someone tell us how can we help make this fast going ahead? My company can give coding help or money to get faster servers.
hmaesta commentedon Jan 14, 2026
FYI, it appears all Node versions released yesterday were built and are already available (including v25.3.0)
loganaden commentedon Jan 14, 2026
not all of them are available on dockerhub. i can't see the alpine ones ?
hmaesta commentedon Jan 14, 2026
Yup... Too soon! (Sorry!)
I just tried building the image and got a 404.
rubnogueira commentedon Jan 14, 2026
That is not true:
danpasecinic commentedon Jan 14, 2026
They have just pushed all images.
nschonni commentedon Jan 14, 2026
https://hub.docker.com/_/node/tags appear to be there now, so closing
heydonovan commentedon Jan 14, 2026
I'm not seeing
20.20.0fornode:20-trixie-slimIt works for
node:20kisaiev commentedon Jan 14, 2026
Regarding above, it seems that
20.20.0-trixie-slimis only available onlinux/amd64, refer https://hub.docker.com/_/node/tags?name=20.20-trixieheydonovan commentedon Jan 14, 2026
Confirmed! Thank you!