node-opcua CVE-2026-95860

Exploitation requires that the server operator explicitly configured a restrictive namespace-level policy via Namespace.setDefaultRolePermissions() and relied on inheritance for nodes that have no explicit per-node RolePermissions; that configured default is silently ignored on the enforcement path and fails open to allPermissions for any role including Anonymous. The target node must lack its own per-node RolePermissions (explicit per-node permissions are still enforced) and have CurrentWrite in its access level or be a bound callable Method. Limiting factors: servers that declared no access-control policy at all are only the documented permissive default (not this bypass); nodes with explicit per-node permissions and namespaces whose metadata was correctly bound via setNamespaceMetaData() are not affected; and on NodeSet2-loaded namespaces setNamespaceMetaData() throws, so activating a working namespace default there is not possible at all. The only complete fix stated by the vendor is upgrading to 2.180.0.

Signals mostly align on high priority but with an important real-world caveat. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H) and 9.1 score describe a remote, unauthenticated authorization fail-open, and the vuln.today Decision label is act_now, so this should be treated as urgent rather than deferred. However, EPSS is not provided in the input and there is no CISA KEV entry or active-exploitation claim, so widespread opportunistic exploitation is not evidenced; the only exploitation artifact is the proof-of-concept code published inside the GHSA advisory. The critical nuance the raw CVSS hides is configuration-dependence: per the advisory this 9.1 bypass applies to case 2 only - a server where an operator actually called setDefaultRolePermissions() with a restrictive policy and relied on namespace inheritance. Servers that declared no access-control policy are the documented permissive default (not a bypass), and nodes with explicit per-node RolePermissions or correctly bound programmatic metadata are outside the affected case. So PR:N is accurate for the attacker (anonymous), but the exposure is gated by a specific vendor-side configuration pattern, which narrows the real-world population below what a bare 9.1 implies. Net: a genuine high-priority fix for OPC UA servers that configured namespace-level RBAC, not a universally exploitable flaw against every node-opcua deployment.

An operator running node-opcua 2.42.0-2.179.x locks down a namespace with setDefaultRolePermissions([Operator]) and relies on inheritance for nodes that carry no per-node RolePermissions. Because the configured policy is written to a private field that the runtime enforcement path never reads, the namespace default resolves to null and fails open, so an anonymous network client can write CurrentWrite variables and call bound methods that should have returned Bad_UserAccessDenied. The advisory ships working reproduction code (passing address-space unit tests PoC-A and an end-to-end TCP PoC-B).