Zephyr Bluetooth AVRCP EUVD-2026-115821

The target must run Zephyr 4.4.0-4.4.x (fixed in 4.5.0) built with the Bluetooth Classic AVRCP Target role enabled. The attacker must be a peer already paired with the device and within Bluetooth radio range, because the AVCTP control channel requires an encrypted BR/EDR link (BT_SECURITY_L2). The trigger is concrete and stated in the source: send a vendor-dependent command whose response exceeds one AVRCP fragment (e.g. GetElementAttributes or GetCapabilities), allow the START fragment to be emitted, then drop the ACL link instead of sending REQUEST_CONTINUING_RESPONSE. No user interaction is needed. Limiting factors: the mandatory prior pairing and encryption, physical adjacency, and the requirement that the device actually implements the AVRCP Target role with fragmented vendor-dependent responses - devices without BR/EDR AVRCP Target are unaffected.

This is a genuine-but-moderate issue, correctly rated below critical. The CVSS 3.1 vector (AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L, 4.6 Medium) is consistent with the mechanism described: exploitation needs adjacency (Bluetooth radio range) and an already-paired, encrypted BR/EDR link (the AVCTP control channel enforces BT_SECURITY_L2), so PR:L reflects that the attacker must be a previously-paired peer, not an anonymous remote actor. No EPSS score and no SSVC exploitation/automatable/technical-impact values were supplied, and there is no CISA KEV listing and no public exploit reference - only the vendor patch commit and GHSA advisory. The vuln.today priority is 'this_month' (not act_now/emergency), which aligns with the picture: a confirmed, deterministically-triggerable denial of the AVRCP Target function (persistent until reboot, no timeout clears it) plus a slow buffer leak from a shallow pool, and a secondary confidentiality concern where a later peer sending REQUEST_CONTINUING_RESPONSE receives the un-sent remainder of the previous peer's response. The primary limiting factors keep real-world risk contained: the pairing/encryption requirement, adjacency, and the need for the device to actually build and use the BR/EDR AVRCP Target role (a feature only introduced in 4.4.0). No signals conflict here; rather, several key risk signals (EPSS, SSVC, KEV, POC) are simply absent, so prioritization rests on the confirmed vendor patch and the 'this_month' label rather than on evidence of active or probable exploitation.

A peer already paired with a Zephyr-based device (e.g. a phone paired to an embedded audio/IoT product) acting as an AVRCP Controller sends a vendor-dependent command whose response spans more than one AVRCP fragment, such as GetElementAttributes or GetCapabilities, lets the Target emit the START fragment, then drops the ACL link instead of sending REQUEST_CONTINUING_RESPONSE. This leaves a buffer stuck on the pending list with TX_ONGOING set; because Target objects are static and reused by connection index, every subsequent connection on that index can never send vendor-dependent responses until reboot, and a new peer can even receive the leaked remainder of the prior peer's response. No public exploit identified at time of analysis; the attack is described by the vendor as deterministically triggerable.