Node.js June 2026 Security Releases: CVE Patch Guide

Node.js shipped coordinated security releases on June 18, 2026, patching 12 CVEs across all three active release lines — 22.x (Maintenance LTS), 24.x (Active LTS), and 26.x (Current). Two of the twelve carry a HIGH severity rating, which means this is a patch-this-week batch, not a patch-next-sprint one.

The two HIGH-severity issues are the headline. CVE-2026-48933 lets an attacker crash a Node process by passing input that is a multiple of 2 GiB to the WebCrypto subtle.encrypt() call — a denial-of-service trigger that file-encryption pipelines can hit without any malice at all. CVE-2026-48618 is a TLS hostname normalization flaw that can bypass wildcard-certificate verification, the most common certificate pattern in multi-tenant SaaS.

This guide does three things: it walks through what each HIGH CVE actually does and who is exposed, it gives you a CVE-by-module breakdown so the right team owns the right fix, and it lays out the one-command upgrade paths for nvm, fnm, Volta, and Docker — plus the one hidden breaking change buried inside this release that npm audit fix can trip silently.

On June 18, 2026, the Node.js project published security updates for every supported release line at once: 22.23.0 (codename Jod), 24.17.0 (codename Krypton), and 26.3.1 (Current — no LTS codename yet). Antoine du Hamel managed all three releases. The advisory groups twelve distinct CVEs across the WebCrypto, TLS, HTTP/2, HTTP, DNS, and Permission Model subsystems.

Most of the twelve are MEDIUM or LOW, but the two HIGH-severity issues — one in crypto, one in TLS — are the reason this release warrants an immediate look rather than a scheduled maintenance window. Both HIGH CVEs affect all three active lines, so there is no version you can be running today that is unaffected, short of an already-patched build.

CVE-2026-48933 is a HIGH-severity flaw in the Node.js WebCrypto implementation. When the input to subtle.encrypt() is a multiple of 2 GiB, the process aborts — a denial of service. The root cause is that the WebCrypto cipher output length was not guarded against integer overflow at that threshold. Filip Skokan authored the fix, which landed in all three release lines.

What makes this one urgent is that the trigger is not exotic. Consider a Next.js API route that encrypts a large file upload — a video, a database export, a backup archive — by buffering it and handing it to subtle.encrypt() in one shot. A 2 GiB upload lands squarely on the failure condition, and the process dies. No attacker is required: an honest user uploading a large file can take the service down. That is the difference between a theoretical DoS and an operational one.

The fix guards the cipher output length so the overflow can no longer occur. There is no application-level mitigation that fully closes the gap short of patching — you can cap upload sizes or chunk encryption below the 2 GiB boundary as a stopgap, but those are workarounds, not fixes. Upgrade to a patched build and remove the stopgaps once you have.

CVE-2026-48618 is the second HIGH-severity issue. It lives in Node.js TLS hostname handling: the runtime did not normalize Unicode dot separators during server identity checks, creating a resolver-versus-verifier normalization mismatch. Under affected configurations, that mismatch can bypass TLS wildcard-depth authentication — a confidentiality impact or a bypass of the intended security boundary. Matteo Collina authored the fix.

The practical exposure here is wildcard certificates. A *.example.com certificate is the default pattern for multi-tenant SaaS, where one cert covers an arbitrary number of tenant subdomains. Teams relying on Node’s built-in tls.checkServerIdentity() with wildcard certs are the specific at-risk population — the normalization mismatch is what lets an attacker present a hostname that passes the verifier but resolves differently, defeating the wildcard depth restriction.

If your architecture terminates TLS at a load balancer or reverse proxy and Node only talks plaintext on a trusted internal network, your blast radius is smaller — but Node-to-Node and Node-to-upstream TLS with wildcard certs is exactly the pattern this CVE targets. Where you run TLS-heavy public endpoints, pair the patch with sane rate-limiting on public HTTP/2 endpoints so a compromised path cannot be hammered cheaply.

Most coverage lists these CVEs in severity order. We group them by affected module instead, so the right team owns the right fix: your TLS reviewers take four, your HTTP team takes four, your crypto path takes one, and your Permission Model work takes three. The Breaking? column flags the single CVE in this batch tied to a behavior-changing dependency bump.

The authorship concentration is itself a useful signal: Matteo Collina authored the bulk of the TLS and HTTP fixes, RafaelGSS owns the three Permission Model hardening fixes, and Filip Skokan owns the WebCrypto crash. The Permission Model fixes are LOW-severity and local-only — they matter most to teams running Node with the experimental --permission flag, and one of them (CVE-2026-48936) affects only the 26.x line. If you are not using the permission model in production, those three drop down your priority list.

The June 18 batch patches Node 22, 24, and 26. It does not patch Node 20, which reached End of Life on April 30, 2026. That is the operationally important fact in this release: any organization still running Node 20 in production has zero official mitigation path for these CVEs from the Node.js project itself. The clock on that exposure started weeks ago, and it does not reset.

One vocabulary point worth getting right, because it changes the upgrade advice: Node 22 is in Maintenance LTS (security patches only), not Active LTS. Node 24 is the one in Active LTS. If you are choosing a line to standardize on for the next two years, Node 24 is the answer — it gives you the longest runway of active feature and security support. Node 22 is a perfectly safe holding line through April 2027 if a major-version bump is not feasible right now.

For teams whose deployment story runs through CI, the single most reliable way to guarantee everyone pulls a patched build is to pin the Node version in the pipeline rather than relying on each developer’s local install. The same CI/CD pipeline hardening discipline that catches dependency drift is what turns a security release into a one-line change in a base image rather than a fleet-wide scramble.

Security releases are supposed to be safe to apply blindly. This one has a wrinkle. All three lines bump bundled nghttp2 to 1.69.0, and for Node.js that bump is SEMVER-MAJOR: nghttp2 1.69.0 removes HTTP/2 priority signaling support. The corresponding Node deprecation, DEP0194, was already in place, so the runtime behavior change is not arriving unannounced — but it is still a behavior change shipping under a security-release banner.

The concrete risk: code that calls http2session.setPriority() or http2stream.priority() can throw runtime errors after you upgrade to Node 22.23.0 or 24.17.0. Teams that auto-apply npm audit fix — or that bump Node without reading the release notes — can pull this in and silently break HTTP/2 priority calls. Audit for those two call sites before you upgrade, and remove them.

Each upgrade path is essentially one command. The wrinkle is never the runtime swap; it is the cleanup afterward — regenerating lockfiles, rebuilding native modules, and re-running your test suite against the new line. Pick the path that matches your version manager.

Not every workload carries the same urgency. The right move is to map your actual surface area to the two HIGH CVEs, then schedule accordingly. Here is how we would triage it for a typical production fleet.

The broader pattern this release reinforces is that the modern Node.js attack surface is overwhelmingly in the network and crypto layers — TLS, HTTP/2, DNS, WebCrypto — not in application logic. Most of the twelve fixes touch transport or network security. As more services move to HTTP/2 and rely on built-in TLS rather than a proxy tier, that surface grows, and the value of patching promptly compounds with it.

Looking forward, the operational takeaway outlasts this specific batch: version-pin your runtime in CI, read the release notes for the one SEMVER-MAJOR change hiding in an otherwise routine security release, and get off End-of-Life lines before the next coordinated disclosure leaves you with no official path. The teams that handle June 18 in an afternoon are the ones who already pin Node in a base image and treat a security release as a one-line bump, not a fire drill.