Checking API Servers for Exposure to Node.js HTTP/2 Session-Abort Crashes and HTTPS Heap Disclosure

Introduction: A 16-Vulnerability Node.js Release and the Two Advisories That Affect API Servers

On 11 November 2026, Node.js published security releases covering 16 vulnerabilities. The Hacker News, Rescana, and BigGo Finance all covered it within an hour of each other, and all three led with the same two items: HTTP/2 bugs that can crash a server or expose data from other connections, and an HTTPS heap disclosure issue. This post shows how to check API servers for exposure to the two that matter most: HTTP/2 session-abort crashes and an HTTPS heap disclosure. The rest of the 16 are the usual runtime bugs you should still take, because they ship in the same binary.

For an API server, two of those items matter far more than the other fourteen, and the reason is asymmetric exposure. The HTTP/2 abort class is a denial of service with no confidentiality component: any TLS client that can complete an ALPN handshake can reach it, and the failure mode is a process exit rather than a degraded response. The HTTPS heap disclosure is the opposite shape — low probability, potentially very high severity, and almost invisible while it happens.

I want to be explicit about what this post is. I have the news coverage, not the full advisory text. So instead of inventing version ranges and CVE numbers, this post is the part I can stand behind: the mechanism, the lab reproduction, the inventory, and the verification. Where I need a number that only the advisory has, I say so and show you where to get it.

What the Public Record Confirms and What It Does Not

Confirmed facts: 16 vulnerabilities, HTTP/2 abort and cross-connection bugs, HTTPS heap disclosure

What the release coverage states, consistently across all three outlets:

• Node.js shipped security releases on 11 November 2026 addressing 16 vulnerabilities.
• Some of those are HTTP/2 issues. The coverage describes two effects: unauthenticated server shutdowns, and exposure of data belonging to other connections.
• One issue is described as an HTTPS heap disclosure.

Those are the claims I am willing to repeat. Everything else in this post is either mechanism I can demonstrate myself, or general bug-class reasoning clearly labelled as inference.

Unverified until you read the advisory: CVE identifiers, exact affected version ranges, CVSS scores

Why a news summary is a pointer to the advisory, not a substitute for it

Look at the headline framing difference across the three items. One says "HTTPS Heap Disclosure." Another says "TLS Private Key Leaks Feared." Those are not the same claim, and the gap between them is the gap between "patch on your normal cadence" and "assume your certificate is compromised."

The confirmed language — heap disclosure — describes a bug class. The feared language describes one possible consequence of that class, conditional on what happens to be sitting next to the leaked buffer. A summary that collapses those two into one sentence strips out the conditional, and the conditional is the entire risk model. That is why the summary is a pointer: it tells you where to look, not what you found.

Anatomy of the HTTP/2 Session-Abort Crash

How session lifecycle differs from request lifecycle in Node's http2 module

http2.createSecureServer() gives you a TLS server that negotiates h2 via ALPN. The event model has three layers, and most handlers only touch the middle one:

1. 'session' — one Http2Session per TLS connection that negotiated h2. Long-lived. Carries the HPACK state, the settings, the stream ID space.
2. 'stream' — one Http2Stream per request. Short-lived.
3. 'request' — the HTTP/1 compatibility layer, only meaningful when you pass allowHTTP1: true.

A typical handler looks like this, and it is the "before" state for the whole bug class:

const http2 = require('node:http2');
const fs = require('node:fs');

const server = http2.createSecureServer({
key: fs.readFileSync('localhost-key.pem'),
cert: fs.readFileSync('localhost-cert.pem'),
allowHTTP1: false,
});

// Deliberately no 'session' listener.
server.on('stream', (stream, headers) => {
stream.respond({ ':status': 200, 'content-type': 'application/json' });
stream.write('{"partial":');   // left unfinished on purpose
});

server.listen(8443, () => console.log('h2 listening on 8443'));

