Node.js July 2026 security release: fixed versions, 11 CVEs, and update guide

Direct answer: the July 2026 Node.js security patches are available now. If your service remains on release line 22, 24, or 26, update to at least 22.23.2 LTS, 24.18.1 LTS, or 26.5.1 Current, respectively. Do not try to patch the runtime with npm update: npm manages application packages; it does not replace the Node.js binary.

The Node.js project published the releases on July 29, 2026, after postponing the rollout planned for July 27 and then July 28 because of additional validation and infrastructure issues. The official security advisory confirms 11 CVEs and links to all three patched releases.

Executive summary

• Minimum action: keep the same major release line during the immediate response and move it to 22.23.2, 24.18.1, or 26.5.1. Plan a major-line migration separately so compatibility work does not delay the security fix.
• Highest-priority exposure: Internet-facing HTTP/2, trusted code running with --permission when an attacker can influence paths or inputs, HTTPS agents that reuse mTLS or distinct identity policies, and Node-based forwarding proxies.
• Scope: Node.js rates three issues High, five Medium, and three Low. The advisory does not publish numeric CVSS scores.
• Exploitation status: The official sources reviewed do not confirm active exploitation. That does not make the update optional: several flaws can exhaust memory, terminate the process, or break a security boundary.
• End of life: if you run an EOL line, migrate to a supported line; this advisory provides no public patch for EOL releases.

Patched Node.js release and action by branch

Branch status comes from the official Release Working Group schedule. The distribution list also marks these builds as security releases in the official Node.js release index.

What the 11 CVEs fix

This table separates severity, component, consequence, and affected lines. “Affected” reflects the scope published by Node.js; an individual application's exposure depends on the features it uses and the inputs an attacker can influence.

CVEs in the July 2026 Node.js security release

The release notes for 22.23.2, 24.18.1, and 26.5.1 document which fixes landed in each line and the bundled llhttp and undici versions.

Prioritize by actual exposure

A raw CVE count cannot set the same priority for every service. Start with the attack surface your deployment actually presents:

1. Internet-facing HTTP/2: treat 56846 and 56848 as urgent. Check Node servers that terminate HTTP/2 directly and deployments where a front proxy passes HTTP/2 to Node.
2. Permission Model around trusted code with attacker-influenced paths or inputs: prioritize 58043 and review 56847 and 58039 as well. The official Permission Model documentation describes it as a defense-in-depth control for trusted code, not a sandbox for malicious code. Operating-system and container isolation remain independent controls.
3. mTLS or multiple identity contexts on one HTTPS agent: prioritize 56850 and 58040, especially for B2B integrations, internal agents, and clients that pool connections.
4. node:sqlite with SQLTagStore: 58041 applies only to 24.x and 26.x. Include write behavior and idempotency in validation.
5. DNS lookups influenced by external input: 58042 can terminate the process when dns.resolveAny() handles a response containing more than 256 A records. Prioritize services that resolve names supplied by users or third parties.
6. Objects passed to synchronous zlib APIs: 58045 requires influence over the object or spoofed TypedArray length passed to the API. The advisory does not say that ordinary attacker-supplied compressed bytes alone trigger the flaw.
7. A forwarding proxy implemented in Node: 58044 matters despite its Low rating. The vulnerable pattern combines rebuilt visible headers, the original piped body, and backend connection reuse.

Temporarily disabling unnecessary HTTP/2, separating agents by identity, constraining attacker-influenced inputs, or strengthening isolation can reduce exposure while a maintenance window is prepared. These are partial mitigations, not replacements for a patched runtime.

Safe update procedure

1. Inventory the runtime that actually executes

Do not rely on package.json alone. Record the version and binary path used by your shell, process manager, systemd unit, and every container. Also review .nvmrc, Dockerfile FROM instructions, Compose images, and CI/CD configuration.

npm --version is useful inventory, but npm update does not install a patched Node.js runtime. Apply this fix through the mechanism that supplies the Node binary.

2. Prepare backup, tests, and rollback before changing anything

