CVE-2025-66409: Espressif ESP-IDF Information Disclosure

CVE-2025-66409 Overview

CVE-2025-66409 is an out-of-bounds read vulnerability in Espressif's ESP-IDF (Internet of Things Development Framework) affecting the Bluetooth stack. When AVRCP (Audio/Video Remote Control Profile) is enabled on ESP32 devices, receiving a malformed VENDOR DEPENDENT command from a peer device can cause the Bluetooth stack to access memory before validating the command buffer length. This may lead to an out-of-bounds read, potentially exposing unintended memory content or causing unexpected behavior on affected IoT devices.

Critical Impact
Attackers within Bluetooth range can send crafted AVRCP commands to trigger memory disclosure or cause device instability on ESP32-based IoT devices.

Affected Products

Espressif ESP-IDF version 5.5.1 and earlier
Espressif ESP-IDF version 5.4.3 and earlier
Espressif ESP-IDF version 5.3.4 and earlier
Espressif ESP-IDF version 5.2.6 and earlier
Espressif ESP-IDF version 5.1.6 and earlier

Discovery Timeline

December 2, 2025 - CVE-2025-66409 published to NVD
February 13, 2026 - Last updated in NVD database

Technical Details for CVE-2025-66409

Vulnerability Analysis

This vulnerability exists in the Bluedroid Bluetooth stack implementation within ESP-IDF, specifically in the AVRCP message handling code. The affected functions fail to properly validate the length of incoming VENDOR DEPENDENT command buffers before accessing their contents. When processing AVRCP commands, the code directly accesses memory offsets within the vendor data buffer without first confirming that the buffer contains sufficient data. This allows a malicious Bluetooth peer to craft packets with truncated or malformed length fields, causing the ESP32 device to read memory beyond the allocated buffer boundaries.

The vulnerability is classified as CWE-125 (Out-of-Bounds Read), which typically results in information disclosure or application crashes rather than arbitrary code execution. In the context of embedded IoT devices, this could expose sensitive data stored in adjacent memory regions or cause denial of service conditions.

Root Cause

The root cause lies in insufficient input validation within the AVRCP command processing functions in bta_av_act.c and avrc_api.c. The original code would immediately set a pointer to access p_vendor->p_vendor_data + 2 without first checking if p_vendor is valid, if p_vendor_data is non-null, or if vendor_len contains the expected number of bytes. Similarly, in the avrc_msg_cback function, the code would access packet data without verifying that p_pkt->len meets the minimum required header size (AVRC_AVC_HDR_SIZE).

Attack Vector

An attacker within Bluetooth range of a vulnerable ESP32 device can exploit this vulnerability by:

Establishing a Bluetooth connection with the target ESP32 device
Sending a malformed AVRCP VENDOR DEPENDENT command with an undersized or crafted length field
The device's Bluetooth stack processes the command without proper bounds checking
Memory adjacent to the command buffer is read, potentially disclosing sensitive information or causing unexpected behavior

The attack requires Bluetooth proximity but no authentication, making it exploitable by any nearby attacker.