A try/catch around the body of that stream handler feels like error handling. It covers exactly one of the three layers. A connection-level failure has no relationship to any particular stream callback frame, so it can never land in that catch.

Why an abort arriving at the wrong moment turns an expected error into an uncaught exception

Http2Session is an EventEmitter. When the underlying socket dies mid-flight — a TCP reset instead of a clean GOAWAY — Node surfaces that as an 'error' event on the session object. And EventEmitter semantics are unforgiving: an 'error' event with no listener is thrown. Not emitted and dropped. Thrown.

So the sequence is:

1. Client completes the TLS + ALPN handshake and opens a stream.
2. Client kills the socket (RST) while the response is still open.
3. Node emits 'error' on the Http2Session with something like ECONNRESET.
4. Nothing is subscribed. The emitter throws.
5. uncaughtException fires, no handler exists, the process exits with code 1.

There is a second path to the same outcome: if your handler calls stream.respond() or stream.write() after the stream has been destroyed, Node throws ERR_HTTP2_INVALID_STREAM synchronously inside your callback. A .then() chain or an await between "check the stream is alive" and "write to it" gives the abort a window to land in. Node will not wrap your 'stream' callback in a safety net.

The distinction that matters operationally: RST_STREAM cancels one stream and is a stream-level error. A socket reset or a protocol-level failure is a session-level error. Most codebases I have read handle the first and not the second.

Why this is unauthenticated, cheap, and effective against a public HTTP/2 listener

Nothing about the trigger requires credentials, a valid route, or a well-formed request body. If the fault is in session teardown — and the coverage's "unauthenticated server shutdowns" phrasing points that way — then the attacker's cost is one TLS handshake against a listener that already accepts handshakes from the entire internet.

That is what makes this different from most DoS reporting. It is not a volumetric attack. It does not need a botnet, and it does not need amplification. It needs the same thing your legitimate clients need: a connection.

What I am not claiming: I do not know, from the coverage, the exact byte sequence or timing window that triggers the specific defect. What I do know, and can demonstrate in the lab below, is that an unhandled session error is a process killer in ordinary Node code. The advisory supplies the trigger; the shape is already in your codebase.

Cross-Connection Data Exposure in HTTP/2

What state is shared per-session versus per-stream, and where mixed-up state becomes a leak

HTTP/2's isolation model is per connection, not per process. That is the design, and it is why a state-mixing bug is a real boundary break rather than a cosmetic one.

The HPACK entry deserves a note: the dynamic table is supposed to be per connection, so sharing it across clients would leak header values — cookies, bearer tokens, internal hostnames — not just bodies. If the advisory turns out to describe HPACK table reuse, the confidentiality impact is worse than a body mix-up, because authorization headers get compressed into that table.

Why HTTP/2 multiplexing changes the trust boundary compared to HTTP/1.1 keep-alive

HTTP/1.1 keep-alive is sequential: one request on the wire at a time, framed by Content-Length or chunked encoding. If a bug misroutes a response, the client's parser usually notices, because the framing is positional.

HTTP/2 interleaves frames from many streams with explicit stream IDs. Correctness depends entirely on the ID-to-stream mapping being right. Get that mapping wrong and there is nothing positional to catch it — the receiving client happily accepts a valid HEADERS frame for a stream it opened. On top of that, browsers will coalesce requests for multiple origins onto one connection when the certificate covers both, so "one connection equals one origin" is already false in the real world.

What a realistic detection signal looks like when one client sees another client's bytes

This is the hard part, and I want to be honest: there is no clean single-request detector. These are the signals I would instrument, all of which are cheap and none of which are conclusive on their own:

• A JSON parse failure where the payload is structurally valid but contains an identifier that belongs to a different tenant.
• content-length disagreeing with the bytes the client actually read.
• A set-cookie value that does not correspond to the session the client just authenticated.
• Response bodies whose ordering does not match request ordering on a connection with concurrent streams.

