Xeno Kovah
xenokovah@infosec.exchange
I’ve posted a detailed explanation of why the claimed ESP32 Bluetooth chip “backdoor” is not a backdoor. It’s just a poor security practice, which is found in other Bluetooth chips by vendors like Broadcom, Cypress, and Texas Instruments too. https://darkmentor.com/blog/esp32_non-backdoor/
1
2
1
Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!
lina@vt.social
@xenokovah I don't think your hypothetical "compromised userspace" scenario applies to the ESP32 in any practical usage. These are integrated chips (think "Bluetooth+WiFi+Arduino-on-a-chip") where the the user host code runs on the same chip, I think even in the same address space. So if that is compromised, the Bluetooth side is compromised regardless of the existence of the vendor commands.
In principle you could use an ESP32 as an external Bluetooth controller exposing HCI of course, and then the concern would apply, but I don't know why anyone would do that when dedicated Bluetooth chips designed to be used as HCI dongles exist. And then most of those have the same issues anyway...
4
0
1
Charlotte/Cinny 
charlotte
@lina @xenokovah I have certainly seen this for like arduino-style microcontroller development boards, but really it imo only matters if you want an actual security boundary between the bt chip and the main chip
1
0
1
Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!
lina@vt.social@charlotte @xenokovah Right, but in this case it's all one chip...
You can use an ESP32 as a network controller for another microcontroller, but then you'd usually implement higher level protocols on the ESP32 and provide a higher level interface, not just expose raw HCI, I think. And if you don't, I don't think having a security boundary would be a requirement for most applications...
1
0
1
Charlotte/Cinny
charlotte
@lina @xenokovah ah tbf i haven’t looked at the details on the arduino clone i have that does this, mostly because i’m not particularly interested in bluetooth
0
0
0
The Bluetooth ecosystem is an unmitigated disaster.
1
0
0
Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!
lina@vt.social@lispi314 @xenokovah I don't think "USB device has firmware update or RAM read/write undocumented commands" is a Bluetooth thing... lots of devices do this kind of thing.
Only privileged userspace can issue raw HCI commands anyway (on a proper Bluetooth stack) so it's not like a random unprivileged app can compromise your Bluetooth controller.
1
0
0
Hari Prakash
hariprakashj@fosstodon.org@lina @xenokovah This is a bit weird but consider a scenario where the firmware for esp32 was modified with some new code which uses these undocumented instructions to do something malicious. Would it be hard to detect that? I guess it would be weird to see code that uses some weird undocumented instructions but would be it be obvious that its malicious to someone who is going through the firmware?
1
0
0
Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!
lina@vt.social@hariprakashj @xenokovah "Would this feature be possibly useful as part of a way to hide/obfuscate malicious behavior" is not usually a criteria for labeling something a security issue. There are many ways to hide or obfuscate malicious behavior, especially when you are linking with vendor blobs like this.
There was even a whole contest about this:
https://en.m.wikipedia.org/wiki/Underhanded_C_Contest
Here is an article about how a very, very subtle API misuse in a similar IoT chip due to missing documentation introduced a memory safety issue:
https://tweedegolf.nl/en/blog/145/the-hunt-for-error--22
You could easily just make a similar "mistake" on the ESP32 to create a backdoor, if that was your goal.
0
1
1
Various systems are sufficiently insecure that most apps might as well be considered to have privileges from the get go.
There should be a hardware jumper or other element required to physically setup to enable reprogramming.
1
0
0
Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!
lina@vt.social@lispi314 @xenokovah The only OS and platform that can seriously claim that getting root does not allow full kernel/platform compromise is macOS TBH, which is why Apple (and Xeno) care about this stuff and nobody else does. Every other platform has much bigger issues to worry about once you get root than a compromised Bluetooth controller.
0
0
0
Xeno Kovah
xenokovah@infosec.exchangeShow content
@lina @xenokovah I was addressing the research in the context in which it was given. I’m aware that chips can have varying architectures (attached but non-animated examples from future class), and that a HCI-using architecture is not necessarily the most likely in the case of the ESP32. And indeed given that the research focused on IoT devices in the last few slides, it seems like the least likely place for HCI to matter in some sense. But I didn’t want to muddy the water with speculation, and I have no direct knowledge of population distribution of different architectures in the ESP32-specific ecosystem. So it’s basically “OK, if they want to talk about a vulnerability under the assumption of HCI, let’s talk about it under that assumption”.
1
0
0
Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!
lina@vt.social@xenokovah I think the idea is that ESP32 uses HCI internally within the same chip, between user code and the Bluetooth host controller. So it's still HCI, but in a use case where it doesn't really matter.
1
0
0
Xeno Kovah
xenokovah@infosec.exchange@lina @xenokovah It is indeed possible that they continue to use HCI even in the single chip architecture. However, within Espressif’s response (https://www.espressif.com/en/news/response_esp32_bluetooth) is the statement “If ESP32 is used in a standalone application and not connected to a host chip that runs a BLE host, the aforementioned HCI commands are not exposed and there is no security threat.”. And my interpretation of that is that the ESP32 can also be used in 2-chip architectures in which HCI is the interface, per the Tarlogic researchers’ implied architecture.
1
0
0
Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!
lina@vt.social@xenokovah It's possible to use HCI via firmware API (see `esp_vhci_host_send_packet()`), though there are probably very few applications that do this. Most would use direct and higher level Bluetooth APIs.
At the end of the day, the number of actual devices/applications where the undocumented commands have an actual security impact is probably close to zero...
0
0
0