Summary
Eclipse Milo's OpcUaServerConfig.copy() may drop a configured RoleMapper, causing sessions to receive no role IDs and allowing the default access controller to bypass role-permission checks. On affected servers that permit anonymous sessions, an anonymous client may read role-permission metadata, invoke protected methods, or delete protected nodes.
Affected context
The issue occurs in Eclipse Milo deployments within the affected version range when authorization depends on a configured RoleMapper and the running server configuration is created through OpcUaServerConfig.copy(). Risk is higher when anonymous sessions are enabled and protected methods, nodes, or role-permission metadata are exposed through the server.
Exploit preconditions
- Attack surface: OPC UA server endpoints and exposed node or method
operations
- Required access: A client session that can connect to the server; anonymous
access may be sufficient where it is enabled
- Trigger point: Construction of the active server configuration through
OpcUaServerConfig.copy(), followed by authorization decisions
- Why exploitation is possible: The copied configuration does not preserve
the RoleMapper, so sessions may lack role IDs and the default access
controller may skip role-permission checks
Why this happens
The underlying defect is a configuration-copying error that silently omits a security-relevant authorization component. Because the active configuration no longer contains the expected RoleMapper, role information is not assigned to sessions and authorization logic can evaluate requests without the intended role-permission constraints. This behavior maps to CWE-862, Missing Authorization, because protected operations may be reached without an effective permission check.
Potential impact
- An anonymous or insufficiently authorized client may read role-permission metadata.
- A client may invoke methods intended to require specific roles.
- A client may delete nodes that should be protected by role permissions.
- The server's authorization boundary may be weakened, potentially affecting data integrity and service availability.
General mitigation guidance
Mitigation generally focuses on preserving security-relevant authorization state whenever server configuration is copied or transformed. Configurations can use secure-by-default authorization behavior that denies protected operations unless an authenticated identity has the required role. Anonymous access can be limited to explicitly public endpoints, while role mappings, permission policies, and configuration transformations can be validated before the server accepts traffic. Least-privilege identities and narrowly scoped node and method permissions can reduce impact if an authorization component is missing or misconfigured.
How teams detect issues like this
Detection can include static analysis and review rules that compare all security-sensitive fields between configuration constructors, copy methods, builders, and serializers. Code review should flag omitted role, identity, permission, or policy components in configuration transformations. Integration tests can exercise anonymous and authenticated sessions against protected methods and nodes, verifying that denied operations remain denied after configuration copying. Policy enforcement may also require explicit tests for anonymous access and authorization regression coverage.