The concrete instrumentation is to log the session identity alongside the request identity and assert consistency at the edge:

server.on('stream', (stream, headers) => {
const socket = stream.session && stream.session.socket;
const sessionId = socket
  ? socket.remoteAddress + ':' + socket.remotePort
  : 'unknown';

// :authority should be stable for the life of a session in any sane client.
const authority = headers[':authority'];

logger.info({ sessionId, authority, streamId: stream.id }, 'h2 stream open');
});

If you ever see one sessionId paired with multiple :authority values for a single-tenant service, that is either connection coalescing on the client or something wrong. It is worth alerting on.

The HTTPS Heap Disclosure Bug Class

How heap-allocated buffers can escape into a TLS response path

Node's Buffer.allocUnsafe(n) does not zero memory. Small allocations are sliced out of the shared 8 KB pool; larger ones come from uninitialized memory directly. Either way the bytes previously held whatever the process was doing. That is a deliberate performance decision, and it is safe only as long as every consumer respects the written length, not the allocated length.

The failure looks like this: a function allocates 16 KB, writes 300 bytes, and hands the whole 16 KB buffer to tlsSocket.write() or stream.write() with a length derived from the allocation rather than the write. The extra ~15.7 KB goes out on the wire as body bytes. In HTTP/1.1 chunked framing or a mis-set Content-Length, it can be delivered straight to the client.

// The unsafe shape: length from the allocation, not the write.
const buf = Buffer.allocUnsafe(16 * 1024);
const written = buf.write(payload, 0, 'utf8');
res.end(buf.subarray(0, 16 * 1024));   // WRONG: should be (0, written)

// The safe shape.
res.end(buf.subarray(0, written));

This is bug-class reasoning, not the confirmed root cause. I do not know from the coverage whether the disclosed issue involves allocUnsafe, a compression buffer, a length computation in the TLS record layer, or something else entirely. I am showing you the pattern because it is the pattern, and because you can grep for it in your own code today regardless of what the advisory says.

Why the practical risk depends on what else lives in that process's heap

This is the sentence that decides whether the disclosure is a severity-7 finding or a severity-10 finding: leaked bytes are only as sensitive as the process's recent memory.

If your API terminates TLS in the same process that runs application code, the private key lives in that process's memory. That does not mean it leaks — the key is typically held in OpenSSL's own structures, not the JavaScript heap, and the two are not the same allocation arena. But the headline "TLS Private Key Leaks Feared" is describing exactly that adjacency, and it is worth knowing which side of it you are on.

Limits of what can be claimed publicly without the advisory's specifics

What I cannot tell you, and what nobody should be guessing at right now:

• Whether the trigger requires attacker-influenced response length.
• Whether the leak is a few bytes per response or a large over-read.
• Whether session resumption or TLS 1.3 early data changes the exposure.
• Whether HTTP/1.1 is affected or only the HTTP/2 TLS path.

The leak rate is the parameter that changes your detection strategy completely. A few bytes per response is a slow exfiltration channel that needs many samples and correlation — you will not see it in a single captured request. A multi-kilobyte over-read shows up as a content-length mismatch the moment a client validates framing. Since I cannot tell you which it is, grep your own length handling and patch the runtime.

Inventory Step 1: Enumerate Every Node Runtime You Actually Run

Local, container, and serverless runtimes: process.version, image digests, managed platform versions

Start with the version check inside the process, not on your laptop:

node -p "process.versions.node + ' ' + process.versions.openssl"

The output is a single line: the Node version, a space, the OpenSSL version. Record both — the OpenSSL version tells you whether the TLS layer moved, which matters for the heap-disclosure side of this release independently of the Node patch.

For containers, record the digest, because tags are mutable and "we are on node:22" is not an answer:

docker image inspect node:22-bookworm-slim --format '{{index .RepoDigests 0}}'

The output is a repo-qualified digest of the form node@sha256:.... The full hash is what belongs in your inventory. Anything shorter is a tag with extra steps.

