Node.js publishes security advisories on its blog and sends them to its security Google Group. The project's policy says the blog copy appears within 6 hours of the mailing list notice. Subscribe to one of them, name an owner on your team, and keep a short routine for applying runtime updates.
How the project handles a report
The Node.js security page describes the disclosure policy. A report goes to a primary handler, who coordinates the fix. The problem is validated against all supported versions, affected versions are listed, and the code is audited for similar problems. Fixes are prepared for all supported releases and held locally, not committed to the public repository. An embargo date is chosen and a CVE is requested.
On the embargo date, the announcement goes to the security mailing list, changes are pushed and new builds deployed to nodejs.org. The page says the embargo is typically set 72 hours from when the CVE is issued, though that can vary with severity and difficulty.
Reports go through HackerOne, and the page says normally a report is acknowledged within 5 days.
Where to get notified
The security page lists two channels for receiving updates: the Google Group and the Node.js blog. There may be other aggregators, but those two are the primary sources named by the project.
| Channel | Use |
|---|---|
| Security mailing list (Google Group) | First notice on the embargo date |
| Node.js blog | Published advisory within 6 hours of the list |
| Your dependency tooling | Maps the advisory to your running versions |
Why Express teams care
The Express security updates page carries a caution: Node.js vulnerabilities directly affect Express, so keep watch on them and use the latest stable version of Node.js. Your framework version can be perfect and the runtime underneath can still be the weak point.
Fixes are prepared for supported releases only. If you run an end of life line, you may get no fix at all. Check the release schedule in which Node.js version to run in production and the end of life posts for Node.js 20.
A routine that works
- Subscribe a shared team address to the security channel, not one person's inbox.
- Record your Node version per service, including container base images.
- When an advisory lands, check whether your versions are in the affected list.
- Patch in a test environment first, then roll out. Rebuild images, because a base image tag may need pulling again.
- Note the date and version in your change log for later review.
- If a service is on an unsupported line, schedule the upgrade, since no fix is coming.
Third party modules are separate
The policy says security bugs in third party modules go to their maintainers. So Node advisories do not cover Express, Fastify or NestJS packages. Those need dependency scanning against advisory databases. See what to do about a vulnerable transitive dependency.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the findings and look at how an advisory is tied to the asset and version it affects.
Safeguard's SBOM and dependency scanning, plus asset discovery, can help map which services run which versions. Free scan: gold.safeguard.sh/scan.
Quick check
Do Node.js advisories cover Express vulnerabilities?
No. Third party module bugs go to their own maintainers. Track the runtime and your packages separately.
Why is there a delay between a fix and the announcement?
The policy holds fixes locally until an embargo date so users can receive builds at the same time as the advisory.
Sources
Last reviewed: 19 October 2026.
