Las 5 vulnerabilidades críticas de las balizas V16 conectadas

Última actualización: 10/12/2025
Autor: Isaac
  • Las balizas V16 conectadas serán obligatorias y forman parte de la infraestructura crítica DGT 3.0, pero su normativa apenas exige ciberseguridad.
  • La investigación sobre Help Flash IoT revela comunicaciones sin cifrar, estación base falsa y un peligroso modo OTA WiFi oculto sin autenticación.
  • Estas debilidades permiten interceptar, manipular o falsificar avisos de emergencia, con impacto directo en la privacidad y la gestión del tráfico.
  • Fabricantes y reguladores deben elevar los requisitos de seguridad y actualizar dispositivos ya vendidos para que la baliza cumpla su función sin convertirse en un riesgo.

Vulnerabilidades críticas en balizas V16

La llegada obligatoria de las balizas V16 conectadas en España ha convertido a estos pequeños dispositivos en una pieza clave de la nueva seguridad vial digital. Van a sustituir a los triángulos, se activan sin bajarse del coche y mandan la ubicación del vehículo a la plataforma DGT 3.0. Sobre el papel suena perfecto, pero cuando se examina su ciberseguridad con lupa el panorama cambia, y mucho.

En los últimos meses, el ingeniero de telecomunicaciones y hacker ético Luis Miranda Acebedo ha destapado cinco vulnerabilidades críticas en un modelo muy popular de baliza V16 conectada (Help Flash IoT, que se comercializa también con Vodafone). Sus pruebas demuestran que la combinación de comunicaciones sin cifrar, un sistema de actualizaciones OTA inseguro y puertos de depuración accesibles convierten a estas balizas en un posible eslabón débil dentro de una infraestructura de tráfico que se supone crítica.

Contexto: qué es una baliza V16 conectada y qué exige la normativa

Las balizas V16 conectadas nacen de la normativa recogida en el Real Decreto 159/2021 y la actualización del Reglamento General de Vehículos, que establecen que, a partir del 1 de enero de 2026, serán el único sistema legal para preseñalizar un vehículo inmovilizado en carretera en España. Su objetivo principal es reducir el riesgo de atropello y mejorar la gestión de incidentes.

Estos dispositivos se colocan en el techo del coche mediante un imán y emiten una luz ámbar visible a 360 grados. La regulación fija, además, una serie de requisitos técnicos relacionados con la parte lumínica: un campo de visibilidad horizontal completo, un ángulo vertical mínimo de ±8 grados y una intensidad de entre 40 y 700 candelas en el eje principal (y entre 25 y 600 candelas en esos ±8 grados).

En cuanto al parpadeo, la normativa exige que la frecuencia de destello se sitúe entre 0,8 y 2 Hz para que la luz sea claramente perceptible como señal de emergencia. Además, las balizas deben asegurar un funcionamiento continuo mínimo de 30 minutos tras su activación, incluso en condiciones adversas, ya sea mediante pilas reemplazables o baterías.

La gran diferencia con los antiguos triángulos está en la conectividad: las balizas V16 que cumplen la norma deben incorporar una SIM o eSIM integrada que conecte automáticamente con la plataforma DGT 3.0, enviando la localización GPS exacta del vehículo parado, la hora de activación y otros parámetros técnicos, todo ello sin que el conductor tenga que usar el móvil.

La normativa también obliga a que el dispositivo ofrezca 12 años de conectividad garantizada sin coste adicional para el usuario. Es decir, el precio de compra incluye el servicio de datos durante toda la vida útil contemplada por la DGT, sin cuotas ni suscripciones posteriores.

El gran punto ciego: la ciberseguridad no está en la homologación

Aunque el Reglamento y las guías de la DGT bajan al detalle sobre requisitos de luz, visibilidad y conexión con la plataforma DGT 3.0, la parte de ciberseguridad brilla por su ausencia en los documentos públicos. No se mencionan estándares mínimos sobre cifrado, autenticación o integridad de los mensajes enviados por las balizas.