For managed and serverless runtimes, the version is a platform attribute you do not control:

Lambda is the one people get wrong. The runtime identifier (nodejs22.x, for example) is a platform-level pin, and AWS updates the patch level inside it on their own cadence. You cannot assume a Lambda function picked up this release on 11 November just because it exists.

Finding the runtimes nobody owns: build tools, cron jobs, sidecars, and local dev

The inventory that matters is the one with node binaries in it that no team claims. Mine a host or an image for them:

find / -xdev -type f -name node -perm -u+x 2>/dev/null

Every line in that output is a runtime that needs a version check. The usual suspects:

• Multi-stage Dockerfiles where the builder stage runs node but the final image ships a distroless base — the builder is still in your supply chain.
• Cron containers and one-off kubectl run jobs that mount an old image.
• CI images pinned by tag months ago, running the test suite on a version your production does not use.
• Developer machines on an nvm-managed LTS two majors behind, which is where reproducible bug reports go to die.

Ninety percent of "we already patched" statements I have seen in incident calls were true for the service and false for the build job next to it.

Inventory Step 2: Find the HTTP/2 Listeners

Grepping for http2.createSecureServer, createServer, and ALPN negotiation in proxies

Search the source, explicitly excluding node_modules, for the import and the server constructors:

rg -n --glob '!node_modules' \
  -e "require\('node:http2'\)" \
  -e "from 'node:http2'" \
  -e 'createSecureServer\(' \
  -e 'ALPNProtocols' \
  .

The ALPNProtocols hit is the one people miss. A server can opt into h2 by listing it in ALPN even if the rest of the code reads like an HTTP/1.1 server. And createServer without Secure still matters — plaintext h2c behind a reverse proxy that speaks prior-knowledge HTTP/2 to the target group is a real deployment pattern.

Frameworks and protocols that enable HTTP/2 implicitly: gRPC, Fastify, Next.js, reverse proxies

• Fastify turns it on with fastify({ http2: true }), and the https option alongside it for a secure listener. Grep for http2: in your Fastify bootstrapping.
• gRPC is HTTP/2 by definition. @grpc/grpc-js sits on top of the http2 module, so it inherits session handling whether or not you ever wrote an Http2Session yourself.
• Next.js does not ship an HTTP/2 server as far as I know — you get h2 by fronting it with a proxy that terminates TLS. That proxy is in scope for this inventory even though your Next.js image is not.
• Express has no built-in secure HTTP/2 listener, but the pattern http2.createSecureServer({ allowHTTP1: true }, app) exists in the wild and is frequently only partially functional — some middleware assumes res.writeHead semantics that do not survive the compat layer. Treat any allowHTTP1: true wrapper around Express as h2-exposed on the h2 path and worth reading closely.
• Reverse proxies — nginx with http2 on;, Caddy (h2 by default for TLS), Envoy, and Traefik all terminate h2 regardless of what your application does.

nginx deserves a specific note: listen 443 ssl http2; was deprecated in 1.25.1 in favour of a separate http2 on; directive. If your config uses the old form, you are probably running an nginx old enough to have other reasons to upgrade, and you have two things to change in one file.

Which services terminate TLS themselves and which sit behind something that does

Two checks, both cheap:

openssl s_client -connect api.example.com:443 -alpn h2 </dev/null 2>/dev/null | grep 'ALPN protocol'

If that prints ALPN protocol: h2, the edge speaks HTTP/2 to clients. That does not tell you who terminates it. For that, look at the application: if the process has no certificate paths, no https option, and reads X-Forwarded-Proto, TLS is terminated upstream and your Node process may only ever see HTTP/1.1.

Inventory Step 3: Rank Exposure Before You Patch

A simple exposure matrix: internet-facing, authenticated-only, internal, and offline

Separating crash-only risk from confidentiality risk when deciding rollout order

