CVE-2026-56850

What it actually does

This vulnerability affects Node.js HTTPS Agent connection reuse when applications use mutual TLS with different client certificates supplied through PFX object arrays. A key-collision flaw in how connection reuse is determined can cause an existing TLS connection authenticated with one client identity to be reused for a request that was configured to use a different client certificate. The primary impact is integrity: outbound requests may be sent under the wrong mTLS client identity, potentially authorizing actions or accessing services as an unintended principal. The issue is local/application-context dependent and requires a privileged attacker or faulty application path capable of influencing HTTPS Agent options or request configuration; it is not a typical unauthenticated remote code execution issue.

Why it matters to the business

Applications that rely on Node.js mTLS to separate tenants, services, customers, or privilege levels may send requests using the wrong certificate identity. This can result in unauthorized transactions, incorrect audit attribution, policy bypass between backend services, or failed compliance controls around strong service identity. Risk is highest for Node.js services that use shared HTTPS Agents, connection pooling, and multiple client certificates for outbound calls. The currently reported exploitation likelihood is low, with low EPSS, no known public exploit maturity, and no CISA KEV listing, but affected long-term Node.js 22.x, 24.x, and 26.x deployments should still be patched because identity mix-ups in trust-boundary code can have high operational consequences.

How an attack unfolds

An attacker first needs a position where they can influence or trigger Node.js HTTPS requests using different mTLS client certificate configurations, typically through application logic, plugin code, job definitions, privileged configuration, or another already-compromised component. They then cause the process to make an HTTPS request using one PFX object-array certificate identity, establishing or reusing an agent-managed TLS connection. Next, they trigger another request that is intended to use a different PFX object-array identity but collides in the HTTPS Agent connection reuse key. Because of the collision, Node.js may reuse the existing authenticated connection rather than creating a separate TLS session with the intended certificate. The target mTLS-protected service sees the request as coming from the previously authenticated client identity, allowing the action to be performed or logged as the wrong service or principal.

How to fix it

Upgrade affected Node.js packages to fixed versions or later. For Red Hat packages, update nodejs22-main to 22.23.2-2.3.hum1 or later, nodejs24-main to 24.18.1-0.1.hum1 or later, and nodejs26-main to 26.5.1-1.5.hum1 or later, as provided in RHSA-2026:48273. Where immediate upgrade is not possible, reduce risk by avoiding shared HTTPS Agents across different mTLS identities, disabling keep-alive or connection pooling for requests that use different client certificates, using separate Agent instances per certificate identity, and ensuring each trust boundary has isolated outbound client configuration. Review applications for PFX object-array usage and confirm that outbound mTLS identity selection is deterministic and not user-controllable.

How to confirm the fix worked

Confirm the installed Node.js runtime or Red Hat Node.js package is at or above the fixed version for the active major release. Validate with package manager queries and runtime version checks, then restart Node.js services so patched binaries are actually in use. Review dependency containers and base images because Node.js runtimes may be bundled into application images. Functionally test applications that use multiple mTLS client identities by sending sequential requests through the same process and confirming each destination service observes the intended client certificate subject, issuer, and fingerprint. Also verify that code uses separate HTTPS Agent instances per certificate identity if mitigation rather than patching is temporarily applied.

Typical attack path

1. Gain the ability to influence a Node.js application's outbound HTTPS request options, certificate selection, or privileged workflow inputs.
2. Identify that the application uses mTLS with PFX object-array client certificates and a reusable HTTPS Agent or connection pooling.
3. Trigger a request that establishes an HTTPS connection authenticated with one client certificate identity.
4. Trigger a second request intended to use a different client certificate configuration that collides in the Agent's connection reuse key.
5. Cause Node.js to reuse the prior TLS connection, making the second request appear to the destination service as the first client identity.
6. Use the identity confusion to perform unauthorized operations, bypass service-level authorization assumptions, or create misleading audit records.

How to detect it

There is no universal network IOC because exploitation results in legitimate TLS connections using valid client certificates, not a distinctive payload. Detection should focus on behavioral and audit inconsistencies. Review logs from mTLS-protected services, API gateways, service meshes, and authorization systems for requests where the observed client certificate subject, issuer, serial number, or fingerprint does not match the expected calling service for that endpoint or operation. Correlate Node.js application logs with downstream service logs to find sequences where a single process rapidly performed outbound calls that should have used different mTLS identities but the downstream service recorded the same certificate identity. Look for authorization decisions, writes, or administrative actions attributed to a valid certificate that is unusual for the resource, tenant, workflow, or time period. On hosts and containers, identify affected Node.js versions and applications using pfx arrays, https.Agent keepAlive, agent reuse, or custom certificate-selection logic. If reverse proxies or service meshes terminate mTLS, inspect their access logs for certificate subject/fingerprint anomalies rather than relying only on application logs.

• node --version
• nodejs22-main-22.23.2-2.3.hum1
• nodejs24-main-24.18.1-0.1.hum1
• nodejs26-main-26.5.1-1.5.hum1
• new https.Agent
• keepAlive: true
• pfx: [
• pfx:[

What your security team should do

• Inventory Node.js 22.x, 24.x, and 26.x deployments, including containers, CI runners, serverless images, and embedded application runtimes.
• Prioritize patching services that use outbound mTLS with multiple client certificates, PFX object arrays, shared HTTPS Agents, or keep-alive connection pooling.
• Upgrade Red Hat nodejs22-main, nodejs24-main, and nodejs26-main packages to the fixed versions from RHSA-2026:48273 or later.
• If patching is delayed, require separate HTTPS Agent instances per mTLS identity or disable connection reuse for certificate-sensitive outbound calls.
• Ask application teams to review code paths where request certificate selection can be influenced by user input, workflow data, plugins, or administrative configuration.
• Monitor mTLS-protected service logs for mismatches between requested operation, expected caller identity, observed certificate subject, and application-level actor.
• Refresh container base images and redeploy workloads after patching; do not rely only on rebuilding application dependencies.
• Treat unexplained authorization events attributed to valid client certificates as possible identity-confusion events, even if no credential theft is evident.