En la práctica, esto significa que una baliza puede estar homologada con el código LCOE y lucir su correspondiente código (LCOE, IDIADA, etc.) cumpliendo los requisitos funcionales de iluminación y conectividad, pero sin haber pasado por una auditoría de ciberseguridad concreta. La homologación se centra en que la baliza se vea y se conecte, no en cómo protege los datos ni cómo gestiona sus actualizaciones.

Este vacío normativo es el caldo de cultivo perfecto para que aparezcan problemas como los descritos en el análisis de Luis Miranda: dispositivos oficialmente válidos que, sin embargo, presentan fallos graves en cifrado, autenticación y gestión de firmware. Todo ello en un entorno, el de la DGT 3.0, que se considera ya infraestructura crítica de tráfico.

Mientras las autoridades insisten en que la baliza esté conectada y certificada, apenas se habla de si el tráfico va cifrado, si los firmwares están firmados digitalmente o si hay mecanismos robustos para impedir que un tercero manipule el dispositivo. Esta brecha entre lo que se exige al usuario y lo que se exige al fabricante es una de las claves del debate actual.

La investigación de Luis Miranda sobre Help Flash IoT

consejos de seguridad para proteger tus criptomonedas

El ingeniero y hacker ético Luis Miranda Acebedo ha centrado su análisis en la baliza Help Flash IoT, uno de los modelos más vendidos en España y distribuido junto a Vodafone, que usa la red NB-IoT/LTE-M del operador. Según datos citados por el propio fabricante y la teleco, hay más de 250.000 unidades en circulación, lo que multiplica el alcance potencial de cualquier vulnerabilidad.

  Rts dsrlte | Qué Es, De Dónde Proviene y Cómo Eliminarlo

Para su estudio, Miranda adquirió varias balizas en el canal comercial, sin acceso privilegiado al fabricante ni a la operadora. El análisis, publicado en abierto y con parte del código disponible en GitHub, describe paso a paso cómo se han realizado las pruebas, aunque omite algunos detalles técnicos para evitar facilitar explotaciones a gran escala.

De ese trabajo surgen al menos cinco vulnerabilidades importantes que se pueden agrupar en tres grandes vectores de ataque: acceso al hardware y puertos de depuración, interceptación y manipulación de las comunicaciones móviles, y secuestro del sistema de actualización OTA vía WiFi oculto. Combinadas, forman una especie de manual de “así no se diseña la seguridad de un dispositivo IoT crítico”.

El investigador notificó inicialmente estos fallos al INCIBE, pero la entidad rechazó asignar identificadores CVE alegando que requerían “acceso físico” al dispositivo. Posteriormente, Miranda remitió el caso a MITRE para que valorara si este tipo de problemas encajan en la definición moderna de vulnerabilidad, teniendo en cuenta que basta con pulsar un botón durante ocho segundos para activar uno de los mecanismos más delicados del sistema.

Comunicaciones móviles en claro: privacidad y suplantación

El primer bloque de problemas está relacionado con cómo se comunican estas balizas con los servidores del fabricante y, por extensión, con la plataforma de la DGT. Cuando se activa una Help Flash IoT, el dispositivo obtiene sus coordenadas GPS, recoge ciertos parámetros de red y envía toda esta información mediante la red NB-IoT/LTE-M de Vodafone.

Según el análisis de tráfico realizado por Miranda, esos mensajes se envían usando un protocolo tipo UDP propietario, pero con el contenido de la aplicación en texto plano, sin cifrado adicional. No hay TLS ni cifrado de extremo a extremo que proteja lo que la baliza manda una vez que sale de su pequeño hardware hacia la infraestructura móvil.

En esos paquetes viajan datos muy sensibles: las coordenadas GPS con una precisión inferior a 5 metros (exigida por la DGT), el IMEI asociado a la eSIM del dispositivo, información sobre la antena a la que se conecta (identidad de la celda, intensidad de señal, operador) y la marca temporal precisa del momento en que se ha activado la baliza.

Además de ir sin cifrar, la comunicación no está autenticada de forma robusta: el servidor receptor no dispone de un mecanismo fuerte para comprobar que el mensaje lo envía realmente la baliza que dice enviarlo, más allá de identificadores que viajan a la vista de cualquiera que intercepte el tráfico. Tampoco hay un control de integridad criptográfica, de modo que no se verifica si el contenido ha sido modificado por el camino.

