BlueZ CVE-2026-75032

Exploitation requires two concrete prerequisites: (1) the attacker must be within Bluetooth radio range of the target system (typically 10-100 meters depending on Bluetooth class), and (2) the victim user must interactively pair with the attacker-controlled malicious Bluetooth device - this is explicit in the description and reflected in UI:R in the CVSS vector. The vulnerability is triggered specifically during processing of GetFolderItems responses in the AVRCP profile, meaning AVRCP must be active (standard on most Linux Bluetooth configurations). Limiting factors include the physical proximity requirement (eliminates remote internet-based exploitation), the mandatory user interaction for pairing (eliminates fully automated or opportunistic attacks without social engineering), and the unauthenticated-but-adjacent attack vector which does not require prior account credentials on the victim system. Systems with Bluetooth disabled or with strict device pairing policies are not exploitable.

The CVSS 3.1 vector AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H (score 6.3) accurately reflects the moderate-to-high real-world risk profile: the adjacent-network vector constrains exploitation to physical Bluetooth proximity, and the required user interaction (device pairing) is a meaningful barrier that eliminates remote mass exploitation. The primary impact is availability - a full daemon crash - with a secondary, lower-confidence confidentiality impact from potential heap memory leakage. No EPSS data was provided in this input, but the physical-proximity and user-interaction requirements make broad automated exploitation unlikely; this is not a fire-drill scenario for most enterprise defenders. The absence of KEV listing and public POC further reduces urgency for non-Bluetooth-centric environments. That said, environments operating shared Bluetooth infrastructure - kiosk systems, medical devices, automotive telematics, or any Linux host whose users regularly pair with untrusted Bluetooth peripherals - face meaningful risk, and even a small IT team managing such endpoints should treat patching as a near-term rather than routine priority.

An attacker brings a Bluetooth-capable device (e.g., a laptop running a custom BlueZ or a modified firmware device) within radio range of a vulnerable Linux host and presents it as an audio device. After socially engineering or waiting for the victim to initiate or accept a Bluetooth pairing, the attacker's device sends a crafted GetFolderItems AVRCP response with manipulated length fields, triggering the out-of-bounds read in parse_media_element() or parse_media_folder(), crashing bluetoothd and potentially exposing heap contents. No public proof-of-concept has been identified at time of analysis, but the attack primitives are well understood in the Bluetooth security research community.