Node.js fixed two medium-severity HTTPS client issues in July 2026. CVE-2026-56850 could reuse the wrong client identity when an HTTPS Agent handled different PFX object-array configurations. CVE-2026-58040 could reuse a TLS session without performing the expected hostname verification for the new request.

These flaws matter most in services that make many outbound HTTPS calls through shared agents, especially when client certificates or dynamic destinations vary by tenant.

Quick answer

Update to Node.js 22.23.2, 24.18.1, or 26.5.1. Use separate HTTPS agents for separate mTLS identities, avoid mixing tenant certificates in one shared pool, keep hostname verification enabled, and test what certificate and server name the remote endpoint actually observes.

import https from "node:https";

const tenantAgents = new Map();

function agentForTenant(tenantId, pfx, passphrase) {
  if (!tenantAgents.has(tenantId)) {
    tenantAgents.set(tenantId, new https.Agent({
      keepAlive: true,
      pfx,
      passphrase,
      rejectUnauthorized: true,
    }));
  }
  return tenantAgents.get(tenantId);
}

The mapping must be bounded and cleaned up. The security point is that one identity owns one connection pool.

If certificate material rotates, create a new agent for the new identity and retire old sockets deliberately. Mutating credentials underneath a live shared pool makes it difficult to prove which certificate a reused connection presents.

Understand the PFX identity risk

An mTLS client presents a certificate to prove its identity. A backend may use different certificates for tenants, partners, regions, or privilege levels.

An HTTPS Agent pools and reuses sockets. If its cache key does not correctly distinguish PFX object-array options, a request may travel over a connection established with another client certificate. The remote service could attribute the request to the wrong identity.

The impact depends on whether different identities have different authorization. If every request uses the same certificate, this particular confusion path is less relevant, but the runtime should still be patched.

Understand the hostname-check risk

TLS verifies that the certificate presented by the server is valid for the requested hostname. Session resumption improves performance by reusing negotiated state, but the client still needs the correct identity guarantee for each destination.

CVE-2026-58040 concerns session reuse where hostname verification could be skipped. Services with dynamic destinations, shared agent pools, custom lookup functions, or proxies deserve focused review.

Never “fix” TLS errors by setting rejectUnauthorized: false. That disables certificate validation and creates a much broader vulnerability than the performance issue being investigated.

Inventory shared agents

Search for https.Agent, Undici agents or pools, Axios agent options, PFX loading, and custom TLS callbacks.

rg -n "https\\.Agent|httpsAgent|pfx:|checkServerIdentity|rejectUnauthorized|session" src test

For each agent, document:

  • destinations it can reach;
  • client identities it may present;
  • who controls the hostname;
  • whether redirects are followed;
  • lifetime and socket limits;
  • custom DNS or proxy behavior.

Pay special attention to a global singleton that receives per-request TLS options.

Test observed identity, not configuration alone

Build a controlled mTLS test server that records the client certificate fingerprint and requested server name. Send alternating requests for two fake tenants through the application’s real client wrapper.

Assert that tenant A always presents A’s certificate and tenant B always presents B’s certificate, including after keep-alive reuse. Run enough alternation to exercise pooled connections.

For hostname validation, use test certificates for two local names. Confirm the client accepts the matching name and rejects the mismatch even after requests that can establish or resume sessions.

Do not use production certificates or weaken operating-system trust stores for the test.

Roll out the patch

Patch inside the current major line, rebuild containers, and canary the client-heavy workloads. Watch TLS handshake errors, connection reuse, request latency, partner authentication failures, and certificate fingerprints where safely observable.

Correct behavior may create more handshakes if a previous pool incorrectly combined identities. That cost is preferable to identity confusion, but it should be measured so capacity remains stable.

Primary sources

Connection pooling is part of the security boundary when identity varies. Patch the runtime, give each mTLS identity its own pool, preserve hostname checks, and verify the identity observed across reused connections.

Save the two-identity test as a regression check for future Node upgrades.

Run it after certificate rotation as well.