These are different risks with different clocks, and conflating them produces bad rollout decisions.

Crash risk is deterministic and verifiable. Either your listener accepts h2 from the internet or it does not. You can answer that in ten minutes with openssl s_client. A confirmed Tier 1 service should be patched today, because the exploit requires nothing but a socket.

Confidentiality risk is probabilistic and unverifiable from the outside. It depends on heap adjacency, on the leak rate, and on whether anyone is actually looking. Patching is still correct, but a Tier 1 service that is multi-tenant with TLS in-process deserves a disclosure review alongside the patch, because the question "do we have to tell anyone" has a longer lead time than "did the container restart."

Reproducing the Crash Class in a Lab

A minimal HTTP/2 server and a client that aborts mid-stream

Generate a throwaway certificate:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout localhost-key.pem -out localhost-cert.pem \
  -days 1 -subj "/CN=localhost"

The server is the shape from earlier — no 'session' listener. The client aborts in two different ways, and the difference is the whole point:

const http2 = require('node:http2');
const { streamAbort, socketAbort } = require('./abort-modes');

function run(label, abort) {
const client = http2.connect('https://localhost:8443', {
  rejectUnauthorized: false,
});
client.on('error', () => {}); // client side is not what we are testing

const req = client.request({ ':path': '/anything' });
req.on('response', () => setTimeout(() => abort(client, req), 20));
req.on('error', () => {});
req.resume();

setTimeout(() => {
  console.log(label, 'done');
  client.close();
}, 400);
}

// Stream-level abort: RST_STREAM, one stream cancelled.
run('stream-abort', streamAbort);

// Session-level abort: RST on the socket, no GOAWAY.
run('socket-abort', socketAbort);

To actually fire the two different aborts, add an explicit RST_STREAM on one path and a socket reset on the other:

const http2 = require('node:http2');

// Mode A: cancel a single stream. Server sees a stream error.
function streamAbort(client, req) {
req.close(http2.constants.NGHTTP2_CANCEL);
}

// Mode B: reset the TCP connection. Server sees a session error.
function socketAbort(client) {
client.socket.resetAndDestroy();
}

module.exports = { streamAbort, socketAbort };

resetAndDestroy() sends a real TCP reset rather than a graceful FIN, which is what an aborting or misbehaving client actually does. Run the server under node h2-lab/server.js in one terminal, fire mode B from another, and watch the first terminal.

Reading the result: exit code, restart count, and container restart policy

On the builds I have done this with, an unhandled ECONNRESET on an Http2Session takes the process down with exit code 1. If yours survives, look for a framework that attached a session listener on your behalf — that is worth knowing, because it tells you the framework is your mitigation and your upgrade risk.

If the server does survive mode A and dies on mode B, you have proof that your code handles stream errors and not session errors. That is the single most common version of this bug.

Container restart policies turn the crash into the failure mode your users see:

docker run -d --restart=always --name h2lab -p 8443:8443 h2-lab
docker inspect h2lab --format '{{.RestartCount}} {{.State.ExitCode}}'

A single reset driving RestartCount up is a functional outage, not a security finding. That is why Tier 1 services get patched first.

Testing behind a proxy, where the crash may show up as a 502 instead of a stack trace

Put nginx or an ALB in front and repeat the test. The application log goes quiet. What you see instead:

• A burst of 502 or 504 at the proxy.
• upstream prematurely closed connection while reading response header in the nginx error log.
• Restart counts rising on the application with no corresponding application log lines.

This is the detection gap that makes the bug expensive. If your only crash alerting is "error log contains a stack trace," an abort-driven crash loop looks like a proxy problem and gets routed to the wrong team. Alert on restart counts and on the proxy-side 502 rate, and correlate them.

Choosing Between Patching, Cross-Line Upgrades, and Temporary Mitigations

Upgrading within a supported release line and why cross-line jumps need their own review

A patch bump inside a release line is a small diff: the fix plus whatever landed in the patch releases since. Take it on the normal fast path.

