Advisory · CVE-2026-116014
Malicious OPC UA server can overflow the heap in open62541 clients via a custom DataType
open62541 1.5.0 before 1.5.7 has an integer overflow in UA_DataType_fromStructureDescription() that wraps the 16-bit memSize field for large custom structure definitions, so a malicious OPC UA server can make a client overflow the heap when it loads remote DataTypes, crashing it or enabling code execution. Fixed in 1.5.7. CVSS 3.1 8.1.
- Vendor
- open62541
- Product
- open62541
- Identifier / CWE
- CVE-2026-116014
CWE-190 - Action timing
- Immediate
Explain it like I’m five
A client asks a server how its custom data is laid out. The server can describe a structure so large that the size number wraps around to a small one, so the client reserves too little memory and the incoming data spills over it.
- 01Attacker controls a server
An attacker runs or compromises an OPC UA server that a client will connect to.
- 02Client loads remote types
The client calls UA_Client_getRemoteDataTypes() and receives the server DataType definitions.
- 03Size field wraps
A large custom structure definition makes the 16-bit memSize field in UA_DataType_fromStructureDescription() wrap.
- 04Heap overflow follows
Decoding a binary structure against that wrapped size overflows the heap, crashing the client or enabling code execution.
What happened
VulnCheck disclosed CVE-2026-116014 for open62541, the open-source OPC UA (IEC 62541) implementation in C used in industrial automation clients and servers. The NVD record states that open62541 1.5.0 before 1.5.7 contains an integer overflow in UA_DataType_fromStructureDescription() that wraps the 16-bit memSize field for large custom structure definitions, and that a malicious OPC UA server can supply those definitions via UA_Client_getRemoteDataTypes(), causing decodeBinaryStructure() to overflow the heap. The CVSS 3.1 score is 8.1 and the CVSS 4.0 score is 9.2.
The open62541 v1.5.7 release notes state that the core now rejects custom DataType definitions that overflow memSize/membersSize, which is the vendor fix corresponding to this flaw. That matters because the trust direction here is reversed from the usual server bug: the server is the attacker and every client application or gateway embedding the library is the target, including products that vendors build on top of open62541 rather than deployments that carry the name themselves.
What to do
- Inventory OPC UA clients, gateways and vendor products that embed open62541, including in operational technology environments.
- Upgrade affected builds to open62541 1.5.7 or later using the project release guidance; where a vendor embeds the library, apply that vendor update.
- Until updated, only connect clients to OPC UA servers you trust, and restrict which servers a client can be pointed at.
- Review client crash logs and connections to unfamiliar or newly added OPC UA servers for signs of malicious DataType definitions.
- Verify the deployed library version after updating, not just that an update ran.
Management note
Protocol libraries in industrial stacks rarely get inventoried under their own name, so the real work is finding where open62541 is embedded. A client that can be pointed at an untrusted server carries this risk even when your own servers are clean.