Description

node-opcua is an OPC UA implementation for TypeScript and Node.js. Prior to 2.166.0, the UserNameIdentityToken authentication handler in packages/node-opcua-server/source/opcua_server.ts decrypts an RSA-OAEP password blob but does not verify that the trailing bytes match the current session serverNonce. An unauthenticated remote attacker can obtain the server public key through GetEndpoints and forge a blob whose little-endian length produces an empty password passed to isValidUser, compromising accounts that accept an empty password. Missing nonce binding also allows a captured UserNameIdentityToken ciphertext to be replayed in another session, and SecurityMode=None removes the separate client-signature safeguard. This issue is fixed in version 2.166.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-14T17:17:46.737Z",
  "pubdate": "2026-09-14T17:17:46.737Z",
  "executiveSummary": "The vulnerability involves an authentication bypass and replay flaw within the UserNameIdentityToken handler of node-opcua versions prior to 2.166.0. An improper implementation of RSA-OAEP decryption fails to enforce serverNonce validation, creating a critical security deficit.\nThis vulnerability allows an unauthenticated remote attacker to craft malicious authentication blobs or replay captured tokens. By manipulating the decrypted password length, an attacker can coerce the server into processing an empty password string. This significantly increases the risk of unauthorized account access, particularly for deployments configured with insecure authentication requirements or SecurityMode=None, which eliminates essential cryptographic signature safeguards.\nThe issue primarily affects the node-opcua server component, exposing systems to potential credential exploitation and session hijacking. Because the server fails to bind the UserNameIdentityToken to the specific session context via the nonce, the integrity of the authentication flow is compromised, necessitating immediate patching to version 2.166.0.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the UserNameIdentityToken handler within packages/node-opcua-server/source/opcua_server.ts. During the RSA-OAEP decryption process of the password blob, the server fails to perform a validation check against the current session's serverNonce. The serverNonce is a critical security element intended to ensure freshness and bind an authentication request to a specific, unique session.\nIn the vulnerable implementation, the decrypted blob's structure is parsed without verifying the trailing bytes, which are expected to contain the nonce. An attacker can leverage this by obtaining the server's public key via the unauthenticated GetEndpoints service. Using this public key, the attacker crafts a custom-encrypted blob. By specifically manipulating the little-endian length field within this blob, the attacker can force the application logic to treat the password as an empty string when passed to the isValidUser function.\nFurthermore, the lack of serverNonce binding facilitates a replay attack. Because the server does not verify that the nonce included in the token matches the session in which it is presented, a valid UserNameIdentityToken captured from a previous communication can be replayed by an attacker in a new, independent session. The risk is compounded significantly when the SecurityMode is set to None, as the protocol fails to provide a client-side signature that would otherwise verify the authenticity and integrity of the authentication request independently of the encrypted blob.\nThe attack flow proceeds as follows: 1) The attacker initiates an OPC UA connection and retrieves the server's public key from the GetEndpoints service. 2) The attacker constructs an RSA-OAEP encrypted payload designed to trigger an empty password evaluation due to the lack of length validation. 3) The attacker submits this payload within a UserNameIdentityToken. 4) The server decrypts the blob but fails to validate the nonce, processing the fabricated empty password. 5) If the target account permits an empty password, the authentication process succeeds, granting the attacker access to the server. 6) Alternatively, an attacker captures a legitimate token and reuses it in a separate session, bypassing authentication entirely because the server does not enforce session-to-nonce correlation."
}