I know tech reporting has gone downhill, but I was really surprised by how badly this minor issue was overhyped.. articles with titles like "Hidden Backdoor Discovery Could Expose 1 Billion Bluetooth Devices To Hackers" coming out even yesterday. It's a stretch to even call this a back door.
<a href="https://developer.espressif.com/blog/2025/03/esp32-bluetooth-clearing-the-air/" rel="nofollow">https://developer.espressif.com/blog/2025/03/esp32-bluetooth...</a><p>This is a more detailed and informative link than the press release above:<p>> <i>Espressif will provide a fix that removes access to these HCI debug commands through a software patch for currently supported ESP-IDF versions</i><p>> <i>Espressif will document all Vendor-specific HCI commands to ensure transparancy of what functionality is available at the HCI layer</i>
That's about the right response. These don't expose a command across a security boundary. You can only exercise them if you're already executing arbitary code on the main CPU core.<p>Honestly the original Tarlogic report was so irresponsible that I have to wonder if Espressif is considering legal action.<p>Note btw that the linked press release points to the more detailed blog post explaining the architecture: <a href="https://developer.espressif.com/blog/2025/03/esp32-bluetooth-clearing-the-air/" rel="nofollow">https://developer.espressif.com/blog/2025/03/esp32-bluetooth...</a>
It it possible to create firmware that is encrypted and cannot be read out. Espressif state there is no security issues, but I have a feeling that these debug commands may be used to read out the flash of a properly secured esp32 that otherwise would not be possible…
This is more concise and clearer. Their first one mocked them being called undocumented, putting it in quotes, when they were in fact undocumented. The main point is that if malicious software has access to these commands, it has access to the rest of the system already so this is the least of your problems (if I understand this correctly).