This CVE presents as a one-byte heap out-of-bounds read in MMS server BER decoder extended tag handling, and the public score of 6.5 reflects only the denial-of-service symptom. Don't let that number frame your response.
The vulnerability is a bounds-check omission in code that handles extended BER tags — specifically the branch added when extended tag support was bolted onto an existing decoder that already had checking for standard tags. This is a copy-paste failure with a known lineage: every time a developer adds extended tag ranges to an existing ASN.1/BER decoder, the same hazard recurs. The API design pushes boundary tracking to the caller, making the omission structurally inevitable in certain development workflows.
In ICS environments, the one-byte leak is more dangerous than it sounds. MMS implementations typically use fixed-size buffer pools or slab allocators for PDU processing — chosen for deterministic real-time performance, but that predictability benefits attackers too. A confirmed request buffer is often adjacent to session state structures, connection metadata, or protocol state objects. One byte is sufficient to leak a heap metadata pointer, a length field, or partial session material that enables ASLR defeat or session hijacking.
The 'authenticated session required' prerequisite doesn't meaningfully reduce risk in ICS contexts. MMS sessions are long-lived (hours to days), credentials are frequently reused across devices, and network segmentation between IT and OT is operationally porous. An attacker who can reach the MMS endpoint and has baseline access — common in integrator commissioning scenarios — can obtain the required session.
What should you do? First, determine whether your MMS stack uses a common BER decoder library (many vendors inherited parsing code from the same reference implementations). If so, the vulnerability likely isn't isolated to one vendor. Second, treat this as a class-vulnerability disclosure: expect other vendors using similar decoder code to have the same issue, and prioritize inventorying MMS implementations in your environment. Third, for defense-in-depth, evaluate whether your MMS server runs on a hardened allocator — but understand that many embedded ICS platforms lack heap randomization entirely, so don't rely on that. Fourth, monitor for the one-byte OOB read in your crash logs; if you see it repeatedly against MMS endpoints, treat it as potential reconnaissance for a follow-on attack rather than random noise. The real risk isn't the DoS — it's the information disclosure that enables chaining.