A partir del 1 de enero de 2026, todos los vehículos que circulen por las carreteras españolas estarán obligados a sustituir los triángulos de emergencia por balizas luminosas V16 conectadas a la plataforma DGT 3.0. Estas señales, equipadas con geolocalización y conectividad IoT, se venden como un avance decisivo en seguridad vial: permiten avisar en segundos a otros conductores y a los centros de control de tráfico sin que el afectado tenga que salir del vehículo.
Sin embargo, una investigación publicada el 5 de diciembre de 2025 por el investigador independiente Luis Miranda Acebedo ha encendido todas las alarmas. El análisis técnico de la baliza Help Flash IoT —uno de los modelos más conocidos del mercado, comercializado junto a Vodafone y homologado por la DGT— describe una cadena de vulnerabilidades que, según el propio autor, puede convertir un dispositivo pensado para salvar vidas en un eslabón débil dentro de la infraestructura crítica de tráfico.
Según datos de la propia operadora, Vodafone ha comercializado ya más de 250.000 unidades de luces V16 conectadas Help Flash IoT en España, lo que multiplica el alcance potencial de cualquier fallo de seguridad.
Un dispositivo clave en la nueva seguridad vial conectada
Help Flash IoT es una baliza V16 conectada desarrollada por la empresa gallega Netun Solutions. El dispositivo se fija de forma magnética en el techo del vehículo, emite una luz LED visible a 1 kilómetro y envía de forma automática la ubicación del coche detenido a la nube DGT 3.0 mediante una eSIM y la red NB-IoT de Vodafone, con un plan de datos incluido durante 12 años y sin cuotas adicionales, tal y como recogen las fichas comerciales y la propia normativa.
La filosofía detrás de la V16 conectada es sencilla: menos personas caminando por el arcén para colocar triángulos, más visibilidad desde el interior del vehículo y datos en tiempo real para avisar al resto de conductores a través de paneles de mensaje variable y aplicaciones de navegación. Sobre el papel, un ejemplo de cómo la Internet de las Cosas (IoT) puede mejorar la seguridad en carretera.
Precisamente por ese carácter crítico —y por el hecho de que será un dispositivo obligatorio por ley—, la robustez de su diseño de ciberseguridad adquiere una importancia que va mucho más allá de un simple “gadget” para el coche.
La investigación: de un puerto serie abierto a una lista de fallos encadenados
En su informe público, Miranda detalla que ha realizado el análisis sobre varias unidades de Help Flash IoT adquiridas en el canal comercial, sin acceder a sistemas de terceros y siguiendo un proceso de divulgación responsable. Algunos detalles técnicos y el código completo de la prueba de concepto han sido deliberadamente omitidos para evitar una explotación masiva.
A partir de ahí, el investigador describe dos grandes bloques de vulnerabilidades:
- Comunicaciones móviles sin cifrado ni autenticación robusta.
- Un sistema de actualización OTA (Over-The-Air) vía WiFi no documentado, sin control de autenticidad ni integridad del firmware.
Ambas piezas, combinadas, configurarían un escenario que recuerda más a un manual de “cómo no diseñar un dispositivo IoT” que a un producto homologado para integrarse con la plataforma nacional DGT 3.0.
Comunicaciones en claro: la baliza “grita” su ubicación y su identidad
El funcionamiento básico de la Help Flash IoT, según el análisis, sigue el esquema previsto por la normativa: al activarse, la baliza obtiene coordenadas GPS y se conecta mediante NB-IoT al operador, enviando periódicamente mensajes con información como la hora de la incidencia, las coordenadas, identificadores del dispositivo y parámetros de red.
El problema, según Miranda, es cómo se hace todo esto: los datos se transmiten en texto plano, sin cifrado a nivel de aplicación y sin mecanismos robustos de autenticación ni de integridad del mensaje. Es decir, el servidor no tiene forma sólida de comprobar que el mensaje procede realmente de una baliza legítima ni de garantizar que no ha sido manipulado por el camino.
En la práctica, esto implica tres riesgos clave:
- Privacidad comprometida. Un atacante con capacidad para observar ese tráfico podría rastrear la ubicación en tiempo (casi) real asociada a un dispositivo concreto, conocer el momento exacto de la incidencia y acceder a identificadores únicos como el IMEI.
- Suplantación de dispositivos. Si el servidor se fía de un simple identificador enviado en claro, recrear mensajes falsos que aparenten proceder de una baliza concreta se vuelve mucho más sencillo.
- Alteración de datos en tránsito. Sin firmas ni sellos de integridad, un atacante situado en medio de la comunicación podría modificar coordenadas o parámetros antes de reenviarlos.
Los operadores suelen argumentar que el uso de APN privados —redes lógicas aisladas dentro de la infraestructura móvil— limita de facto la posibilidad de ataques externos. Pero el informe pone en cuestión esta “seguridad por oscuridad”: con acceso físico a una baliza, o utilizando el propio dispositivo como módem, sería posible conectar a esa red y convertir un supuesto perímetro cerrado en un vecindario mucho más poblado de lo que parece.
Fake eNodeB: estaciones base falsas para interceptar y manipular tráfico
El informe da un paso más y plantea un escenario que los especialistas en ciberseguridad móvil conocen bien: el uso de estaciones base falsas (fake eNodeB) para atraer dispositivos NB-IoT hacia una antena controlada por el atacante.
Con hardware relativamente asequible —una radio definida por software (SDR) y un ordenador con Linux— y software libre como srsRAN u OpenAirInterface, un atacante podría levantar una célula LTE falsa, realizar interferencias selectivas sobre las bandas que usan las balizas y conseguir que éstas se conecten a su torre en lugar de a la del operador legítimo.
A partir de ahí, el dispositivo seguiría enviando sus mensajes, pero:
- En un modo básico, todo ese tráfico se perdería en el vacío (denegación de servicio), mientras el atacante almacena ubicaciones, IMEI y otros metadatos.
- En un escenario más avanzado, si el atacante logra acceso al APN privado, podría actuar como hombre-en-el-medio: leer, modificar e inyectar mensajes antes de reenviarlos a los servidores del fabricante.
El cifrado estándar de LTE protege el enlace radio, pero no el contenido de las tramas UDP de aplicación si éstas viajan en claro. El resultado es que la baliza “confía” plenamente en la red móvil, mientras que la red móvil, mal utilizada, podría convertirse en el canal perfecto para ataques discretos y difíciles de detectar.
La puerta trasera de las actualizaciones OTA: un botón de 8 segundos
Si la parte de comunicaciones es preocupante, el sistema de actualización OTA descrito en el informe añade una capa adicional de riesgo.
Según Miranda, la baliza incluye un modo de actualización por WiFi que no aparece en la documentación pública. Para activarlo, basta con mantener pulsado el botón de encendido durante unos 8 segundos. No se requiere PIN, ni app, ni confirmación adicional: solo acceso físico momentáneo al dispositivo.
Una vez en ese modo, la baliza busca una red WiFi con un nombre (SSID) y una contraseña fijos, embebidos en el firmware y compartidos por todas las unidades analizadas. Es decir, credenciales comunes para decenas o cientos de miles de dispositivos.
El procedimiento de actualización descrito en la investigación presenta varias deficiencias graves:
- Uso de HTTP en lugar de HTTPS. Las balizas descargan configuración y firmware sin cifrado ni protección frente a manipulación.
- Sin verificación de servidor. No hay comprobación de certificados ni autenticidad del origen: cualquier servidor que responda con el hostname esperado es aceptado como legítimo.
- Firmware sin firma digital. El dispositivo no verifica criptográficamente que la imagen de software provenga del fabricante.
Con estos ingredientes, un atacante que monte un punto de acceso WiFi con el mismo nombre y contraseña, un servidor DNS sencillo y un servidor HTTP en un portátil o una pequeña placa (como una Raspberry Pi) podría engañar a la baliza para que descargue e instale un firmware modificado. El investigador asegura haber demostrado en laboratorio que el compromiso puede completarse en menos de un minuto desde que se pulsa el botón.
A partir de ese momento, el control del dispositivo sería total: desde enviar ubicaciones falsas hasta bloquear el envío de alertas, acceder al APN privado o transformar la baliza en un simple “ladrillo luminoso” que ya no cumple la normativa, pero conserva su apariencia de producto homologado.
Del acceso físico puntual al compromiso remoto y masivo
Uno de los puntos más delicados del informe está en cómo se encadenan las vulnerabilidades.
Inicialmente, el investigador trasladó sus hallazgos al INCIBE (Instituto Nacional de Ciberseguridad), que, según el relato publicado, rechazó asignar identificadores CVE al considerar que las vulnerabilidades requerían acceso físico a la electrónica del dispositivo.
Sin embargo, el mecanismo OTA cambia el marco del debate: un acceso físico tan limitado como pulsar un botón durante 8 segundos puede servir para instalar un firmware que, a partir de ahí, actúa de forma remota y persistente, explotando el resto de debilidades de comunicaciones sin necesidad de volver a tocar la baliza.
El propio investigador ha remitido la documentación a MITRE, organismo responsable de la base de datos CVE, para que evalúe si este tipo de escenarios entra dentro de lo que debe considerarse una vulnerabilidad de ciberseguridad en la era del IoT. La decisión aún no es pública.
Escenarios de ataque: del taller de barrio a la furgoneta en movimiento
El informe plantea varios escenarios prácticos —algunos inquietantemente realistas— en los que estas vulnerabilidades podrían explotarse:
- Compromiso en un taller o revisión. Un establecimiento poco escrupuloso podría aprovechar una estancia del vehículo para activar el modo OTA y cargar un firmware manipulado en segundos, sin dejar rastro visible.
- Puntos de acceso maliciosos en gasolineras o áreas de servicio. Con redes WiFi falsas configuradas con las credenciales conocidas de actualización, cualquier baliza que entre en modo OTA en esas zonas podría ser reprogramada automáticamente.
- Furgoneta con antena en carretera. Un atacante con una fake eNodeB móvil podría recorrer zonas de tráfico intenso para interceptar comunicaciones, provocar denegaciones de servicio o inyectar falsas incidencias en la plataforma.
El impacto va más allá de la privacidad individual: un número suficiente de balizas comprometidas podría degradar la confianza en el sistema DGT 3.0, disparar falsas alarmas o, en el peor escenario, ocultar incidencias reales en determinados tramos o momentos.
Un dispositivo obligatorio… con seguridad opcional
Mientras organizaciones de consumidores como OCU y FACUA llevan meses alertando sobre la venta de balizas V16 no homologadas o que no cumplen los requisitos de conectividad exigidos para 2026, la investigación de Miranda abre otro frente: ¿qué ocurre cuando el problema no es la homologación visible, sino lo que ocurre “bajo la carcasa” en términos de ciberseguridad?
El contraste es llamativo: el mismo ecosistema en el que se exige al conductor comprobar el número de homologación y la conexión a DGT 3.0, confía en dispositivos que, según este análisis, carecen de elementos básicos como:
- Cifrado de extremo a extremo en las comunicaciones con el backend.
- Autenticación fuerte del servidor y del firmware.
- Firmas digitales y arranque seguro (secure boot) para impedir modificaciones no autorizadas.
Hasta la fecha de esta noticia, no constan comunicados públicos específicos del fabricante, de la DGT o del operador implicado sobre los hallazgos concretos de esta investigación. Sí existe, en todo caso, un contexto creciente de preocupación social por el despliegue masivo de dispositivos conectados obligatorios por ley, tanto por su impacto en privacidad como por el riesgo de que se conviertan en nuevos vectores de ataque dentro de la infraestructura de movilidad inteligente.
Qué debería pasar ahora
El caso de Help Flash IoT, tal y como lo plantea el informe, se ha convertido en un ejemplo pedagógico de lo que muchos expertos llevan años advirtiendo: la seguridad en IoT no puede ser un añadido de última hora, y menos cuando se trata de dispositivos de seguridad crítica sometidos a obligación legal.
Diversas voces del sector de ciberseguridad consultadas en otros debates sobre la V16 conectada han defendido la necesidad de:
- Elevar los requisitos mínimos de seguridad en la normativa, incluyendo cifrado, autenticación, gestión de claves y actualización segura como condiciones de homologación.
- Incorporar auditorías técnicas independientes antes y después de la certificación, especialmente para dispositivos que se integran en plataformas nacionales como DGT 3.0.
- Mejorar los programas de divulgación y gestión de vulnerabilidades, de forma que investigadores y fabricantes puedan coordinarse sin que los problemas se queden en un limbo administrativo.
Mientras tanto, los conductores apenas tienen margen de maniobra: no hay evidencias de que manipular o desactivar las balizas sea una solución —al contrario, puede suponer un riesgo legal y de seguridad vial—, pero sí resulta razonable exigir transparencia, actualizaciones de seguridad y una revisión profunda de los modelos afectados si las vulnerabilidades se confirman.
Lo que está en juego no es solo la eficacia de una luz de emergencia, sino la confianza en un modelo de seguridad vial cada vez más conectado, en el que un fallo de diseño puede multiplicarse por cientos de miles de dispositivos repartidos por todo el país.
Preguntas frecuentes sobre las balizas V16 conectadas y la seguridad de Help Flash IoT
¿Qué es una baliza V16 conectada y por qué será obligatoria en España?
La baliza V16 conectada es un dispositivo luminoso de emergencia que se coloca en el techo del vehículo en caso de avería o accidente. Emite una luz visible a 360º y, además, envía la ubicación exacta del coche inmovilizado a la plataforma DGT 3.0 mediante una eSIM integrada y conectividad IoT. A partir del 1 de enero de 2026 sustituirá a los triángulos de emergencia como único sistema de preseñalización homologado en España, con el objetivo de reducir atropellos y mejorar la gestión de incidencias en carretera.
¿En qué consisten las vulnerabilidades detectadas en la baliza Help Flash IoT?
Según la investigación de Luis Miranda Acebedo, las principales debilidades se concentran en dos frentes: las comunicaciones móviles —que se realizan en texto claro, sin autenticación ni integridad robustas— y el sistema de actualización OTA vía WiFi, activable con una pulsación prolongada del botón y basado en una red WiFi con credenciales comunes, sin cifrado HTTPS ni firma digital del firmware. La combinación de ambos fallos permitiría interceptar, manipular o falsificar las alertas que la baliza envía a la infraestructura del fabricante y, por extensión, a la DGT 3.0.
¿Qué riesgos reales asume un conductor que utiliza una baliza V16 vulnerable?
Para el usuario individual, el riesgo más evidente es que, en una situación de emergencia, la baliza no cumpla su función: podría dejar de enviar la alerta, enviar una ubicación errónea o comportarse de forma imprevisible si ha sido comprometida. A ello se suma un impacto en la privacidad —posible rastreo de la ubicación mientras el dispositivo esté activo— y un riesgo sistémico: un número elevado de balizas manipuladas podría generar falsas alarmas masivas o interferir en la gestión de incidencias reales por parte de los servicios de tráfico.
¿Qué pueden hacer fabricantes, reguladores y usuarios tras conocerse estos fallos?
Los fabricantes tienen en su mano revisar el diseño de seguridad, publicar actualizaciones de firmware firmadas, cerrar accesos inseguros y establecer programas claros de divulgación de vulnerabilidades. La DGT y el regulador deberían evaluar si las exigencias actuales de homologación son suficientes para dispositivos IoT críticos, e incorporar requisitos explícitos de ciberseguridad. Los conductores, por su parte, pueden: comprobar que su baliza está homologada, seguir las recomendaciones oficiales, evitar manipular el dispositivo y mantenerse atentos a posibles comunicaciones del fabricante o de la DGT sobre actualizaciones o retiradas de producto.
Fuentes:
– Informe técnico “Vulnerabilidades en Balizas V16 Conectadas: Cuando la Seguridad Vial se Vuelve Insegura”, de Luis Miranda Acebedo, publicado en GitHub el 05/12/2025.
