BlueZ EUVD-2026-66133

Bluetooth discovery must be active on the victim device - this is the standard mode required for device pairing and is frequently enabled by default on consumer laptops and IoT hardware. The attacker must be within Bluetooth radio range (approximately 10-100 meters depending on device class); internet-based remote exploitation is not possible given AV:A. No authentication is required per CVSS PR:N, and no victim user interaction beyond having discovery mode on is needed per UI:N. Code execution reliability is further constrained by stack canaries, ASLR, and PIE on hardened Linux distributions; embedded or IoT BlueZ builds lacking these mitigations face materially higher RCE risk than standard desktop or server environments.

The CVSS vector AV:A correctly constrains exploitation to Bluetooth radio range (typically 10-100 meters for Class 1/2 devices), meaningfully narrowing the opportunistic attack surface compared to internet-facing vulnerabilities. AC:L/PR:N/UI:N indicates that once an attacker is in range, no authentication or victim interaction beyond having Bluetooth discovery active is required. The A:H impact aligns with the confirmed DoS vector (bluetoothd crash); C:L and I:L reflect the speculative but plausible code execution primitive, conditioned on successfully bypassing modern stack mitigations. EPSS data was not provided, but the adjacency constraint typically correlates with lower opportunistic exploitation rates than network-exposed CVEs. The absence of a KEV listing and no known public exploit reduce urgency for internet-hardened environments; however, risk is elevated for devices in public or semi-public spaces - laptops, IoT gateways, Bluetooth-enabled embedded Linux systems - where physical proximity cannot be guaranteed and discovery is often left enabled by default.

An attacker positions themselves within Bluetooth radio range of a target Linux system running BlueZ with Bluetooth discovery active. The attacker transmits a crafted EIR packet containing an oversized field value during device inquiry, triggering the stack buffer overflow in bluetoothd. On systems without stack hardening mitigations this may enable arbitrary code execution in the bluetoothd process context; on hardened distributions the most reliable outcome is a service crash causing Denial of Service.