Security is hard. Just as Espressif Systems announced PSA Level 2 for the ESP32-C6 microcontroller, Spain-based cybersecurity company Tarlogic published their findings about a hidden Bluetooth functionality that can be used as a backdoor in the previous generation ESP32, and gave a presentation in Spanish at Rootedcon 2025.
Specifically, they found hidden proprietary Bluetooth HCI (Host Controller Interface) commands used to read & write controller memory, and typically used for debugging. However, they could also facilitate supply chain attacks, the concealment of backdoors in the chipset, or the execution of more sophisticated attacks. Tarlogic initially called it a “backdoor”, but some disputed the claim (more on that later), and the company eventually issued an update downgrading it to a “hidden” feature:
We would like to clarify that it is more appropriate to refer to the presence of proprietary HCI commands—which allow operations such as reading and modifying memory in the ESP32 controller—as a “hidden feature” rather than a “backdoor.”
The use of these commands could facilitate supply chain attacks, the concealment of backdoors in the chipset, or the execution of more sophisticated attacks. Over the coming weeks, we will publish further technical details on this matter.
According to the researchers, bad actors could potentially infect not only the ESP32 chips themselves, but devices that connect to them through Bluetooth such as smartphones or even medical devices:
Exploitation of this hidden functionality would allow hostile actors to conduct impersonation attacks and permanently infect sensitive devices such as mobile phones, computers, smart locks or medical equipment by bypassing code audit controls.
That looks scary, especially since over one billion ESP32 devices are in the wild. Let’s have a closer look.
Tools used for discovery included a LibUSB-based Bluetooth device driver and Scapy sockets developed by Antonio Vazquez from Tarlogic, and ROM ELF documentation from Espressif. These allowed them to enable raw access to Bluetooth traffic, and after reverse-engineering work, they eventually discovered 29 undocumented HCI commands in the ESP32 Bluetooth firmware. Those commands can be used to read and write RAM and Flash, MAC address spoofing, and LMP/LLCP packet injection.
The ESP32 Bluetooth security vulnerability has its own CVE (CVE-2025-27840) with a medium severity score of 6.8 points. Targlogic says they will provide more technical details later, and still need specific hardware that will allow them to implement advanced attacks.
A post by Xeno Kovah from Dark Mentor LLC provides more insights. First, it rejects the initial “backdoor” assessment:
What the researchers highlight (vendor-specific HCI commands to read & write controller memory) is a common design pattern found in other Bluetooth chips from other vendors as well, such as Broadcom, Cypress, and Texas Instruments. Vendor-specific commands in Bluetooth effectively constitute a “private API”, and a company’s choice to not publicly document their private API does not constitute a “backdoor”.
Backdoor claims aside, they also tried to assess whether this feature constitutes a security vulnerability. The short answer is that it depends. The longer answer explains that it’s not a vulnerability for customers who do not make a distinction between the privileges of the Host and the Controller. However, it would be for a customer who does not want a compromised userspace on the Host to automatically guarantee a compromised Bluetooth Controller firmware. In any case, they consider use of VSCs granting the capability to read and write memory, flash, or registers is a bad security design, but it impacts all Bluetooth vendors.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
> The short answer is that it depends.
No it doesn’t depend on anything. Being a microcontroller without an MMU means that there’s no privilege rings preventing you from accessing the network stack regardless so any level of arbitrary code execution is equivalent to elevated root. As such, whether such instructions exist or not makes no difference to the threat model and the same information can be accessed through calling the firmware’s internal functions by the address.
This whole thing is a nothing burger.
Exactly. When this was posted on multiple subreddits a few days ago, most people just hopped onto the backdoor hype train without reading & thinking about the details. Shame on the Tarlogic “researchers” for posting such sensationalist garbage too.
Proprietary (non-free) blobs should be considered as backdoors by default.
You mean if you connect it to the usb and flash some code or maybe run micropython you can exercise some calls that exercise some Bluetooth test code?
Not exactly what I would call a vulnerability, but hey, I’m not on stage pretending I am an expert. I just develop on them with the esp-idf.
I saw these as well, and I think that:
Thus I’m not worried 🙂
Matter has a ridiculous level of security. You need a 384b Elliptic curve key to talk to it, and once you can talk to it there is a another layer of ACLs (access control lists). Combine that with secure boot and no one is going to hack all of that to get to a light bulb.
Where Matter security breaks down is with vendors who don’t want to deal with all of this and then they code in backdoors. The Matter spec doesn’t prohibit them from doing that.
OK but the weak point is always the same in practice, you shut have to shout close to a window “Alexa open the door”, and that marvelous device which also has the precious private key will happily do it for you.
Alexa is optional with Matter. If you want voice you can pick between Amazon, Google, Apple, Samsung and Home Assistant. Or just not use voice at all.
I meant it as an example of how people often use these devices. You put 384-bit crypto and in the end someone shouts an order near a microphone 🙂
This is not true (rather, no longer true, and has not been the case for years) with Siri. It will not unlock doors without making you authenticate first by unlocking your phone. As in, yelling at someone’s HomePod near a window to unlock the door will NOT do so, unless the HomePod owner unlocks their phone first.
There are no passwords to hack on Matter. You log into a larger device like a phone to generate those 384b keys. So if you want to attack passwords you have to attack the phone.
The 384b keys are used to encrypt the Matter network traffic at a low level. Even if you manage to break into the encrypted network you won’t have Admin privilege, so next you’d need to hack the whole ACL system.
Next version of Matter is going to have cameras.
Official response from Espressif https://www.espressif.com/en/news/Response_ESP32_Bluetooth
Key points:
In first implementations of bluetooth 2.0 stack in bluez linux library, it existed the “bccmd” command to access bluetooth dongle memory, to change firmware and so on. Of course, nobody called that backdoor, what a nonsense.
If you have access to send those commands locally you’re already have the control, it’s not a security risk.