[UlisesGascon]

Node.js embeds the Mozilla root store but has no equivalent of the
browsers' CRLSet/OneCRL and no default online revocation checking. When
an intermediate CA key is compromised, a chain through it still verifies
as long as it reaches a trusted root. Removing the affected roots would
over-block, since other legitimate intermediates chain to them.

This adds a small compiled-in blocklist of SubjectPublicKeyInfo SHA-256
hashes, checked from a single SSL_CTX_set_cert_verify_callback hook on
every SSL_CTX Node.js creates (SecureContext, QUIC, DTLS). A hit is
reported as X509_V_ERR_CERT_REVOKED through the normal verification
path, so it honours rejectUnauthorized and surfaces as
authorizationError on client and server sockets. The OpenSSL 4.1 CN
name-constraint handling from #65957 moves into the same hook, since
OpenSSL allows only one.

The initial entries are the eight eMudhra/emSign intermediates whose
private keys were reported compromised in October 2026. The hashes are
byte-identical to Go's fix (CVE-2026-111943) and Electron's patch.

Known limitation

Sessions resumed from before the upgrade are not re-verified. This is
standard TLS resumption behaviour and ends with the session timeout.

Points for reviewers

• This is the first compiled-in trust-policy list in core. Scope is
  deliberately narrow; whether it should be configurable or updatable
  outside a release is open.
• The test-only hooks live on internalBinding('crypto') behind
  --expose-internals. A test/addons C++ addon is the alternative.
• Needs backporting to every active release line.

AI disclosure

Assisted by Claude Code and Codex; reviewed, built and tested by me.

Refs: electron/electron#55126
Refs: golang/go#82345 (technical details: golang/go@go1.27.2...go1.27.3)

[nodejs-github-bot]

Review requested:

• @nodejs/crypto
• @nodejs/quic

[UlisesGascon]

@aduh95 I am waiting for CI to finish in case I need to include more changes, but I have a local fix for the build issue (ref) 👍

Edit: pushed (8417eb1)

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/78512/

[mcollina]

lgtm

[codecov]

Codecov Report

❌ Patch coverage is 85.10638% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.50%. Comparing base (531d28f) to head (8417eb1).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
src/crypto/crypto_context.cc	85.10%	3 Missing and 11 partials ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main   #66871    +/-   ##
========================================
  Coverage   90.49%   90.50%            
========================================
  Files         797      797            
  Lines      278221   278315    +94     
  Branches    53462    53484    +22     
========================================
+ Hits       251786   251888   +102     
+ Misses      16809    16808     -1     
+ Partials     9626     9619     -7     

Files with missing lines	Coverage Δ
src/crypto/crypto_context.h	100.00% <ø> (ø)
src/crypto/crypto_tls.cc	78.44% <ø> (ø)
src/crypto/crypto_context.cc	72.52% <85.10%> (+1.03%)	⬆️

... and 31 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Fast-track has been requested by @aduh95. Please 👍 to approve.

[pimterry]

This puts a mutex into every TLS handshake, to check a list which is guaranteed empty anywhere except our test suite. It's not a huge cost compared to a whole TLS handshake, but it's not free, especially if there's any actual contention (worker threads doing TLS).

Doesn't need to block this, but there might be nicer ways to test this without this list and mutex and extra internal APIs. We could just generate a fresh intermediate for our test suite for example and include its SPKI in the real revoked list. That'd be cheaper, no locking, and we could drop the internal test APIs etc that this adds. Having a revoked example we can test with is probably quite useful generally.

[UlisesGascon]

I will work on a separate PR for this 👍

[gurgunday]

Lgtm

[nodejs-github-bot]

Landed in d9a3f3d

[golywater]

Data point for anyone landing here, plus a userland stopgap until a release containing this PR ships.

Unpatched v24 releases still accept these chains. On v24.22.0 and v24.14.0, against the test hosts from https://emudhra.we-have-a-problem.com, plain fetch() and https.get() with the bundled store return 200 for all 6 {dv,ov,ev}-{g3b,g3c}-emudhra hosts. The served chain is leaf → EM … TLS CA - G3x → emSign Root TLS CA - G3 (cross-signed) → bundled emSign ECC Root CA - G3. The 6 -aaa- hosts already fail with UNABLE_TO_GET_ISSUER_CERT_LOCALLY, because AAA Certificate Services isn't in the bundle.

Stopgap, using the same SPKI-hash approach as this PR. Wrap tls.checkServerIdentity, which Node calls after chain verification succeeds. Walk cert.issuerCertificate, stopping at a self-referencing root or undefined. For each certificate, SHA-256 new crypto.X509Certificate(c.raw).publicKey.export({ type: 'spki', format: 'der' }) and return an Error if it matches one of the 8 hex spki_sha256 values in the disclosure's impacted-intermediates.json. On both versions above, this rejected all 6 hosts through https and fetch(), and the unrelated sites we tried were unaffected.

Caveats, each observed:

• Install it before the process makes any TLS connection. Resumed sessions skip checkServerIdentity, so a session to a compromised host that was cached before the wrapper went in was resumed afterwards and got 200. Rejected handshakes are not cached, so with the wrapper installed first, repeat requests stayed rejected. Preloading with node --import ./stopgap.mjs app.js does this.
• Requests that pass their own checkServerIdentity, or rejectUnauthorized: false, bypass it.
• It's a stopgap for the window until a release with this PR ships, not a replacement.