Espressif ESP-IDF CVE-2025-68474

Exploitation requires the target ESP-IDF device to use the BlueDroid Bluetooth Classic stack with the AVRCP profile active, and to process/construct a vendor-dependent AVRCP command (avrc_vendor_msg) with a vendor_len approaching the buffer limit. The attacker must be within Bluetooth (adjacent) range, and the CVSS AT:P reflects the specific condition that vendor_len must be large enough to exceed the 29-byte real header footprint. Limiting factors: impact is bounded to adjacent radio proximity (not internet-remote), requires AVRCP to be enabled/in use (not all ESP32 firmware uses Bluetooth or AVRCP), and the severity is worst on builds with assertions disabled; devices with no Bluetooth or without the AVRCP profile are not affected.

This is a moderate-severity memory-corruption flaw (CWE-787 out-of-bounds write) in the BlueDroid AVRCP stack of ESP-IDF, rated CVSS 4.0 6.1 by the GitHub advisory (AV:A/AC:L/AT:P/PR:N/UI:N, impacts VC:L/VI:L/VA:H). The vendor-supplied vector indicates an adjacent (Bluetooth-range) attack with no privileges or user interaction, but AT:P signals a non-default attack requirement - consistent with the root cause: avrc_vendor_msg() validated allocations against AVRC_MIN_CMD_LEN (20 bytes) when 29 bytes of fixed header are actually written before the vendor payload, so a large vendor_len can overflow the buffer. No EPSS score, KEV listing, or POC was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the realistic risk is primarily availability/crash (VA:H) rather than confirmed code execution, which the advisory conservatively scores as only low confidentiality/integrity impact. The signals are internally consistent (no KEV-vs-EPSS conflict), but one caveat: avrc_vendor_msg() constructs an outgoing AVRCP command and vendor_len is set by the calling code/application, so whether an over-the-air adjacent attacker can directly control vendor_len depends on the device's AVRCP usage - the AV:A rating should be verified against the actual call path for a given product. Note the description states the overflow can be larger when assertions are disabled (typical of production/NDEBUG builds), which raises real-world impact versus debug builds.

An attacker within Bluetooth range of an ESP32-based device that uses the BlueDroid AVRCP profile triggers construction of a vendor-dependent AVRCP command with a vendor_len close to the buffer limit; because allocation was sized using the 20-byte AVRC_MIN_CMD_LEN while 29 bytes of header are written first, the vendor-data copy writes past the allocated buffer. This corrupts adjacent heap memory, most reliably causing a crash/denial of service, with the overflow larger on production builds where assertions are disabled. No public proof-of-concept was provided in the intelligence sources.