El resultado es un triple fallo respecto a los principios básicos de la seguridad de la información: sin confidencialidad, sin autenticación y sin integridad. Un atacante con acceso al “vecindario” de red adecuado podría leer los datos, hacerse pasar por un dispositivo concreto o alterar campos como la ubicación antes de que lleguen al servidor. Es como si, en lugar de hacer una llamada discreta a emergencias, alguien cogiera un megáfono y fuera gritando su dirección exacta en mitad de la calle.

APN privado y estaciones base LTE falsas (fake eNodeB)

Al hablar con fabricantes y operadores, el argumento recurrente es que estas comunicaciones van encapsuladas en un APN privado del operador móvil, lo que supuestamente reduce el riesgo de que cualquiera pueda asomarse a ese tráfico. Sin embargo, el informe de Miranda desmonta esta sensación de seguridad, que no deja de ser una forma de “seguridad por oscuridad”.

Con acceso físico a una baliza o a su puerto serie, un atacante podría extraer la eSIM o replicar los parámetros de acceso al APN privado, convirtiendo lo que debería ser una red muy cerrada en un entorno mucho más expuesto. Incluso sin llegar a tanto, usar el propio dispositivo como módem abre la puerta a que quien lo controle se plante en esa red supuestamente aislada.

Además, la tecnología LTE y NB-IoT tiene un talón de Aquiles bien conocido: las estaciones base falsas o fake eNodeB. Con hardware relativamente barato (una radio definida por software, un ordenador con Linux y software libre como srsRAN u OpenAirInterface), es posible levantar una célula LTE que se haga pasar por una antena legítima para los dispositivos cercanos.

Las balizas V16, incluido el modelo Help Flash IoT, están diseñadas para conectarse a la antena que les ofrezca mejor señal disponible, sin hacer muchas más comprobaciones. Esto permite construir escenarios de ataque en los que el delincuente levanta una estación base falsa que atrae a todas las balizas del entorno, capturando, bloqueando o modificando su tráfico a voluntad.

En un modo simple, la estación falsa podría generar una denegación de servicio: la baliza envía sus mensajes de emergencia, pero estos nunca llegan a la DGT porque se quedan atrapados en la antena maliciosa. En un escenario más avanzado, y si el atacante consigue acceso al APN privado, se puede montar un ataque Man-in-the-Middle completo: leer los mensajes, cambiar coordenadas GPS o incluso inyectar incidencias falsas asociadas a IMEI válidos.

  5 Mejores Programas Para Transmitir En Vivo

La puerta oculta: un modo OTA WiFi activable con un botón

El hallazgo más inquietante del informe de Miranda no está en la red móvil, sino en un mecanismo de actualización de firmware que el fabricante no documenta públicamente. La baliza Help Flash IoT incluye un modo OTA vía WiFi oculto que se activa simplemente manteniendo pulsado el botón de encendido durante unos ocho segundos.

Al hacer esa pulsación larga, la baliza entra en modo de actualización y comienza a buscar una red WiFi concreta, con un SSID y una contraseña que están incrustados en el firmware y que, según las pruebas del investigador, serían idénticos para todas las unidades. Es decir, que miles de balizas en el mercado compartirían exactamente las mismas credenciales de acceso.

Una vez conectada a ese punto de acceso, la baliza contacta con un servidor remoto y descarga una actualización de firmware o configuración a través de HTTP sin cifrado. No se emplea HTTPS, ni se verifica la identidad del servidor mediante certificados, ni se comprueba la firma digital del fichero de firmware que llega al dispositivo.

Esto implica que cualquier actor capaz de montar un punto de acceso con el nombre de red y la contraseña apropiados, junto con un servidor DNS y HTTP que simule el del fabricante, puede responder a la llamada de la baliza y entregarle una imagen de firmware completamente manipulada. La baliza, sin comprobaciones criptográficas, la descargará y la ejecutará como si fuera legítima.

