En los últimos días, ha circulado una noticia que ha causado revuelo en la comunidad tecnológica: “¡Se ha descubierto un backdoor en el ESP32!”.
Lo que muchos han entendido es que se ha descubierto un agujero de seguridad enorme a la hora de usar el Bluetooth del ESP32, que permite ejecutar código malicioso, como cambiar bytes de memoria o lanzar comandos.
🚨 ¡Alarmaaaa general! 🚨 ¿Está tu producto en riesgo? ¿Los hackers pueden controlar tus dispositivos inteligentes? ¡O peor! ¿El ESP32 que pusiste a tu tío Manolo para controlarle el riego está comprometido? 😱
Bueno, tranquilidad. Como suele ocurrir en estos casos, la realidad es mucho menos alarmante de lo que los titulares sugieren (ya siento decepcionarte 😆).
Vamos a desglosar qué ha ocurrido realmente despacito, ver por qué no es tan grave como parece y qué lecciones podemos extraer de este episodio.
🧠 ¿Qué es el modo HCI en Bluetooth?
Para entender por qué esto no es un problema de seguridad como algunos han dicho, primero debemos comprender cómo funciona el protocolo Bluetooth (el protocolo es bastante más complicado de lo que solemos creer).
Específicamente, una parte de la especificación es el modo HCI (Host Controller Interface). Es una forma para que un dispositivo que no tiene Bluetooth use otro para tenerlo.
Por ejemplo, un ordenador sin BT, que usa un “pincho” Bluetooth USB.
En este modo HCI, el chip con Bluetooth (el Controller) se comunica con un dispositivo más potente (el Host), como un ordenador o un móvil.
Para que esto funcoine, el chip con BT tiene que ponerse específicamente en modo HCI. Entonces este comunica con el Host, a través de un cable físico 8(UART, USB, etc…).
Para la comunicación, el Host envía comandos al Controller para realizar acciones como escanear dispositivos, conectarse a ellos o actualizar el firmware.
Estos comandos pueden ser:
- Estándar → Definidos por el protocolo Bluetooth.
- Específicos del fabricante → (Vendor-Specific Commands, VSCs), usados para funciones internas como depuración (debugging) o configuración avanzada.
🔎 ¿Qué ha pasado?
Todo empezó con una investigación en la conferencia RootedCon 2025, donde se analizó el firmware del ESP32, específicamente su implementación de Bluetooth.
Los investigadores descubrieron comandos HCI (Host Controller Interface) no documentados que permiten leer y escribir en la memoria del controlador Bluetooth.
👉 Es muy común que los dispositivos tengan comandos no documentados. De hecho, son habituales en otros chips de Bluetooth como los de Broadcom, Cypress y Texas Instruments.
En la presentación de la investigación, se denominó “comandos no documentados”. Peeero, posteriormente en una nota de prensa, se vinieron arriba y lo llamaron “el descubrimiento de un backdoor”.
Y claro, la noticia se viralizó rápidamente, especialmente en medios especializados, y terminó llegando a redes sociales. 🤔 ¿Un exceso? ¿Un poco de clickbait? Puede ser (en mi opinión, sí).
Algo habría cuando, tras la reacción de la comunidad, se rectificó el comunicado. Se volvió a cambiar el término “backdoor” por el original, “funciones no documentadas” (que es una descripción mucho más precisa).
🚫 ¿Por qué NO es un backdoor?
La clave aquí es entender que no se trata de una puerta trasera maliciosa, sino de comandos internos que no están documentados públicamente. Esto es una práctica común en la industria.
👉 Otros fabricantes como Broadcom y Texas Instruments también tienen comandos VSCs no documentados que permiten operaciones similares, como leer y escribir en la memoria del controlador.
Para que estos comandos representen un riesgo real, se deben cumplir varias condiciones:
- 🛡️ El ESP32 debe estar en modo HCI: Esto no es el modo predeterminado en la mayoría de los dispositivos.
-🔌 Debe estar físicamente cableado al Host: No es posible explotar estos comandos de forma inalámbrica (OTA).
- 🔑 El Host debe tener acceso root: Si el Host ya está comprometido, el problema de seguridad es mucho más grave que estos comandos.
En otras palabras, si un atacante pudiera ejecutar estos comandos, ya tenía un control total sobre el sistema (vamos, este es el menor de tus problemas).
Los comandos no documentados no son la causa del problema, sino una herramienta más que podría usar un atacante que ya ha comprometido el sistema, antes un fallo de seguridad anterior.
👉 Pongamos un ejemplo
Para que quede claro, para que se entienda, pongamos como paralelismo (inventado) que se hubiera descubierto un comando de Linux no documentado que al ejecutarlo, te dijera le versión de Linux instalada.
Para ejecutarlo, tienes que tener acceso físico (al teclado de la máquina) y una cuenta de usuario de administrador.
🧑💻 Tu menor roblema es que pueda ejecutar un comando para saber la versión. ¡Ya tenías al tío en casa, sentado en el teclado del ordenador, podía hacer lo que quería!
🤡 ¿Por qué se ha exagerado la noticia?
En primer lugar, hay que dejar muy claro que el término backdoor tiene connotaciones muy negativas, especialmente en el contexto de la seguridad informática.
Sugiere una vulnerabilidad intencional y maliciosa, lo cual no es en absoluto el caso aquí (y deberíamos tener responsabilidad a hacer estas acusaciones).
Ni siquiera si hubiera sido un error garrafal (que no lo es), sería un backdoor. Sería un zero-day exploit o lo que fuera… pero no es un backdoor.
¿Y por qué alguien exagera así una noticia?
- Por desconocimiento.
- Por un malentendido.
- O por una combinación de sensacionalismo mediático y un intento de llamar la atención sobre una investigación que, aunque interesante, no es tan impactante como se hizo parecer.
Además, el hecho de que Espressif sea un fabricante chino pudo haber contribuido a difundir la narrativa de “backdoor”, dado el contexto geopolítico actual y las preocupaciones sobre la seguridad en dispositivos fabricados en China (o por los loles).
No voy a opinar de política. Pero he leído en redes sociales cosas como “no te puedes fiar de los chinos”. Y esto no es un motivo técnico para acusar incorrectamente a una empresa de montar un backdoor en sus productos.
🚀 Lecciones aprendidas
Aunque este caso no representa una amenaza grave, sí nos deja algunas lecciones importantes:
- 📖 La importancia de la documentación: Los fabricantes deberían documentar mejor sus comandos internos, especialmente aquellos que podrían tener implicaciones de seguridad.
- 🎯 La responsabilidad de los investigadores: Es crucial que las investigaciones se comuniquen de manera precisa y sin sensacionalismo.
- 🔒 La seguridad es un proceso continuo: Este caso es un recordatorio de que la seguridad no es un estado, sino un proceso constante.
En resumen, que no hay un backdoor en el ESP32. Lo que se ha descubierto son comandos HCI no documentados que, aunque interesantes desde un punto de vista técnico, no representan una amenaza para la mayoría de los usuarios.
Como comunidad, debemos seguir fomentando la transparencia y el rigor en la investigación de seguridad,… pero también ser críticos con las noticias que consumimos y compartimos.
La seguridad es un tema serio, y abordarlo con responsabilidad es clave para construir un ecosistema tecnológico más seguro y confiable (que bonito me ha quejado 🌈).
👉 Si quieres leer más, te dejo estos artículos: