Honestly the original Tarlogic report was so irresponsible that I have to wonder if Espressif is considering legal action.
Note btw that the linked press release points to the more detailed blog post explaining the architecture: https://developer.espressif.com/blog/2025/03/esp32-bluetooth...
As the article says, they worked with Tarlogic to provide a correction. So, probably not.
https://www.tarlogic.com/news/hidden-feature-esp32-chip-infe...
You order 100k chips for your products and while in transit they get compromised by a this party via the said commands
In any case either it is gross incompetence or deliberate malice.
You need arbitrary code execution on the main cpu to execute the debug commands. Once you have that, it's game over anyway. Why not just post the data to a url rather than trying to smuggle it out in Bluetooth headers? Or just broadcast it via normal Bluetooth packets?
There's no issue here.
Tarlogics blog post, it is mentioned “modifying chips arbitrarily”, “infecting chips with malicious code”, “obtain confidential information stored on them”.
Even though they rephrased the backdoor wording, the remaining statements make me believe the undocumented functions can be used to gain code execution on the main cpu.
they're either lying, or failed to disclose details previously.
why do you think they're doing a better job this time around? there may in fact be no serious threat, but now anything and everything is called into question.
The problem is that Tarlogic went full nuclear with "There is a Backdoor in ESP32!!" all over the tech media based on logic that aligns with yours. "They had a feeling."
This is not a backdoor. It is arguably poor security design as one might like it if the BTLE controller was a separate permissions domain. But it isn't, and doesn't have to be, and there isn't even a theoretical vulnerability demonstrated.
probably most news outlets didn't made any research, they just rewrote what the previous outlet published.
as in, "we don't know either, but those guys do!"
so they probably went confident that they weren't wrong with the argument that someone else did the research for them.
i wouldn't dare call them journalists, and it is rather unlikely all of them independently reached the same conclusion that this is a "massive vulnerability".
That means you could attach wires to any device and simply overwrite the firmware on them, replacing it with your own. If that's not a severe security vulnerability, I don't know!
A CCP subsidized chip is massively popular for its low cost in the US.
Ok if you feel this is not a backdoor, but the issue is this is not proof. There will never be proof.
There has long been suspicion. How is it crazy that undisclosed “features” are getting attention?
When it's a special type of command that's only accessible from the host CPU, I have a hard time seeing any way to call it a backdoor. If it were some weird special input to a common command that could hypothetically be handed untrusted input that'd be a different matter, but in this case it's not going to be getting triggered unless the software running on the host CPU is intentionally trying to activate it.
Could these commands be hypothetically used by a malicious actor who had already managed to compromise the code running on the main CPU? Sure. Is there any reason to believe they're put there specifically to allow some kind of exploitability instead of just being debugging commands? Not a bit.
This is a more detailed and informative link than the press release above:
> Espressif will provide a fix that removes access to these HCI debug commands through a software patch for currently supported ESP-IDF versions
> Espressif will document all Vendor-specific HCI commands to ensure transparancy of what functionality is available at the HCI layer