Según describe el informe, el proceso completo —pulsar el botón, que la baliza se conecte al WiFi trampa, descargue el nuevo firmware y lo instale— puede llevar menos de un minuto. Desde ese momento, el atacante tendría control total sobre el comportamiento del dispositivo, pudiendo modificar lo que envía, a quién lo envía o incluso desactivar funciones críticas sin que el usuario lo note.

Acceso al hardware: puertos de depuración y escalabilidad del ataque

Aunque la mayoría de escenarios de riesgo no requieren abrir la carcasa de la baliza, la investigación también identificó un problema en el propio hardware: al desmontar una Help Flash IoT, Miranda encontró un puerto de depuración UART expuesto, conectado directamente al procesador principal y sin ningún tipo de protección por contraseña.

Con unas simples pinzas o cables conectados a esos pines, es posible volcar el contenido completo del sistema operativo de la baliza, revisar cómo funciona internamente, extraer parámetros sensibles y, entre otras cosas, obtener las credenciales del famoso WiFi de actualización o el acceso al APN privado del operador.

Que un atacante consiga vulnerar una sola baliza mediante acceso físico al UART no parece dramático por sí mismo, pero el verdadero problema está en la escalabilidad de la amenaza. A partir de esa unidad comprometida, puede desarrollar firmwares maliciosos adaptados a miles de dispositivos idénticos y reutilizar credenciales comunes para generalizar el ataque.

Con esa información, resultarían viables escenarios como el despliegue de puntos de acceso trampa en gasolineras, talleres o áreas de servicio por los que pasan miles de coches cada día, forzando la actualización silenciosa de las balizas que entren en modo OTA. Todo ello a partir del conocimiento obtenido de un solo dispositivo manipulado en laboratorio.

Además, la información interna sirve para construir mejor las estaciones base falsas o para comprender el protocolo propietario con el que la baliza habla con los servidores, facilitando la creación de scripts que generen avisos de emergencia falsos a gran escala o bloqueen los reales, con impacto directo sobre la DGT 3.0.

Escenarios de explotación realistas

Las vulnerabilidades descritas no se quedan en teorías abstractas, sino que se traducen en escenarios de ataque relativamente asequibles para un adversario con conocimientos medios de ciberseguridad y un presupuesto modesto. El propio informe detalla varias posibilidades preocupantes.

En primer lugar, están los talleres o comercios poco escrupulosos. Cuando un coche pasa por una revisión o una instalación de accesorios, un empleado malintencionado puede coger la baliza, mantener pulsado el botón de encendido durante esos ocho segundos críticos y, sin desmontar nada ni levantar sospechas, dejar que se conecte a un punto de acceso WiFi preparado previamente para cargar un firmware manipulado.

Otro escenario probable son las gasolineras, centros comerciales y áreas de servicio donde se montan redes WiFi trampa. Cualquier conductor que, por accidente o curiosidad, active el modo OTA de su baliza en las inmediaciones podría ver cómo su dispositivo se conecta de forma automática a esa red maliciosa y queda reprogramado sin darse cuenta.

A una escala mayor, el informe plantea la posibilidad de utilizar una furgoneta equipada con una fake eNodeB para recorrer zonas de tráfico intenso y, desde ahí, interceptar las comunicaciones de todas las balizas V16 cercanas. Dependiendo de las capacidades del atacante, esto permitiría tanto espiar ubicaciones en tiempo real como simular accidentes y averías inexistentes en puntos estratégicos.

  Cómo fue la llegada de Internet a España y su impacto en nuestra vida

Por último, no se descarta que haya usuarios que utilicen estas debilidades para manipular su propia baliza, instalando un firmware que siga iluminando pero deje de enviar la posición a la DGT. El dispositivo seguiría pareciendo completamente homologado desde fuera, pero se habría perdido de facto la “visibilidad virtual” que la DGT vende como una de las grandes ventajas del sistema.

Obligatoriedad, críticas legales y desconfianza social

La decisión de imponer las balizas V16 conectadas como único sistema legal de preseñalización no ha estado exenta de polémica. A pocas semanas de la entrada en vigor definitiva, han surgido plataformas ciudadanas y asociaciones que cuestionan la medida desde varios frentes.

