CVE-2026-67861 is a client-side denial-of-service in open62541's UA_Client_getRemoteDataTypes function. A compromised or impersonated OPC UA server can send a crafted response that crashes any client calling this function. The CVSS 7.5 score is appropriate — this is genuinely high-severity — but the EPSS score of 0.00417 understates the risk in OT environments for a structural reason: the exploitation preconditions are far more plausible in industrial deployments than in typical IT networks.
The asymmetry is the key concern. In hub-and-spoke OT architectures where dozens or hundreds of field devices (PLCs, embedded controllers, edge gateways) query a central OPC UA server, a single malicious server becomes a mass-casualty weapon. One compromised server can DOS an entire fleet of clients simultaneously. This is not a vulnerability you wall off at the perimeter — the attack surface lives in every client that queries untrusted servers, which in OT environments often means every field device in your deployment.
What makes this worse: the disclosure does not specify whether the root cause is memory corruption, a logic error, or resource exhaustion. Without that detail, you cannot determine whether this is a 'never call this with untrusted servers' problem or a 'don't call it under these specific conditions' problem. Those two answers lead to completely different remediation paths. Until more detail emerges, treat any open62541 client that calls getRemoteDataTypes as vulnerable when connecting to non-trusted servers.
Prioritize remediation along this logic: the highest-impact fix is hardening or securing the server side — restricting who can impersonate your OPC UA servers, implementing certificate validation, and network-segmenting server nodes. Patching every client device in a distributed OT environment takes weeks or months; hardening the server takes less effort and reduces more risk. If getRemoteDataTypes is not essential to your application, consider removing that call entirely — the function exists in the public API but creates a trust boundary that many deployments did not architect for.
Check your client deployments: identify which open62541 instances call getRemoteDataTypes, evaluate whether that capability is actually needed, and if it is, treat those clients as requiring priority patching once a fix is available.