In times of IoT I do not get why they do not offer a version with Bluetooth and WiFi. However a nice product that may be able to push the whole microcontroller hobby space forward.
They don't directly, but Arduino are apparently making an RP2040 board with Bluetooth and WiFi. The accompanying blog post [1] mentions the Arduino Nano RP2040 Connect [2], which includes "a highly efficient power section, a powerful WiFi/Bluetooth module, and the ECC608 crypto chip, enabling anybody to create secure IoT applications with this new microcontroller".
Adding Bluetooth and WiFi would be an order of magnitude more complicated, and not just from a technical point of view - you also have licensing and compliance to deal with. Silly to try and do that on the first version. There's a reason the firs RPis didn't have WiFi.
Bluetooth and Wifi add to cost, size, and power consumption and are actually not needed for many applications, including when a wireless link is needed (for decent range and battery-powered devices there are better options if your device is mostly for remote control/sensing).
So I think it's actually good to strip these out. There can be added as external modules or you can choose a board better suited for the job at hand.
This exploit is about loading your own code to, and reading existing code from, a locked (encrypted) ESP32 - which is pretty bad, as it lets someone with physical access to a device to replace firmware on it, but also if you store the same secret in flash of devices you ship, someone can take one of them and get the secret (potentially compromising them all). A single secret, shipped to users is never a good security architecture, as we have learned multiple times.
However, it's not like this breaks security of your hobbyist projects.
OTOH, the RP2040 doesn't even have flash encryption or secure boot. Which I guess makes sense, given that it looks like a first mass produced MCU designed specifically for education/makers/hackers.
Eh, "grave vulnerabilities" seems like quite the overstatement to me for a lot of ESP32 use cases.
The described exploit requires physical access to the device PCB and precisely timed fault injection, so it requires moderately sophisticated attacker have the device entirely in their control in relative privacy to even perform.
As I see it, the Secure Boot bypass is thus only really relevant to those concerned about a supply chain attacker replacing the firmware. I don't really know how large the overlap is in the venn diagram of those with legitimate concerns about such things and those buying ESP-powered products though as the ones I'm aware of are pretty much all consumer-tier IoT things.
The ability to decrypt encrypted firmware is of course a different matter, even if it doesn't contain any real "secret sauce" most companies don't want their code to be accessible to competitors and/or cloners. See ELM327 for an example of what can happen there. That said I still wouldn't call it a "grave" vulnerability from the perspective of anyone but corporate IP lawyers, and in general screw them.
From a hobbyist perspective these are both good things because they enable hackers to modify their own devices to improve them.
If someone walks to my living room, inside my house, with a laptop and start flashing the ESP32 in there measuring and displaying my house temperatures from BLE sensors - I've got bigger issues than a hacked microcontroller.
[1] https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-n...
[2] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...