node-opcua Namespace RBAC Fail-Open: Anonymous Clients Can Write Variables and Call Methods (CVE-2026-95860)

What happened

A GitHub Security Advisory (GHSA-xggf-m53x-jc3f, CVE-2026-95860) discloses a critical authorization flaw in node-opcua, a popular npm implementation of the OPC UA industrial protocol. According to the advisory, when a Node lacks an explicit per-node RolePermissions attribute, the library's enforcement path is supposed to fall back to the namespace's DefaultRolePermissions. Instead, the advisory reports that getPermissionForRole() returns all permissions (Read, Write, Call) whenever that lookup resolves to null — the opposite of the default-deny behavior mandated by the OPC UA spec (Part 3, §4.8.3). The advisory further describes a disconnect between the configuration API (setDefaultRolePermissions(), which writes to a private field) and the runtime enforcement path (which reads a separate DefaultRolePermissions UAVariable node) — meaning an operator who calls setDefaultRolePermissions() without also calling setNamespaceMetaData() has not actually restricted anything, and on NodeSet2-loaded namespaces that binding call reportedly throws an error, leaving no working way to apply the namespace default at all. The advisory notes CVSS 9.1 and a publicly available PoC.

Per the advisory, this specifically affects deployments where an operator declared a namespace-level default policy expecting it to be enforced. Servers that never configured any RolePermissions are described as behaving per documented (permissive) defaults and are not considered newly exposed by this bug.

Why it matters for defenders

node-opcua is widely embedded in industrial control and SCADA-adjacent software for OPC UA connectivity. The advisory's PoC demonstrates an anonymous, unauthenticated client successfully calling a bound Method (e.g., an emergency-shutdown style operation) and writing to a process Variable (e.g., a setpoint) despite the operator having configured namespace-level RBAC intended to block exactly that. Because Methods have no secondary AccessLevel gate and default to executable, the impact described ranges from unauthorized configuration changes to availability-impacting actions on any bound Method tied to operational control, in deployments that rely on namespace-level rather than explicit per-node permissions.

What defenders should watch for now

• Inventory any OPC UA servers or gateways built on node-opcua (check package.json/lockfiles for node-opcua, node-opcua-address-space, node-opcua-server) and determine whether they rely on namespace-level DefaultRolePermissions rather than per-node permissions.
• Review OPC UA server logs/network captures for Anonymous-token sessions performing Write or Call service requests against nodes that were expected to require an authenticated role — this is the behavior the advisory's PoC reproduces.
• As an interim mitigation per the advisory's analysis, explicit per-node RolePermissions are correctly enforced even when the namespace default is broken — consider auditing and hardening critical Variables/Methods with explicit per-node policies rather than relying solely on namespace defaults.
• Where feasible, restrict or disable Anonymous authentication on OPC UA endpoints at the network/firewall or server-configuration layer until a patched release is confirmed available.
• Track the upstream repository for a fix implementing fail-closed behavior (returning no permissions rather than all permissions on an unresolved policy) and unifying the configuration/enforcement paths described in the advisory.

Developing intel

This is a same-day disclosure and df00tech has not independently verified the proof-of-concept beyond what is documented in the advisory. Details such as a confirmed fixed version are not yet established in the source material. For the full technical writeup, root-cause analysis, and proof-of-concept code, see the original GitHub Security Advisory: GHSA-xggf-m53x-jc3f.