If that's true, then maybe this is a good thing?
It needs access to the command interface of the chip, which means you need to either have physical access to the device or compromise whatever is physically connected to the device.
It's practically like calling a read/write filesystem a security issue. Yes, an attacker can write to disk and persist there, and they can overwrite files, etc. But there needs to be a flaw that allows access to that behaviour first, else it's just a part of the interface.
And in this instance, it's a part of the debug interface of the chip. And practically makes it a perfect candidate for future bluetooth security tools, similar to the Atheros chipsets used for WiFi sniffing. Now we can do bluetooth impersonation attacks for $2 instead of hundreds.
Betting there'll be some good bluetooth research in the near future, showing all sorts of devices are vulnerable to attacks using $2 hardware. That's the real security problem here.
The undocumented instructions isn't a backdoor at all, it requires you to have local access or have already taken control over the firmware via another bug. The only thing that people going nuts over a "backdoor" will do is cause espressif to close up their interfaces, which would make it harder in the future to repurpose the hardware.
I wonder if this is patchable at all?
Just a bunch of undocumented hardware registers/commands, no remotely accessible backdoor.
This is not a remote exploit. It's arguably not even an exploit or backdoor at all, which is why this PR article is full of "democratized security" slop.