CVE-2026-11946 Overview
CVE-2026-11946 is an unauthenticated memory exhaustion vulnerability in the open62541 OPC UA implementation. The flaw resides in the GetEndpoints Discovery Service, where the endpointUrl field of GetEndpointsRequest lacks length validation. A remote attacker can declare an arbitrarily large string, up to approximately 4.09 GB via the UInt32 length field, and deliver it across intermediate chunks without sending the final chunk. The server buffers all chunks in RAM indefinitely until the SecureChannel times out. The attack is pre-session and bypasses all encryption configurations. The issue is tracked under [CWE-770] (Allocation of Resources Without Limits or Throttling).
Critical Impact
A single unauthenticated attacker can exhaust server memory pre-session, causing denial of service against any exposed open62541 OPC UA endpoint regardless of encryption or authentication settings.
Affected Products
- open62541 versions 1.4.0 through 1.4.16
- open62541 versions 1.5.0 through 1.5.4
- open62541 master branch prior to the fix
Discovery Timeline
- 2026-07-02 - CVE-2026-11946 published to NVD
- 2026-07-02 - Last updated in NVD database
Technical Details for CVE-2026-11946
Vulnerability Analysis
The open62541 library implements OPC UA (Open Platform Communications Unified Architecture), a machine-to-machine communication protocol widely used in industrial control systems. The GetEndpoints service allows clients to discover available endpoints before establishing an authenticated session. This pre-session context is critical because it means the vulnerability is reachable by any network attacker who can connect to the OPC UA port.
The endpointUrl field within a GetEndpointsRequest is encoded as an OPC UA String, prefixed with a signed Int32 length. The server accepts the declared length and begins buffering the payload as it arrives across message chunks. Because the server never validates the length against a reasonable upper bound, an attacker can advertise a payload up to roughly 4.09 GB and stream partial chunks slowly. The final chunk is never delivered, so the server continues holding all buffered data until the SecureChannel timeout elapses.
Root Cause
The root cause is missing input validation on the endpointUrl length field during chunked message reassembly. The implementation trusts the client-declared length and allocates or accumulates memory proportional to it. There is no early rejection of oversized strings and no incremental cap on aggregate chunk buffering per unauthenticated peer.
Attack Vector
Exploitation requires only network access to the OPC UA listener. The attacker opens a SecureChannel, sends a GetEndpointsRequest declaring a maximum-length endpointUrl, and transmits intermediate chunks without ever completing the message. Multiple parallel connections multiply the memory pressure until the server exhausts RAM or begins swapping, disrupting availability. The attack requires no credentials, no user interaction, and works against servers configured with any security policy.
No verified exploitation code is publicly available. Refer to the open62541 GitHub Pull Request #8142 for the corrective changes and technical context.
Detection Methods for CVE-2026-11946
Indicators of Compromise
- Sustained growth in resident memory of open62541 server processes without a corresponding increase in active sessions.
- Multiple long-lived SecureChannels from a single source that never complete GetEndpointsRequest messages.
- Repeated inbound OPC UA chunks with abnormally large declared string lengths on the discovery endpoint.
Detection Strategies
- Inspect OPC UA traffic for GetEndpointsRequest messages where the endpointUrl length header approaches the UInt32 maximum.
- Correlate incomplete chunked messages with rising per-process memory metrics on hosts running open62541.
- Alert on SecureChannel sessions that remain open near the configured timeout without completing an initial service request.
Monitoring Recommendations
- Track RSS and heap growth of OPC UA server processes and alert on deviations from baseline.
- Log connection duration, chunk counts, and completion status for every SecureChannel handled by open62541.
- Forward network telemetry from OPC UA-exposed segments into a SIEM for behavioral analysis of pre-session traffic.
How to Mitigate CVE-2026-11946
Immediate Actions Required
- Upgrade open62541 to a fixed release beyond 1.4.16 and 1.5.4 once published, or apply the patch from Pull Request #8142.
- Restrict network access to OPC UA discovery endpoints so only trusted engineering and management networks can reach them.
- Enforce operating system memory limits (cgroups, ulimits) on the open62541 process to contain the impact of exhaustion attempts.
Patch Information
The upstream fix is delivered through open62541 GitHub Pull Request #8142, with the specific changes visible in the associated diff. Consult the open62541 project repository for tagged releases incorporating the fix.
Workarounds
- Reduce the SecureChannel timeout so incomplete chunked messages are discarded sooner, limiting how long buffered data persists.
- Place a protocol-aware proxy or firewall in front of the server to reject GetEndpointsRequest messages with unreasonable declared lengths.
- Rate-limit new SecureChannel establishments per source IP to constrain parallel exhaustion attempts.
# Configuration example: constrain the open62541 service via systemd resource limits
# /etc/systemd/system/open62541.service.d/override.conf
[Service]
MemoryMax=512M
MemoryHigh=384M
TasksMax=256
Restart=on-failure
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
