The heap buffer overflow in open62541 1.5.5 lives in the memory backend—the default history store that ships enabled out of the box. This isn't an optional plugin; it's the built-in storage mechanism for OPC UA history features, which industrial deployments use for trending, compliance logging, and audit trails. If you're running open62541 with history enabled (common in manufacturing and energy OPC UA servers), you're executing this code path by default.
The 7.5 CVSS with 0.00267 EPSS tells a clear story: this is an authenticated-user vulnerability. History read operations in OPC UA require valid client credentials, which constrains exploitation to attackers who already have session access. The heap overflow sits in the read response path, not in allocation routines, which further limits what an attacker can control.
For defenders: verify your authentication configuration on history read operations. If anonymous history queries are allowed, this becomes network-adjacent exploitable—check your server's AccessControl settings. The memory backend is default-enabled precisely because it's the fallback when no external database is configured, so audit whether you've intentionally configured SQLite, Redis, or another backend instead of leaving the default in production. If you rely on the memory backend, prioritize this patch regardless of the low EPSS—history databases feed compliance logs and operational trending that downstream systems trust without verification.
The key question the CVE description leaves unanswered: what specific data structure in the HistoryRead response triggers the overflow (string length, array bounds, pointer arithmetic)? Watch the vendor patch for this detail—it will determine whether the constraint is in parsing the response or in storing retrieved values.