A cross-line jump is a different change. Between majors, Node moves V8, may move OpenSSL, and changes the ABI that native addons compile against. That means every native module in your dependency tree needs a rebuild, and every prebuilt binary needs a compatible build to exist. npm rebuild covers the local case; the harder question is whether your production image rebuilds native addons from source or downloads a prebuilt artifact compiled for a Node ABI you just left. Check before you plan the window.

I would not bundle a major upgrade into an emergency security patch unless a line is already end-of-life. Do the patch on your current line, then plan the jump separately with its own soak.

Temporary mitigations: disabling HTTP/2 on the public listener, restricting ALPN, or fronting with a proxy

In rough order of how much they actually buy you:

1. Turn off HTTP/2 at the edge. In nginx, replace listen 443 ssl http2; with listen 443 ssl; and add http2 off; if a global http2 on; directive is set. Clients fall back to HTTP/1.1 via ALPN.
2. Restrict ALPN on the Node TLS listener. If you own the createSecureServer options, ALPNProtocols: ['http/1.1'] removes h2 from the negotiation entirely. Verify with openssl s_client afterwards — do not trust the config file.
3. Move TLS termination in front of the application, so the app speaks HTTP/1.1 to the proxy over a private network.
4. Rate-limit per connection at the edge. The weakest option, and I would not rely on it: if one reset is enough, the limit needs to be low enough to break legitimate clients.

The real cost of each mitigation: latency, connection counts, and lost multiplexing

The lost-multiplexing cost is real but frequently overstated for API traffic. A JSON API with 50 ms responses does not benefit much from h2 multiplexing; a page with 80 subresources does. If you are weighing a temporary h2 shutdown, look at your p95 latency under HTTP/1.1 in staging rather than reasoning from first principles. And if you enable allowHTTP1: true, remember that a client can pin http/1.1 in ALPN and never touch the h2 code path — that is a legitimate, temporary way to reduce surface without disabling the listener.

Verifying the Fix Landed

Startup assertions and CI gates that fail on a vulnerable runtime

A version assertion at boot is the cheapest possible guard against a stale base image:

const MINIMUM = process.env.NODE_MINIMUM; // fill in from the advisory, per line

if (!MINIMUM) {
console.error('NODE_MINIMUM is not set; refusing to start.');
process.exit(1);
}

const parse = (v) => v.split('.').map((n) => parseInt(n, 10));
const [maj, min, pat] = parse(MINIMUM);
const [cmaj, cmin, cpat] = parse(process.versions.node);

const ok =
cmaj > maj ||
(cmaj === maj && cmin > min) ||
(cmaj === maj && cmin === min && cpat >= pat);

if (!ok) {
console.error('Node ' + process.versions.node + ' is below the patched minimum ' + MINIMUM);
process.exit(1);
}

The NODE_MINIMUM value comes from the advisory, not from me — I do not have it. Set it per release line, because a minimum that is correct for 22.x is wrong for 24.x.

The CI gate has to run against the built artifact, not the runner. A runner on a patched version proves nothing about the image you are about to deploy:

docker run --rm --entrypoint node "$IMAGE" -p "process.versions.node"

Post-deploy proof: version endpoints, image digests, and SBOM diffs

Three layers of proof, in increasing order of usefulness:

• A version endpoint. Useful for debugging, and a small information leak. If you expose process.versions.node publicly, an attacker gets a free fingerprint of exactly which CVE you are missing. Gate it behind internal networking or return a hash.
• Image digests. Capture docker image inspect ... --format '{{index .RepoDigests 0}}' before and after. The digest must change. If it did not, you redeployed the same bits.
• SBOM diffs. Generate both and compare the Node version:

syft "$IMAGE" -o cyclonedx-json > sbom-after.json
jq -r '.components[] | select(.name | test("node"; "i")) | "\(.name) \(.version)"' sbom-after.json