Save the previous version, service configuration, dependency inventory, and immutable image identifier. Use your application's normal data-backup procedure as well; copying a Node binary does not protect a database. Run only the commands that match your deployment. Review and redact any secret, and save only the minimum inventory in access-restricted storage; never attach raw output to the change record.

If jq is unavailable, use pm2 list and record only those fields manually. Define success criteria—health checks, latency, errors, queues, and critical workflows—and an explicit threshold for returning to the previous image or runtime. A rollback is temporary if it restores a vulnerable release.

3. Update through the existing runtime manager

NVM

Choose one target: 22.23.2 for 22.x, 24.18.1 for 24.x, or 26.5.1 for 26.x. This example uses line 24; change TARGET if you run another line. Confirm that the service account uses the same NVM installation.

A runtime change may require native add-ons to be rebuilt in the application's normal pipeline. Use the project's lockfile and documented build process; do not turn an indiscriminate npm update into part of the runtime patch.

Docker

Official images can lag the upstream binary by hours and appear gradually by architecture, as the docker-node release availability documentation explains. Inspect the exact tag and its platforms with docker buildx imagetools inspect first. If it returns manifest unknown or no matching manifest, stop this path: do not substitute 24.18.0 or another unpatched release for 24.18.1.

The Dockerfile must explicitly consume the base you verified. One safe pattern declares ARG BASE_IMAGE before FROM ${BASE_IMAGE} and passes a resolved digest; the digest can also be pinned directly in FROM. An application image tag does not prove which runtime it contains.

The docker run --rm check validates the built image before deployment and removes only that ephemeral verification container. Run the two docker exec commands after a controlled deployment; they should return v24.18.1 and the binary path inside the container. This example is valid only when the Dockerfile actually uses ARG BASE_IMAGE in FROM; otherwise, fix the Dockerfile first.

Distribution or provider packages

Inspect the candidate version first. Repositories can lag the upstream release or use a provider-specific package version with backported fixes. Check the provider's documentation and stop if you cannot show that the candidate contains these fixes. Run only the section for your operating system.

For a backport, retain the full package version and the provider advisory that confirms the fixed CVEs; node --version alone does not prove a backport. Do not add apt autoremove or image/package cleanup to this response. Retain previous artifacts until the observation window closes.

4. Restart the right process

A new binary on disk does not change a process already loaded in memory. Restart or reload in a controlled way, then confirm status. Replace the example names with your service names.

If PM2 or systemd points to an old absolute path, correct the deployment before closing the change. A shell that prints the new version does not prove which binary the production process is using.

5. Validate version, behavior, and telemetry

Check the release from every execution context, exercise a functional endpoint, and observe errors, restarts, memory, CPU, latency, and connections. These commands are a documented checklist; adapt names and endpoints to your system.

• With NVM, upstream binaries, and official images, every worker, replica, and job should report the exact patched release for its line.
• With distribution packages, record the full version through dpkg-query, rpm -q, or apk info -v and retain the provider advisory that documents the backport; do not declare success from node --version alone.
• Run smoke tests for authentication, APIs, scheduled jobs, bots, WebSockets, HTTP/2, TLS/mTLS calls, and SQLite where those features exist.
• Compare the post-change window with baseline 5xx rate, p95/p99 latency, memory, restarts, TLS/DNS errors, and queue depth.
• Observe long enough to cover at least one relevant traffic and scheduled-job cycle.

Troubleshooting before rollback

• manifest unknown or no matching manifest: confirm the tag and platform through Buildx. If the patched image is not available for your architecture, stop the Docker path and wait for that image or use another verifiable runtime source; do not deploy the prior tag.
• The shell changed, but PM2 or systemd did not: inspect the real PID executable through /proc. Fix the interpreter path in version-controlled configuration and restart only api or myapp.service.
• The candidate package does not prove a backport: do not update blindly or declare success. Record the full package version and require a provider advisory that maps it to these CVEs.
• A native add-on fails: if you see an ABI or NODE_MODULE_VERSION error, rebuild the add-on in CI or staging from the lockfile and redeploy. Do not use npm update as a production shortcut.
• The health check fails: inspect logs and telemetry. If the pre-defined threshold is crossed or a critical workflow is unavailable, trigger the matching rollback.

