librtmp EUVD-2026-103503

Exploitation requires the victim client to establish an RTMP session with an attacker-controlled server or for an attacker to hold a man-in-the-middle position on an existing RTMP connection (UI:P reflects this victim-initiated connection). The specific trigger is an AMF0 message body that terminates with a strict-array type marker followed by fewer than four trailing bytes, parsed by AMFProp_Decode in librtmp through 2.6. Limiting factors: no authentication bypass or code execution is achieved - impact is limited to crashing the client (availability only); the attacker cannot act purely remotely without the client first connecting outbound to the malicious endpoint, and RTMP over TLS (rtmps) or network controls that prevent MITM reduce the on-path variant.

This is a genuinely medium/low-priority issue, not a high-severity emergency, and the signals are internally consistent. The provided CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:P/VC:N/VI:N/VA:L) describes a network-reachable but low-availability-impact flaw whose only effect is a client-side crash (denial of service) - confidentiality and integrity impact are explicitly None, so despite the 'Information Disclosure' tag this is effectively a DoS. Crucially, exploitation is not fully attacker-driven: UI:P (passive user interaction) reflects that the victim must initiate or accept an RTMP connection to an attacker-controlled or man-in-the-middle position, which is a meaningful limiter. No EPSS score, no CISA KEV listing, and no explicitly flagged POC were supplied; a third-party technical write-up (hackmd) is referenced but a working exploit is not confirmed in the input, so this should be treated as 'no public exploit identified' rather than active exploitation. The 5.3 CVSS 4.0 base score is consistent with the description. Net: a defender should patch in the normal maintenance cycle but need not treat it as an exploited-in-the-wild priority. No conflicting signals were found; the main gap is the absence of EPSS and any authoritative confirmation of real-world exploitation.

A user runs an RTMP client built on librtmp (e.g., rtmpdump or an application embedding it) and connects to a rtmp:// URL, or an on-path attacker intercepts an existing RTMP session. The malicious or tampered server returns an AMF0 body that ends with a strict-array type byte but fewer than four trailing bytes, causing AMFProp_Decode to read the element count out of bounds and crash the client. No public exploit is confirmed in the provided data, though a third-party technical write-up describing the flaw is referenced.