Por un lado, se critica el coste económico, que ronda los 40 euros de media por dispositivo, en un contexto en el que hay más de 35 millones de vehículos afectados. Diversos estudios apuntan a que un porcentaje elevado de las balizas que se venden en marketplaces como Amazon no cumplen todos los requisitos de homologación, lo que expone a los conductores a multas de entre 80 y 200 euros si son sancionados.

Por otro lado, varias reclamaciones remitidas a la DGT citan el Real Decreto 1030/2022 y plantean dudas en materia de protección de datos: se cuestiona la geolocalización automática y obligatoria del vehículo, la posible ausencia de una evaluación de impacto específica (EIPD), la falta de una ley formal detallada que autorice todo el tratamiento de datos personales asociado a DGT 3.0 y la poca claridad sobre quién accede a esos datos y con qué fines.

También se subraya que, hasta la fecha, ningún país de la Unión Europea exige una baliza conectada que remita la ubicación directamente a una autoridad pública. Esto alimenta el debate sobre si España se ha adelantado demasiado en la digitalización de la seguridad vial sin cerrar antes todos los frentes legales y de seguridad técnica.

Al mismo tiempo, en redes sociales abundan los mensajes de usuarios que ven en estas balizas una forma de vigilancia encubierta sobre sus movimientos, a lo que suman la sospecha de que el Estado recauda voluminosas cantidades en IVA y que solo unas pocas empresas se benefician de la obligación legal, sin que quede claro quién se hace responsable si se demuestra que un modelo certificado era inseguro.

Qué pueden hacer fabricantes, reguladores y conductores

La investigación sobre Help Flash IoT se ha convertido casi en un caso de estudio para ilustrar lo que muchos expertos llevan años advirtiendo: en el Internet de las Cosas, y más aún cuando hay dispositivos obligatorios por ley, la seguridad no puede ser un añadido de última hora ni una simple casilla a marcar en un Excel.

Para los fabricantes, el camino pasa por revisar de arriba abajo el diseño de sus balizas: implementar cifrado de extremo a extremo en las comunicaciones con el backend, utilizar autenticación mutua entre dispositivo y servidor, incorporar firmas digitales y arranque seguro (secure boot) en el firmware y cerrar cualquier mecanismo de actualización que no esté protegido con estándares actuales.

Los reguladores y la propia DGT deberían plantearse elevar el listón de la homologación para estos dispositivos, incluyendo requisitos de ciberseguridad claros: cifrado mínimo obligatorio, gestión de claves, autenticación fuerte y actualización segura como condición imprescindible para dar el visto bueno a un modelo. Además, serían deseables auditorías técnicas independientes antes y después de la certificación.

También es clave mejorar los programas de divulgación y gestión coordinada de vulnerabilidades, facilitando que investigadores como Miranda puedan comunicar fallos de forma responsable y que fabricantes y administraciones reaccionen con transparencia, sin que todo se quede perdido en un limbo administrativo por matices como si un botón pulsado ocho segundos es o no “acceso físico”.

En cuanto a los conductores, su margen de maniobra es limitado: deben llevar una baliza V16 conectada homologada para evitar sanciones, pero sí pueden exigir información clara, actualizaciones de seguridad y transparencia por parte de los fabricantes y de la propia DGT. Lo que no tiene sentido es manipular el dispositivo por cuenta propia, porque, además de ilegal, puede dejarlos vendidos en una emergencia.

Todo este debate cristaliza en una idea sencilla: unas balizas V16 conectadas bien diseñadas pueden ser una herramienta muy potente para reducir atropellos y gestionar mejor el tráfico, pero cuando su ciberseguridad se deja en segundo plano se convierten en una combinación peligrosa de baja visibilidad física, geolocalización obligatoria y vulnerabilidades explotables; justo lo contrario de lo que se espera de un dispositivo creado, en teoría, para salvar vidas.

SOS Alert o MyIncidence: cómo registrar las balizas V16 de la DGT
Artículo relacionado:
SOS Alert o MyIncidence: registrar y usar tu baliza V16 conectada de la DGT