The package name syft assigns to the Node binary varies with the base image — it may be node, or it may come from the distro package manager's naming. jq with a case-insensitive regex on node and a manual read of the output is more reliable than assuming a single exact name. Record the version you actually see, not the one you expected.

Rollback criteria and the observability signals that should return to baseline

Define these before the deploy, with numbers:

Rollback is the right call on handshake failures and restart loops. It is usually the wrong call on a small p99 regression, because the security delta is unbounded and the latency delta is measurable. Say that out loud before the deploy, not during the incident.

Hardening HTTP/2 Handlers So the Next Bug Hurts Less

Session limits, timeouts, maxConcurrentStreams, and maxSessionMemory

The session object is where you put bounds that survive this bug and the next one:

const http2 = require('node:http2');
const fs = require('node:fs');

const server = http2.createSecureServer({
key: fs.readFileSync('tls/localhost-key.pem'),
cert: fs.readFileSync('tls/localhost-cert.pem'),
allowHTTP1: true,
maxSessionMemory: 8,          // MB; docs list 10 as the default
settings: {
  maxConcurrentStreams: 64,   // set explicitly; do not inherit a default
  initialWindowSize: 65535,
},
});

server.on('session', (session) => {
session.setTimeout(30000, () => {
  session.close(http2.constants.NGHTTP2_NO_ERROR);
});

// THE important line. Without this, any session error kills the process.
session.on('error', (err) => {
  logger.warn({ code: err.code }, 'h2 session error');
});
});

server.on('session', (session) => {
logger.info({
  remote: session.socket && session.socket.remoteAddress,
  maxConcurrent: session.remoteSettings.maxConcurrentStreams,
}, 'h2 session opened');
});

Two notes on the numbers. maxSessionMemory is documented with a 10 MB default; lowering it bounds the damage a slow-reading client can do. maxConcurrentStreams — set it explicitly rather than trusting whatever the default is on your release line, and read session.remoteSettings at runtime to see what the client actually agreed to. The October 2023 Rapid Reset campaign (CVE-2023-44487) was a RST_STREAM flood, and per-session stream caps plus per-connection limits were the standard mitigation. The same knobs bound the blast radius of a session-abort bug.

Handling stream and session error events instead of letting them escape

Attach both, and wrap the handler body. All three are necessary; none substitutes for the others.

server.on('stream', (stream, headers) => {
stream.on('error', (err) => {
  // RST_STREAM, cancellation, protocol errors on this stream.
  logger.debug({ code: err.code, streamId: stream.id }, 'h2 stream error');
});

try {
  stream.respond({ ':status': 200, 'content-type': 'application/json' });
  stream.end(JSON.stringify({ ok: true }));
} catch (err) {
  // respond() after destroy throws ERR_HTTP2_INVALID_STREAM synchronously.
  logger.debug({ code: err.code }, 'h2 respond failed');
  if (!stream.destroyed) stream.close(http2.constants.NGHTTP2_INTERNAL_ERROR);
}
});

And what not to do: process.on('uncaughtException', () => {}) as the fix. Catching the throw keeps the process alive with a corrupted HTTP/2 session state, an unknown number of half-written responses, and no guarantee the socket is still coherent. That is not availability; it is a process that has stopped crashing while continuing to serve. Attach the session listener instead.

Keeping TLS termination in a separate process from application code

This is the architectural position I would actually defend: for internet-facing, multi-tenant APIs, terminate TLS in a dedicated proxy process, not inside the Node application.

The availability argument is the obvious one — a proxy that speaks HTTP/1.1 to your app removes the entire h2 session crash surface from the app. The confidentiality argument is better. If the private key never enters the application process, the heap-disclosure blast radius shrinks to "whatever the application holds," which is still bad but is a bounded, enumerable set instead of "plus the key." It also gives you a single place to enforce stream limits, connection caps, and timeouts, and a component you can patch on a different schedule than your business logic.

