There was no "Backdoor" in the ESP32, only undocumented commands were found

gulson 15 Mar 2025 21:07 5 1578 Cool? (+3)

📢 Listen (AI):

TL;DR

Tarlogic’s “ESP32 backdoor” claim centers on undocumented Bluetooth HCI vendor-specific commands in Espressif’s ESP32, not a confirmed implant.
Reverse engineering of the ESP32 ROM found commands for reading and writing RAM, flash, registers, and sending low-level packets from the Controller side.
Tarlogic published the press release on 6 March 2025, and the issue is now tracked as CVE-2025-27840.
Espressif says there is no known real security risk, will patch ESP-IDF access to these debug commands, and will document all vendor-specific HCI commands.
ESP32-C, ESP32-S, and ESP32-H chips are not affected because their Bluetooth controllers do not support these commands.

Generated by the language model.

On 6 March 2025, Tarlogic published a press release entitled 'Tarlogic detects backdoor in mass-produced ESP32 chip that could infect millions of IoT devices'. This information was later picked up by the BleepingComputer website and circulated via Slashdot, Google News. In short, 'researchers' announced a week ago that they had detected a backdoor in ESP32 from Chinese manufacturer Espressif, published an article which first had a title suggesting a security vulnerability. Quite quickly, the manufacturer issued a statement and then documented in detail . It turned out that the so-called 'back door' was simply.... undocumented API. This is in fact a common design pattern also found in Bluetooth chips from other manufacturers such as Broadcom, Cypress and Texas Instruments. Manufacturer-specific commands in Bluetooth are in fact a 'private API', and a company's decision not to document this API does not constitute a 'backdoor'. The researchers' article quickly changed its title to 'Undocumented commands'

.

Bluetooth has an architectural layer known as the Host Controller Interface (HCI). In architectures such as laptops and phones, the main processor and operating system is the "Host" and the Bluetooth chip is the "Controller". HCI is the interface between the Host and the Controller. When the Host wants to search for nearby available BT devices or connect to one of them, it sends a Command through the HCI to the Controller.
The Bluetooth Core specification defines a number of HCI commands, but also reserves a command space for 'Manufacturer Specific Commands' (VSC). These are commands that the manufacturer can use to manage the Controller. They can include such things as updating the Controller software, obtaining useful information (e.g. chip temperature), performing chip-specific actions (e.g. setting transmission power), etc. VSCs are typically used by manufacturers through their proprietary software.

What does the study describe?
The study describes the reverse engineering of the ESP32 ROM, using a copy that Espressif makes available on GitHub. The researchers analyse the VSC and find instances of reading and writing RAM and flash, as well as sending certain types of low-level packets that cannot normally be sent from the Host.
Importantly, the research slides themselves do not claim that this is a backdoor. Only the press release suggests this. The slides merely indicate that there are hidden/undocumented commands.

Espressif has partially documented its VSC, as have other Bluetooth chip manufacturers, and has included the ability to read and write the chip's memory, as have other Bluetooth chip manufacturers.
The author concludes that Tarlogic's press release spreads fear, uncertainty and doubt (FUD) in order to attract attention. And the BleepingComputer article and its messages on platforms such as Slashdot, focusing on the fact that Espressif is a Chinese supplier.

Is this feature a security vulnerability?
It depends.
In general, the author considers the use of VSCs that give the ability to read and write memory, flash or registers to be a bad security design. It is a bad design for Espressif, just as it is for Broadcom, Texas Instruments and any other vendor that uses it.
This issue is now tracked as CVE-2025-27840 .

Espressif itself states that there is no real, known security risk that these undocumented commands could pose. Despite this, Espressif has decided to take the following action:
- Espressif will provide a patch that removes access to these HCI debug commands through a software update for currently supported versions of ESP-IDF.
- Espressif will document all vendor-specific HCI commands to provide transparency of the functionality available at the HCI layer.

The ESP32-C, ESP32-S and ESP32-H series chips are not affected as their Bluetooth controllers do not support these commands.

What do hack news users think about this?
https://news.ycombinator.com/item?id=43330331
1. users express satisfaction that Espressif has chosen to be more transparent, rather than further restricting access to features.
2. Although the company initially gained popularity in the DIY community, their chips are now present in billions of edge devices and professional products.
3. ESP chips gained popularity during the pandemic when they were the only Wi-Fi/BT modules available in a market suffering from a semiconductor shortage.
4) Some users express concern that removing access to debug commands will hinder researchers and those interested in experimenting with these features.
5) Many commenters emphasise that it was exaggerated and irresponsible to present this issue as a 'back door'.
6 The general opinion is that this is not a real security issue, as an attacker would already have to have full access to the device to exploit these commands.
7. users recommend disabling Bluetooth on devices when it is not needed, which is in line with some CE regulations.
8. some believe that these undocumented features are standard industry practice and not a deliberate security threat.

