CVE-2026-67861
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.
Reviewed through automated stages and approved by a human before publication.