Smart Machines & Factories Editorial TeamOn November 3, 2026, a critical authorization-bypass vulnerability tracked as CVE-2026-95860 was disclosed in node-opcua, the widely used OPC UA implementation for TypeScript and Node.js that integrators embed in bridges, historian connectors and custom SCADA front ends. The flaw scores 9.1 Critical on CVSS v3.1 and applies to every release from 2.42.0 through 2.179.9 — effectively the entire modern history of the library before the patch.
A Permission Check That Fails Open
The bug sits in SessionContext.getApplicableRolePermissions, the function node-opcua uses to decide whether a given client session is allowed to write a variable or call a bound method on a node that has no explicit per-node RolePermissions set. In that case, the runtime is supposed to fall back to the namespace-level default configured through setDefaultRolePermissions. Instead, it reads a missing or null DefaultRolePermissions metadata field and treats that null result permissively rather than denying access. An operator who configured a restrictive namespace default and relied on it being inherited down to every node gets no warning that the inheritance silently never happened.
CVE-2026-95860 — Key Facts
- Severity — CVSS v3.1 9.1 Critical;
- Affected versions — node-opcua 2.42.0 through 2.179.9;
- Root cause — namespace
DefaultRolePermissionsis not honored by the runtime enforcement path for nodes without explicit per-node permissions; - Impact — an anonymous network client can write variables with CurrentWrite access or call bound methods that should have been restricted;
- Who is exposed — servers that accept Anonymous sessions and rely on namespace-level defaults instead of setting explicit per-node RolePermissions; servers with no declared policy or with correct per-node configuration are not affected;
- Fix — upgrade to node-opcua 2.180.0 or later.
Why "Anonymous" Access Still Matters in OT
Allowing anonymous OPC UA sessions is common in brownfield deployments where legacy clients never implemented certificate-based authentication, so operators lean on namespace-level role policies as the compensating control: anonymous read is fine, anonymous write is not. CVE-2026-95860 breaks exactly that assumption. A client that was never meant to touch anything beyond read access can write process variables or trigger bound methods on any node that inherited from the broken default — without presenting a certificate, a username, or any credential at all. On a factory floor, that is the difference between a dashboard that displays a setpoint and a client that can quietly change it.
The Patch Is Small; the Exposure Audit Is Not
Bumping a package.json dependency to node-opcua 2.180.0 is a one-line change. The harder work is finding every server instance that actually relies on the broken behavior:
- enumerate which custom bridges, gateways and integration services embed node-opcua as a transitive dependency;
- confirm whether each one declared per-node RolePermissions explicitly or leaned on the now-fixed namespace default;
- re-test client sessions against the patched enforcement path before it goes back into a production line.
Tightening a permission check that was silently failing open can also break a legitimate integration that unknowingly depended on the bug, which is why that last step matters as much as the version bump itself.
That is exactly the kind of audit and remediation work YuSMP Group's API development team handles for plants running custom OPC UA integrations: tracing which services actually embed node-opcua, rebuilding the permission model with explicit per-node rules instead of namespace defaults, and validating the upgrade against real client traffic before it reaches a production floor.
Sources: OpenCVE, CVE-2026-95860 record; Ostorlab, "node-opcua RBAC Bypass: Anonymous Writes to OPC UA".