Skip to content

node-opcua missing nonce verification in UserNameIdentityToken authentication

High severity GitHub Reviewed Published Jul 3, 2026 in node-opcua/node-opcua • Updated Aug 20, 2026

Package

npm node-opcua (npm)

Affected versions

<= 2.165.0

Patched versions

None

Description

Summary
A missing nonce verification in the UserNameIdentityToken authentication handler allows an unauthenticated remote attacker to forge a password token that extracts as an empty string, and to replay captured authentication tokens across sessions.

Affected versions: <= 2.165.0
Tested version: 2.165.0
CVSS Score: 8.1 (High)
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L
CWE: CWE-347 Improper Verification of Cryptographic Signature


Root Cause

In packages/node-opcua-server/source/opcua_server.ts at line 1886-1887, after RSA-OAEP decrypting the UserNameIdentityToken password blob, the server reads a 4-byte little-endian length field and extracts buff[4 : 4+length] as the password. It never verifies that the trailing bytes equal session.nonce.

This has two consequences:

  1. Forged empty password: An attacker who retrieves the server's public key via an unauthenticated GetEndpoints call can craft a token where the 4-byte length field equals serverNonce.length (32). The server computes length = 32 - 32 = 0 and calls isValidUser(username, ""). Any account that accepts an empty password is compromised.

  2. Unconditional replay attack: Because nonce binding is structurally absent, any captured UserNameIdentityToken ciphertext can be replayed in a different session unconditionally.

The impact is compounded by a second issue: when the channel uses SecurityMode=None, verifyClientSignature returns true unconditionally (security_policy.ts:697-700), bypassing the channel-level signature check entirely.


Proof of Concept (logic, no exploit code)

1. GetEndpoints (unauthenticated) → retrieve server public key and RSA token policy
2. OpenSecureChannel (SecurityMode=None)
3. CreateSession
4. Craft plaintext: [0x20, 0x00, 0x00, 0x00]  (readUInt32LE = 32 = serverNonce.length)
5. RSA-OAEP encrypt with server public key → 256-byte ciphertext
6. ActivateSession with crafted UserNameIdentityToken
7. Server decrypts → length = 32 - 32 = 0 → password = ""
8. isValidUser(username, "") is called

Dynamically confirmed: decryption produces password = "" with no error and no nonce verification.


Suggested Fix

After decrypting the password blob, verify that buff.slice(4 + passwordLength) equals session.nonce before extracting the password. Reject the token if verification fails.


I am following a 90-day responsible disclosure policy. I am happy to provide additional technical details under embargo. Please confirm receipt at your earliest convenience.

Reporter: Stanley Tobias
Discovery date: 2026-03-23

References

@erossignon erossignon published to node-opcua/node-opcua Jul 3, 2026
Published to the GitHub Advisory Database Aug 20, 2026
Reviewed Aug 20, 2026
Last updated Aug 20, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
Low

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L

EPSS score

Weaknesses

Improper Verification of Cryptographic Signature

The product does not verify, or incorrectly verifies, the cryptographic signature for data. Learn more on MITRE.

CVE ID

CVE-2026-54155

GHSA ID

GHSA-mq36-523m-x7vv

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.