// Security patch in components/bt/host/bluedroid/bta/av/bta_av_act.c
// Source: https://github.com/espressif/esp-idf/commit/075ed218cadb8088155521cd8a795d8a626519fb

 {
     tAVRC_STS   status = BTA_AV_STS_NO_RSP;
     UINT16      u16;
-    UINT8       *p = p_vendor->p_vendor_data + 2;
+    UINT8       *p = NULL;
+
+    if (!p_vendor || !p_vendor->p_vendor_data ||
+        (p_vendor->vendor_len != AVRC_REGISTER_NOTIFICATION_CMD_SIZE)) {
+        return AVRC_STS_INTERNAL_ERR;
+    }
+
+    p = p_vendor->p_vendor_data + AVRC_CMD_PARAM_LENGTH_OFFSET;

     BE_STREAM_TO_UINT16 (u16, p);
     /* double check the fixed length */
-    if ((u16 != 5) || (p_vendor->vendor_len != 9)) {
+    if (u16 != 5) {
         status = AVRC_STS_INTERNAL_ERR;
     } else {
         /* make sure the event_id is valid */

// Security patch in components/bt/host/bluedroid/stack/avrc/avrc_api.c
// Source: https://github.com/espressif/esp-idf/commit/075ed218cadb8088155521cd8a795d8a626519fb

     p_data  = (UINT8 *)(p_pkt + 1) + p_pkt->offset;
     memset(&msg, 0, sizeof(tAVRC_MSG) );
-    {
+
+    if (p_pkt->layer_specific == AVCT_DATA_BROWSE) {
+        // opcode = AVRC_OP_BROWSE;
+        // msg.browse.hdr.ctype = cr;
+        // msg.browse.p_browse_data = p_data;
+        // msg.browse.browse_len = p_pkt->len;
+        // msg.browse.p_browse_pkt = p_pkt;
+        AVRC_TRACE_ERROR("BROWSE CHANNEL NOT SUPPORTED NOW!");
+        osi_free(p_pkt);
+        return;
+    } else {
+        if (p_pkt->len < AVRC_AVC_HDR_SIZE) {
+            AVRC_TRACE_WARNING("Bad message length:%d (< %d)", p_pkt->len, AVRC_AVC_HDR_SIZE);
+            osi_free(p_pkt);
+            return;
+        }
         msg.hdr.ctype           = p_data[0] & AVRC_CTYPE_MASK;
         AVRC_TRACE_DEBUG("avrc_msg_cback handle:%d, ctype:%d, offset:%d, len: %d",
                          handle, msg.hdr.ctype, p_pkt->offset, p_pkt->len);

Detection Methods for CVE-2025-66409

Indicators of Compromise

Unexpected device reboots or Bluetooth stack crashes on ESP32 devices
Anomalous Bluetooth connection attempts followed by malformed AVRCP command sequences
Memory fault errors or exception logs in ESP32 device firmware logs
Unusual Bluetooth peer devices attempting connections with AVRCP-enabled ESP32 endpoints

Detection Strategies

Monitor Bluetooth stack logs for warning messages containing "Bad message length" or similar buffer validation failures
Implement Bluetooth traffic analysis at the network perimeter to detect malformed AVRCP VENDOR DEPENDENT commands
Deploy firmware integrity monitoring on ESP32 devices to detect unexpected crashes or restarts
Review ESP-IDF version inventory to identify devices running vulnerable firmware versions

Monitoring Recommendations

Enable verbose logging on ESP32 Bluetooth stack to capture AVRCP command processing events
Implement centralized log aggregation for IoT device fleets to correlate potential attack patterns
Monitor for repeated Bluetooth pairing attempts from unknown devices
Set up alerting for ESP32 device crashes or watchdog timer resets

How to Mitigate CVE-2025-66409

Immediate Actions Required

Update ESP-IDF to a patched version containing the security fixes for your branch
Audit all deployed ESP32 devices to identify those with AVRCP functionality enabled
Consider disabling AVRCP functionality temporarily if updates cannot be immediately deployed
Restrict physical access to areas where ESP32 devices are deployed to limit Bluetooth attack surface

Patch Information

Espressif has released security patches across multiple ESP-IDF branches. The fixes add proper null pointer checks, validate vendor_len against expected command sizes (AVRC_REGISTER_NOTIFICATION_CMD_SIZE), and verify minimum packet lengths before processing AVRCP messages. Apply the appropriate patch for your ESP-IDF version:

For full details, see the Espressif Security Advisory GHSA-qhf9-vr2h-jh96.

Workarounds

Disable AVRCP functionality in ESP-IDF configuration if not required for device operation
Implement network segmentation to isolate Bluetooth-enabled IoT devices from critical infrastructure
Deploy physical security controls to limit Bluetooth access range to trusted areas only
Monitor device behavior and implement automated restart procedures if crashes are detected

bash

# Configuration example - Disable AVRCP in ESP-IDF sdkconfig
# Add to your project's sdkconfig or use menuconfig
CONFIG_BT_A2DP_ENABLE=n
CONFIG_BT_AVRCP_ENABLE=n

# Alternatively, use idf.py menuconfig:
# Component config → Bluetooth → Bluedroid Options → Classic Bluetooth → A2DP → Disable