The following was used to write the article:
https://darkmentor.com/blog/esp32_non-backdoor/
https://developer.espressif.com/blog/2025/03/esp32-bluetooth-clearing-the-air/
official release:
https://www.espressif.com/en/news/Response_ESP32_Bluetooth

I don't know about you, but I am impressed by Espressif's explanation and handling of the matter, they have gained more trust with me.
.

Comments summarised using Claude 3.7

About Author

gulson wrote 29221 posts with rating 5977 , helped 148 times. Live in city Kielce. Been with us since 2001 year.

Comments

Add a comment

modziul 15 Mar 2025 23:34

Apparently manufacturers were obliged years ago to leave loopholes for the so-called only right ones because they supposedly represent the law and are supposedly so swamped with data that they don't have... [Read more]

gulson 16 Mar 2025 00:02

The ESP8266 or ESP32 has already been so ploughed through in all sorts of ways by users, researchers, hobbyists, engineers that it seems improbable that a deliberate vulnerability exists. For some, however,... [Read more]

Macosmail 16 Mar 2025 10:03

This is part of the trade war. One can expect many such accusations in the future. Unfortunately, the accusation is carried and loud in the media, but the correction already passes unnoticed. And a false... [Read more]

krzbor 16 Mar 2025 19:26

. I would not be surprised if the moves were forced by the US. If China attacked Taiwan the entire West would be deprived of the ability to mass produce chips at the smallest scales. The current dependence... [Read more]

Anonymous 16 Mar 2025 20:16

Unfortunately, the bleepingcomputer website continues to show the nonsense information regarding ESP32 that. " The undocumented commands allow spoofing of trusted devices, unauthorised data access, pivoting... [Read more]

FAQ

