Imagine the ESP32 is being used as a wifi/bluetooth "modem" via a serial link to a host system (rather than the ESP32 used as a standalone SOC.)
In theory, the attacker could then use the undocumented commands to scan, spoof, or otherwise attack any near by bluetooth devices. Perhaps this could even be achieved without gaining root on the device which is hosting the esp32.
If you find a device that does it in the wild, then I guess you now gained a nice jailbreaking vector - that is, if it needed jailbreaking at all. Otherwise, it's nothing.
This possibility should be obvious to any software developer that knows how modern IO peripheral stacks are constructed. There is little that can be done to defend against a poorly written OS driver that exposes functions like this, even unintentionally, and it is naive to assume that any class of device will lack them unless clearly documented otherwise. This has been of particular concern to developers of open source Linux kernel drivers for decades at this point.
How's this any different than a laptop getting pwned and attackers being able to run aircrack-ng or whatever on it?
Maybe an issue here is WebSerial, as HCI comes over a serial port device. I believe the OS should block access to the serial device once the host driver takes it as a Bluetooth adapter though.
IIRC, that restriction was removed.
It's an IOT device. Everything's running as root.
It's undocumented.
So? Device is 0wned. Did you think Bluetooth chip is magic protection device for rest of the network?
How would you stop physical external actor? Do you have "No ESP32 permitted on this property" signs on windows?