[seba_dos1]

That's why the article is misleading, because what you took away doesn't make any slightest sense.

If a malicious actor can leverage these commands, it means they already have control over your device and can use its Bluetooth radio however they want.

The only security problem that this causes is when your firmware gives someone else ability to use ESP's Bluetooth via HCI over UART without validating their inputs, not expecting it to allow them to take over the device. This is a rather uncommon scenario though - the user of such interface would usually be still you, just from a different chip.

[haswell]

> If a malicious actor can leverage these commands, it means they already have control

Have control, or had control at some point in the device’s lifecycle?

e.g. if an upstream supplier leverages these commands to put the device in a vulnerable state (either intentionally or because of a supply chain compromise) prior to incorporation into some product, is this not still an issue?

[seba_dos1]

"Have control".

These commands let you do what a ROM bootloader does as well. They just do so over an unexpected vector (HCI interface), which could be a problem if you exposed it outside while not exposing the bootloader.

Are you actually trying to come up with a plausible case, or are just guessing without knowing what this "backdoor" is about?

Just for the record, the researches themselves described these command in their talk's abstract in this way:

> The tools will be complemented by the use of undocumented manufacturer commands on ESP32 devices that allow to increase the versatility of these devices when implementing attacks or conducting audits.

Source: https://reg.rootedcon.com/cfp/schedule/talk/5

The same could have been achieved by implementing an open-source replacement for the blob, by the way (just like it's already happening with ESP32's Wi-Fi peripheral: https://esp32-open-mac.be/).