TL;DR: Published on 6 March 2025, the claim that ESP32 had a Bluetooth “backdoor” was later reframed as undocumented vendor commands. This FAQ helps ESP32 developers, IoT teams, and security readers separate real design risk from media overstatement and understand what Espressif said it will patch in ESP-IDF. [#21481343]

Why it matters: The thread argues that misleading security headlines can distort risk decisions for billions of deployed edge devices.

Claim or situation	Thread’s description	Practical meaning
“Backdoor” headline	Press release language	Suggests intentional hidden access
Research slides	Undocumented commands in ROM/HCI	Points to hidden functionality, not deliberate covert access
Espressif response	Debug access to be removed in ESP-IDF	Treat as hardening and transparency work
ESP32-C / ESP32-S / ESP32-H	Not affected	Their Bluetooth controllers do not support these commands

Key insight: The core finding was undocumented Bluetooth vendor-specific functionality, not proof of a secret remote implant path. The thread treats it as poor security design and weak messaging, not evidence of an intentional Espressif backdoor.

Quick Facts

The thread centers on a 6 March 2025 press release, followed by Espressif’s response and a more detailed clarification published about 1 week later in the discussion timeline. [#21481343]
The commands were discussed at the Bluetooth HCI layer, where a host processor sends commands to a Bluetooth controller; the thread says this architecture is standard in laptops and phones. [#21481343]
The research reportedly found ROM-level commands for reading and writing RAM and flash, plus sending low-level packets that normal host software cannot usually send. [#21481343]
The issue is tracked as CVE-2025-27840, but the thread stresses that an attacker would already need very high device access to use these commands in practice. [#21481343]
ESP32-C, ESP32-S, and ESP32-H are stated as not affected because their Bluetooth controllers do not support the undocumented commands discussed. [#21481343]

What exactly was found in the ESP32 Bluetooth controller, and why is Espressif saying it was not a backdoor?

Researchers found undocumented Bluetooth vendor-specific commands in the ESP32 controller ROM, not evidence of a secret remote backdoor. The thread says the commands include memory read and write functions and low-level packet features, but notes that manufacturer-specific HCI commands are common private APIs in Bluetooth chips. Espressif’s position, as summarized here, is that hidden documentation does not equal hidden attacker access. [#21481343]

How do undocumented HCI vendor-specific commands work in ESP32, and what are they normally used for?

They work as manufacturer-defined commands sent over the Bluetooth Host Controller Interface to manage controller-only functions. The thread says such commands can update controller software, read chip information such as temperature, change transmit power, or expose debug-style memory access. In normal use, vendors access them through proprietary tools rather than public end-user APIs. [#21481343]

What is the Bluetooth Host Controller Interface (HCI) in ESP32 and other Bluetooth chips?

“Host Controller Interface” is a Bluetooth control layer that links the main processor to the radio controller, separating operating-system logic from low-level wireless execution. In the thread’s example, a laptop or phone host sends HCI commands when it scans for nearby devices or starts a connection, and the controller executes them. [#21481343]

What are vendor-specific commands (VSC) in Bluetooth, and why do chip makers like Espressif, Broadcom, Cypress, and Texas Instruments use them?

“Vendor-specific commands” are Bluetooth HCI commands that sit in a manufacturer-reserved space and expose chip-specific management features beyond the core Bluetooth specification. The thread says vendors use them for tasks like software updates, telemetry, temperature reads, power tuning, and other controller controls that standard HCI commands do not cover. [#21481343]

Why did Tarlogic's ESP32 press release get criticized as FUD, and what did the research slides actually claim?

It was criticized because the press release used the word “backdoor,” while the thread says the research slides only showed hidden or undocumented commands. The same post argues that the stronger wording created fear, uncertainty, and doubt, especially after amplification by security media and aggregators. The criticism targets the messaging, not the fact that reverse engineering uncovered undocumented behavior. [#21481343]

How serious is CVE-2025-27840 for real ESP32 devices in practice?

The thread treats CVE-2025-27840 as a real hardening issue but not a major practical remote threat. Its key claim is that an attacker would already need full or near-full device access before these Bluetooth debug commands become useful, which sharply limits real-world exploitation on deployed products. That makes it more serious for device trust boundaries than for mass remote takeover. [#21481343]

Which ESP32 families are affected by the undocumented Bluetooth commands, and why are ESP32-C, ESP32-S, and ESP32-H not affected?

The thread says some ESP32 devices are affected, but ESP32-C, ESP32-S, and ESP32-H are not. The stated reason is specific: their Bluetooth controllers do not support the undocumented commands discussed in the report. That narrows the scope to older or different controller implementations rather than the full ESP product line. [#21481343]

What software update is Espressif planning for ESP-IDF to remove access to the ESP32 HCI debug commands?

Espressif is described as planning an ESP-IDF software patch that removes access to the HCI debug commands on currently supported versions. The same summary says the company also plans to document all vendor-specific HCI commands for transparency. So the response has two parts: reduce debug exposure and improve public documentation. [#21481343]

How can a researcher reverse engineer the ESP32 ROM and inspect undocumented Bluetooth commands using the ROM copy on GitHub?

The thread describes a simple 3-step path. 1. Obtain the ESP32 ROM copy that Espressif makes available on GitHub. 2. Reverse engineer the ROM to identify vendor-specific HCI handlers. 3. Trace functions related to RAM, flash, and low-level packet operations. That process is how the discussed research reportedly identified undocumented Bluetooth commands. [#21481343]

Why do some engineers argue that memory read/write debug commands are bad security design even when they are not a hidden backdoor?

They argue that memory and flash read/write commands weaken system trust even without proving malicious intent. The thread explicitly says this is bad security design for Espressif and also bad design for other vendors that expose similar capabilities. The failure case is clear: once a high-privilege path reaches those commands, sensitive data or firmware state becomes easier to inspect or alter. [#21481343]

How does the ESP32 undocumented-command issue compare with similar private Bluetooth APIs in Broadcom, Cypress, and Texas Instruments chips?

The thread says it is comparable because private Bluetooth controller APIs are an industry pattern, not an ESP32-only anomaly. It specifically names Broadcom, Cypress, and Texas Instruments as vendors that also use partially documented or proprietary command paths for controller management. That comparison weakens the claim that undocumented commands alone prove a special backdoor. [#21481343]

What practical attack path would an attacker need to exploit ESP32 Bluetooth debug commands, and why do some commenters say this is not a major remote risk?

A practical attacker would first need extensive control over the target device, then use that foothold to access the Bluetooth controller commands. The thread’s summary of discussion says many commenters do not see this as a major remote risk because the commands are not a turnkey over-the-air exploit by themselves. In short, device compromise comes first; these commands mostly deepen access after that. [#21481343]

How should developers reduce Bluetooth-related risk on ESP32-based IoT devices when Bluetooth is not needed?

Disable Bluetooth when the product does not need it. The thread says users explicitly recommended turning Bluetooth off when unused, and adds that this aligns with some CE-related guidance mentioned in the discussion. That is the cleanest reduction step because it removes exposure at the radio and controller level instead of only relying on later filtering. [#21481343]

Why do media reports about ESP32 and Chinese hardware security claims spread faster than later corrections from Espressif?

The thread says dramatic accusations travel faster because headlines about a Chinese “backdoor” attract more clicks than later technical corrections. One commenter summarizes the pattern bluntly: “the accusation is carried and loud in the media, but the correction already passes unnoticed.” That dynamic leaves a false public image even after the wording changes. [#21481748]

What is a CVE, and how does a finding like CVE-2025-27840 get tracked and evaluated for embedded chips such as the ESP32?

A CVE is a public identifier used to track a reported security issue so vendors and users can discuss one finding consistently. In this thread, the undocumented-command issue is tracked as CVE-2025-27840, which lets the design concern be referenced even while people disagree on severity and exploitability. For embedded chips, that tracking separates naming the issue from proving practical risk. [#21481343]

Generated by the language model.