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:

1. Establishing a Bluetooth connection with the target ESP32 device
2. Sending a malformed AVRCP VENDOR DEPENDENT command with an undersized or crafted length field
3. The device's Bluetooth stack processes the command without proper bounds checking
4. 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:

• Patch for ESP-IDF commit 075ed21
• Patch for ESP-IDF commit 2f788e5
• Patch for ESP-IDF commit 7980291
• Patch for ESP-IDF commit 999710f
• Patch for ESP-IDF commit d5db5f6
• Patch for ESP-IDF commit daeeba2

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

# 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