Run only the package query for your distribution. These checks diagnose state; they do not replace functional validation.

6. Roll back only against a defined criterion

Trigger a rollback only when the threshold defined before the change is met. Use the exact recorded values and restore the version-controlled configuration that matches the previous artifact. Returning to a vulnerable release reopens exposure, so the rollback must be temporary and documented.

NVM and PM2

Restore the version-controlled process file first if it contains an absolute interpreter path. Replace the example value with the exact recorded release and reload only the affected application.

Docker

Redeploy the immutable digest of the previous application image, not just the Node base image. This example applies only when Compose consumes APP_IMAGE; with another orchestrator, use its documented deployment mechanism with the same recorded digest. If your Compose version does not support --wait, use an explicit wait with a timeout; do not omit it.

systemd and operating-system packages

Restore the previous unit and application configuration from its versioned source through the approved deployment workflow, then reload systemd and restart only the affected service. For an OS package, use only the provider's documented rollback and only when the exact previous artifact was retained; do not offer a generic downgrade.

After each reversal, check the real process version and executable, the health check, and the same telemetry used as the trigger. Document the reopened exposure, retain partial mitigations, and schedule the compatibility fix required to reapply the patch.

If your Node.js release is EOL

Node.js states that out-of-support lines should be treated as affected when a security release occurs. In July 2026, 22.x is Maintenance LTS, 24.x is Active LTS, and 26.x is Current; lines such as 20.x are already EOL under the current schedule. Do not wait for a public patch on an EOL branch.

1. Inventory runtime, native add-on, and dependency compatibility.
2. Choose a supported line; an LTS line usually limits unrelated change for production workloads.
3. Test in staging with representative data and traffic.
4. Roll out in stages, validate telemetry, and retain a time-bounded rollback.

For APIs, bots, and Next.js applications, keep runtime updates separate from framework remediation. See our guide to the July 2026 Next.js vulnerabilities: updating Node.js does not replace a Next.js patch, and updating Next.js does not patch the runtime.

Frequently asked questions

Which Node.js version should I install?

Install 22.23.2 if you must remain on 22.x, 24.18.1 if you are on 24.x, or 26.5.1 if you are on 26.x. Do not jump release lines during the urgent response unless your current line is EOL or the migration is already validated.

Does npm update fix these CVEs?

No. These CVEs are fixed in the Node.js runtime and in dependencies shipped with it, including llhttp and undici. npm manages application dependencies; auditing or updating them is a separate task.

Am I protected behind a reverse proxy?

Not necessarily. It depends on where HTTP/2 terminates, the protocol between the proxy and Node, and whether the application uses other affected surfaces: HTTPS Agent, Permission Model, DNS, zlib, SQLite, or proxy logic implemented in Node. Verify the architecture and update the runtime.

Is there active exploitation or an official CVSS score?

The official sources reviewed do not confirm active exploitation. The advisory labels severity High, Medium, or Low but does not include numeric CVSS scores. If Node.js later publishes CVSS data, confirmed exploitation, or an erratum, this same URL should be updated with that information.

Can I mitigate the issues without restarting?

Some controls reduce exposure, such as removing unused HTTP/2 or separating agents by identity. They do not repair the binary. Schedule the controlled restart required to load the patched runtime.

Does installing the patch guarantee my service works?

No. The patched version removes the documented flaws, but application compatibility still needs smoke tests and telemetry. The commands in this guide are documented instructions; they are not tests performed by Teramont against your service.

Conclusion

This is no longer a pre-release warning: the patches are available. Update to 22.23.2, 24.18.1, or 26.5.1 for your release line, verify the binary inside the real process or container, and preserve a traceable rollback.

Primary sources

• Node.js: Wednesday, July 29, 2026 Security Releases
• Node.js 22.23.2 (LTS)
• Node.js 24.18.1 (LTS)
• Node.js 26.5.1 (Current)
• Official Node.js distribution index
• Node.js Release Working Group schedule