The cost is a hop. For most API workloads that hop is under a millisecond on a local network, and the operational benefit — one place to see and bound HTTP/2 behaviour across every service — is worth more than the microsecond.

What I Would Do This Week

An ordered checklist from inventory to verification

1. Read the advisory at nodejs.org/en/blog/vulnerability and write down the CVE identifiers, affected ranges, and fixed versions per line. Nothing below this line is useful without it.
2. Run openssl s_client -connect <your host>:443 -alpn h2 against every public endpoint and record which ones answer h2. That is your Tier 1 candidate list.
3. For each Tier 1 service, determine whether TLS terminates in the Node process or upstream. Record the answer; it decides both the crash exposure and the disclosure scope.
4. Enumerate runtimes with find / -xdev -type f -name node inside your images, plus a query against Lambda and any managed build platform.
5. Run the 'session' listener grep across every repo. Any service that creates an Http2Session without an 'error' listener is a crash waiting on a reset, independent of this release.
6. Patch Tier 1 today, within line. Queue cross-line upgrades separately.
7. Add the NODE_MINIMUM startup assertion and the docker run --entrypoint node CI gate, so the next release does not require this whole exercise.
8. Verify with the image digest and the SBOM diff. Confirm the digest changed.
9. Watch restart counts and proxy 502 rates for 24 hours against the baseline you defined before the deploy.
10. If any Tier 1 service is multi-tenant with in-process TLS termination, start the disclosure conversation now rather than after the advisory technical details are public and your customers have read them.

What to say to stakeholders without exaggerating the risk

The version I would actually send:

A Node.js security release on 11 November 2026 covers 16 issues. Two affect us. The first lets an unauthenticated client restart our API process by aborting an HTTP/2 connection; the impact is availability, and we are patching today. The second is a memory-disclosure issue in the HTTPS layer whose real-world scope we cannot confirm until the advisory's technical details are published. We have patched it in the same change. We are not currently treating it as a key compromise, and we will reassess if the published details show key material in the affected memory.

What not to say: "TLS private key leaks." The coverage says heap disclosure; a headline writer added the fear. If you repeat the fear as a fact, you will spend the next week in a certificate rotation you may not have needed, and you will lose credibility when the advisory turns out to describe something narrower.

Further Reading: Advisories, Release Notes, and the HTTP/2 Specification

• Node.js security releases index — the primary source for this event; read the November 2026 entries for CVE identifiers and fixed versions per line.
• Node.js release schedule — which lines are still supported, and therefore which lines this release covers.
• Node.js http2 API documentation — Http2Session events, maxSessionMemory, settings, and allowHTTP1 semantics.
• Node.js tls API documentation — ALPN negotiation and the TLS server options referenced above.
• Node.js Buffer documentation — allocUnsafe, the buffer pool, and the length semantics behind the disclosure bug class.
• RFC 9113 — HTTP/2 — session and stream lifecycle, RST_STREAM, GOAWAY, and SETTINGS.
• RFC 7541 — HPACK — why the header compression table is per connection, and what it holds.
• RFC 8446 — TLS 1.3 — record layer and the response path the heap issue sits near.
• CVE-2023-44487 (HTTP/2 Rapid Reset) — prior art for per-session stream limits as a mitigation.
• nginx ngx_http_v2_module documentation — the http2 on; directive that replaced the deprecated listen ... http2 form.

News coverage of the release, for reference (aggregator links): The Hacker News, "Node.js Fixes 16 Flaws, Including HTTP/2 Bugs That Crash Servers and Leak Other Connections' Data"; Rescana, "Node.js 11 November 2026 Security Releases: HTTPS Heap Disclosure and HTTP/2 Abort"; BigGo Finance, "16 Severe Node.js Vulnerabilities: Unauthenticated Server Shutdowns and TLS Private Key Leaks Feared." Treat all three as pointers to the Node.js advisory, not as substitutes for it.