Summary
Eclipse Milo's Call service can authorize methods in a mixed batch but dispatch the original batch to address-space handlers. An anonymous or otherwise low-privileged client may therefore execute a method that should have been denied when it is combined with an allowed method.
Affected context
The vulnerability occurs in Eclipse Milo deployments that expose the OPC UA Call service and process batches containing methods with different authorization outcomes. The risk is present when authorization decisions are calculated for individual requests but the unfiltered, original batch is subsequently passed to address-space handlers.
Exploit preconditions
- Attack surface: OPC UA Call service
- Required access: Anonymous access or credentials providing limited privileges
- Trigger point: Submission of a mixed batch containing an allowed method and a denied method
- Why exploitation is possible: Authorization is evaluated, but the original batch is dispatched without reliably removing denied operations
Why this happens
The underlying bug is an authorization enforcement failure caused by a mismatch between decision data and the operations ultimately executed. The service calculates which calls are authorized but forwards the original mixed request to downstream handlers, allowing a denied operation to bypass the intended policy. This maps to CWE-863: Incorrect Authorization, because access checks do not consistently constrain the action performed.
Potential impact
- An unauthorized client may execute restricted OPC UA methods
- Sensitive device or application operations could be triggered
- Process integrity or operational safety may be affected
- Attackers could use permitted methods as a path to reach higher-impact functionality
General mitigation guidance
Mitigation generally focuses on making authorization decisions authoritative at the execution boundary.
Common defensive patterns include:
- Dispatch only the individually authorized operations rather than the original request batch
- Recheck authorization immediately before invoking address-space handlers
- Apply deny-by-default policies for anonymous and low-privileged clients
- Keep authorization context attached to each operation throughout request processing
- Limit exposed methods and run OPC UA services with the minimum required privileges
These patterns reduce the chance that batching, transformation, or downstream dispatch will bypass access controls.
How teams detect issues like this
Organizations can look for authorization enforcement gaps through:
- Static analysis of batch-processing paths for checks that are detached from the executed collection
- Code review signals where filtered results are calculated but the original request is later dispatched
- Tests combining allowed and denied operations in the same service request
- Runtime auditing of method invocations by identity, authorization result, and batch contents
- Policy enforcement requiring deny-by-default behavior and per-operation authorization checks
Automated security review tools may help identify mismatches between authorization decisions and downstream execution.
