Espressif has 35 documented security and bug advisories since 2020, ranging from genuine security flaws to end-of-life announcements. Yet their newest entry, a plain new CVE-2025-27840 out of Spain regarding an ESP32 chip, stands out not for its discovery but for its alarmist classification.

To be clear, this is just the latest security advisory in Espressif’s catalog, following a dozen in 2024 and fun ones like “Bypassing Secure Boot and Flash Encryption using CPA and FI attack” (AR2023-007) and “Security Advisory for WLAN FragAttacks” (AR2023-008).

That’s why, looking at the ESP32, I say we shouldn’t be surprised if a kid driving an industrial harvester has found something to chew on in the exact same field that for the last five years has produced a whole lot of delicious potatoes.

When researchers Miguel Tarascó Acuña and Antonio Vázquez Blanco announced their findings at RootedCON in Madrid, they used the term “backdoor” for an ESP32 Bluetooth implementation.

However, where the prior litany of vulnerability reports represented actual attack vectors with demonstrable exploitation paths, their claim comes up short by comparison. It deserves a rebuff through some rational technical dissection that uses a baseline to verify backdoor claims.

Examining their actual discovery reveals something rather mundane in the security vulnerability hierarchy: undocumented vendor commands residing precisely where the Bluetooth specification expects vendor commands to exist—in OGF (Opcode Group Field) 0x3F.

We should be fair to prior researchers, not to mention Espressif’s track record of proper vulnerability disclosure. Applying a consistent technical rigor of research to the new CVE greatly waters down claims being made. It simply doesn’t hold a candle to actual hairy security like a June 2021 (AR2021-002) flash encryption flaw.

Flash 中的分区表本身也经过加密，但攻击者⼀一旦具备对设备的物理理访问权限，则有可能
篡改经过加密的分区表，并清除⼀一些分区的 “加密” 标记。这样⼀一来，设备在下次启动时将
视这些分区为明⽂文数据来处理理

Be honest now, are you scared more because I said encryption flaw, or because you’re seeing Chinese?

An undocumented command set of course could sound very, very scary to an untrained ear, to those who don’t read command sets and thus can’t understand what’s going on. So let’s dive in deep to apply some banal vulnerability taxonomy and see what commands actually were discovered versus what was waved on the plains of Spain like a big red cape to work up some bulls….

I guess we can call this doing research on the research, or even some peer review if you must, given disclosure of vendor-specific HCI (Host Controller Interface) commands. I will try here to make a significant technical distinction, with important security implications, to explain why a backdoor doesn’t seem to exist.

The researchers cleverly reverse-engineered the ESP32 firmware by analyzing multiple binary libraries provided by Espressif:

`libbtdm_app.a`
`libbttestmode.a`
`libphy.a`
`librftest.a`
`librtc.a`


Through static analysis with the NSA’s Ghidra (VROOM VROOM, push the big GO button), they discovered the ESP32 contains tables of HCI commands, with the last entry referencing OGF 0x3F—a range reserved for proprietary vendor commands.

This revealed 29 undocumented commands for low-level functionality.

Now for some bad news. A backdoor, by definition, implies some specific stuff. Any of this would help:

1. Intentional implementation for unauthorized access
2. Remote exploitability without prior access
3. Bypass of authentication mechanisms

The discovered ESP32 functionality however fails all three criteria:

Implementation Intent

I see proprietary debugging/manufacturing commands. The commands exist in the OGF 0x3F range explicitly designated for vendor-specific functionality in the Bluetooth specification. This is standard practice in hardware and software, across chipsets.

Access Vector

Exploitation requires sending HCI commands to the ESP32, which necessitates either having physical access to the device’s USB/UART interfaces, or a prior compromise allowing direct communication with the Bluetooth controller. Root access is needed to send arbitrary HCI commands.

Command Architecture

The commands use standard HCI protocol structure and are processed through the normal command handler. They aren’t hidden “backdoor” channels but rather undocumented extensions of the standard interface.

As you can see any claims of a backdoor stretch the definition beyond recognition. This is a case of documenting something missing a manual. Look at their discovered commands, which include:

0xFC01 - Read memory
0xFC02 - Write memory
0xFC32 - Set MAC address
0xFC0E - Send LMP packet
0xFC43 - Send LLCP packet


These are typical vendor testing/debugging functions found in most Bluetooth controllers. The commands are processed through usual RivieraWaves/CevaWaves RTOS command handlers—the proprietary Bluetooth stack used by ESP32.

With all the usual stuff in mind the actual security impact is limited to scenarios where an attacker has already achieved privileged access. In other words, calling this a backdoor is like entering a house somehow (front door, back door, window, whatever) and then saying “hey everyone I found a hidden closet in this bedroom, not on the floorplan”. Kinda significant difference from a backdoor event.

It’s still a hidden thing, on a proprietary chip, so let’s not forget some scenarios could manifest and maybe even matter to someone thinking broadly about risks.

OEMs, or someone intercepting chips, implementing an ESP32 could theoretically exploit these commands, but of course they already have physical access to modify firmware.

After gaining root access to a device with an ESP32, an attacker could use these commands to hide code in the controller—but again this requires some prior system wide compromise. Can’t use a hidden closet until after you get in the house somehow.

Physical access to debugging interfaces could allow firmware manipulation, just like virtually any embedded device. Nothing new here.

I guess what I’m saying is that it is fantastic to see someone put together undocumented functionality by applying “right to repair” principles. But it’s silly for them to call documentation of any of these functions a backdoor.

The security community should hold the line and classify it as CWE-912 (Hidden Functionality) rather than CWE-506 (Embedded Malicious Code).

While Espressif could document these commands for transparency (unless they want to give researchers something to busy themselves with), they seem to follow industry norms for proprietary extensions to a Bluetooth specification. It’s called proprietary for a reason.

The research is valuable to show Bluetooth security testing works, but the “backdoor” characterization is technically inaccurate and obviously selfish and misleading.