CVE-2026-84197: Critical severity npm/@eclipse-ditto/ditto-javascript-client-node vulnerability
In Eclipse Ditto's Node.js JavaScript client, all released versions of @eclipse-ditto/ditto-javascript-client-node from 2.0.0 to 3.9.0 and of its predecessor package @eclipse-ditto/ditto-javascript-client-node1.0 from 1.0.0 to 2.1.0, the WebSocket transport hard-codes rejectUnauthorized: false when creating the underlying ws WebSocket. Certificate chain and hostname validation are therefore disabled for every wss:// connection, and no builder option, constructor argument or environment variable lets an application turn validation back on. An attacker in a position to intercept the connection can present an arbitrary certificate, complete the TLS handshake, read the credentials that the configured authentication provider sends in the Authorization header of the WebSocket upgrade request, and read, alter or inject Ditto Protocol messages for the lifetime of the connection. The Java client, the browser/DOM JavaScript client and the HTTP transport of the Node.js client are not affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
@eclipse-ditto/ditto-javascript-client-nodeto a version that resolves this vulnerability.Fixed in 3.9.0 - Upgrade
Upgrade
@eclipse-ditto/ditto-javascript-client-node_1.0to a version that resolves this vulnerability.Fixed in 2.1.0 - Compensating control
For any wss:// connection used by the Node.js JavaScript client where certificate chain/hostname validation is disabled (rejectUnauthorized hard-coded to false), prevent connection interception (e.g., do not allow untrusted network paths; restrict and monitor network routes so the connection cannot be intercepted).
- Operational
If Authorization header credentials may have been exposed during intercepted WebSocket connections, rotate/reset those credentials before reusing them.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using the Node.js client's WebSocket transport over wss:// are exposed in the affected package ranges. The Java client, browser/DOM JavaScript client, and the Node.js client's HTTP transport are not affected.
What does an attacker need to exploit it?
An attacker must be able to intercept the application's wss:// connection. They can then use an arbitrary certificate to complete TLS, capture credentials sent in the WebSocket upgrade Authorization header, and read, modify, or inject Ditto Protocol messages.
Can certificate validation be enabled through configuration as a workaround?
No. The affected WebSocket transport hard-codes rejectUnauthorized: false, and the provided data states that no builder option, constructor argument, or environment variable can re-enable validation.