The CVE describes a buffer overflow in Open1722 before version 0.9.2—an Audio Video Transport Protocol stack used in automotive Ethernet. The vulnerability: an unbounded write index into a 15-slot array, triggered by a hardcoded unauthenticated stream ID transmitted in plaintext over UDP. Send the right bytes to the right port and the listener complies. That's the exploitability model. CVSS 7.5 badly understates the risk.

This is not merely a bounds-check bug. It's a protocol architecture that encodes an assumption of network-layer trust that modern vehicle Ethernet designs actively invalidate. The hardcoded stream ID reflects a design choice made when AVTP ran over isolated segments—'the network is the security boundary,' a developer rationale that stops reasoning about sender validation entirely. Contemporary vehicle architectures collapse that isolation through Ethernet backbones, central gateways, and connected services. An attacker who reaches any network-adjacent node is already inside the trust perimeter this design relies upon. The UDP transport compounds this: no handshake, no session state, no replay protection.

The EPSS score of 0.02361 is misleading in this sector context. EPSS models general exploitability across internet-facing software; it does not capture the patch-velocity reality in embedded automotive where firmware updates require supplier coordination, homologation cycles, or physical access. A CAN bus adapter running this code may remain vulnerable for years not because the fix is complex but because update propagation through the supply chain is slow.

The blast radius is where this becomes qualitatively worse than a typical buffer overflow. Open1722 typically runs avtp_to_can()—a bridge function converting AVTP streams to CAN messages. Exploiting this doesn't give you RCE on a standalone ECU; it gives you RCE on a node whose outputs feed directly into vehicle dynamics. Corrupt the CAN output of a bridge ECU, and every ECU listening on that bus receives attacker-controlled signal content. The cascade runs through the protocol's actual function, not through generic code execution. If firmware-resident persistence is achieved, the ECU update mechanism becomes a vector for perpetuating compromise across vehicle fleets rather than remediating it.

The fix—bounds checking the write index—is mechanically trivial. The harder problem is that Open1722 likely exists as middleware from a Tier 1 supplier, compiled into firmware images, requiring reconvergence across the supply chain and recertification. The patch may sit in a git branch while vulnerable versions ship in 2027 model-year vehicles.

Audit your fleet for AVTP and Open1722 implementations. Determine whether the stream ID is configurable or hardcoded. Map data flows from AVTP ingress through avtp_to_can() conversion to CAN bus outputs. Assess network topology to identify where the vulnerable component sits relative to safety-critical domains. Assume the patch will take 12-18 months to reach fielded vehicles, and plan accordingly.