ESP-IDF EUVD-2026-98738

Exploitation requires that the target ESP32-class device uses the BlueDroid host stack with Classic Bluetooth (BR/EDR) enabled - devices built with the alternative NimBLE stack or with Classic Bluetooth disabled are not affected. The attacker must be a BR/EDR peer within Bluetooth radio range (AV:A), and must be able to open an L2CAP channel and send a configuration request carrying option-length fields that exceed the remaining received packet bytes. No authentication is required (PR:N) and no user interaction is needed (UI:N). Limiting factors: the Adjacent radio-range requirement prevents remote/internet-based attacks and generally limits exploitation to one target at a time; the memory disclosure is itself conditional ('under some runtime conditions'), so a successful leak of adjacent stack memory is not guaranteed on every attempt.

This is a genuine but moderate-priority issue, best characterized as a high-confidence CVSS-Medium (6.5) that should NOT be treated as an emergency. The CVSS vector CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N is internally consistent with the description: AV:A (Adjacent) correctly reflects that an attacker must be a BR/EDR peer within Bluetooth radio range rather than a remote network attacker, AC:L reflects that a single malformed L2CAP configuration request triggers the flaw, and PR:N/UI:N reflect unauthenticated exploitation requiring no victim interaction. The impact is scoped to C:H/I:N/A:N (confidentiality only), though the description's own wording - 'under some runtime conditions limited adjacent Bluetooth stack memory can be included' - suggests the real-world disclosure is limited and conditional, arguably closer to C:L than C:H. No EPSS score, KEV listing, or POC was provided in the input: there is no public exploit identified at time of analysis and no evidence of active exploitation. The limiting factors - Adjacent (radio-range) attack vector, confidentiality-only impact, and dependency on Classic Bluetooth being enabled with the BlueDroid host stack - substantially reduce real-world risk compared to a remotely-reachable RCE. SSVC-style reasoning: exploitation = none observed, automatable = no (requires radio proximity to each target), technical impact = partial (limited memory disclosure). Overall: patch on a normal maintenance cadence, prioritizing devices with Classic Bluetooth exposed in physically accessible or adversarial environments.

An attacker within Bluetooth radio range of an ESP32-class device running BlueDroid with Classic Bluetooth (BR/EDR) enabled establishes an L2CAP connection and sends a crafted L2CAP configuration request whose option-length fields exceed the remaining received packet bytes. The unvalidated length triggers an out-of-bounds read in l2c_main.c/l2c_utils.c, and under certain runtime conditions adjacent Bluetooth stack memory is reflected back in the outbound L2CAP Configuration Response, leaking limited internal memory to the attacker. No public exploit was identified in the provided data, and the Adjacent (AV:A) vector means the attacker must be in radio proximity.