La baliza V16 conectada que debía proteger a los conductores abre un frente de ciberseguridad en plena cuenta atrás hacia 2026

Cuando la Dirección General de Tráfico (DGT) decidió que, a partir del 1 de enero de 2026, la baliza V16 conectada sería el único dispositivo válido para señalizar averías y accidentes, el mensaje fue claro: menos riesgo al no tener que salir del coche y más información en tiempo real para gestionar el tráfico.

Pero en plena recta final hacia esa obligación, una investigación de ciberseguridad sobre uno de los modelos más vendidos, la Help Flash IoT, ha encendido una luz ámbar. El dispositivo, fabricado por la gallega Netun Solutions y comercializado durante años junto a Vodafone, acumula más de 250.000 unidades vendidas en España.

El problema es que, según el análisis del investigador independiente Luis Miranda Acebedo, su diseño de seguridad informática dista mucho de estar a la altura del papel crítico que se le ha asignado en carretera.


De “gadget” útil a pieza crítica de la seguridad vial conectada

En apariencia, la baliza Help Flash IoT es un objeto sencillo: un pequeño dispositivo con base magnética que se coloca en el techo del vehículo cuando este queda inmovilizado. Emite una luz intermitente visible a 360 grados y hasta 1 kilómetro, incluso con lluvia o poca luz.

La parte menos visible es la que la convierte en pieza clave del nuevo modelo de seguridad vial: lleva una eSIM integrada y se conecta a la red NB-IoT del operador. Cada vez que se activa, envía la ubicación del vehículo y otros datos técnicos a un servidor del fabricante, que a su vez los remite a la plataforma DGT 3.0. Desde ahí, la incidencia puede aparecer en paneles informativos, navegadores o apps de tráfico.

Es el tipo de automatismo que muchos conductores dan por hecho en la era del coche conectado: encender la luz y olvidarse, confiando en que la tecnología hará el resto. La investigación de Miranda viene a recordar que, en el mundo digital, esa confianza exige algo más que homologaciones y logotipos.


La investigación: una auditoría técnica desde fuera

El informe, publicado el 5 de diciembre de 2025 en GitHub, analiza al detalle varias unidades de Help Flash IoT adquiridas en el canal comercial. No hay acceso a sistemas de terceros ni interceptación de tráfico ajeno; sí trabajo de laboratorio, desmontaje del dispositivo, acceso al puerto de depuración y observación del comportamiento en red.

Miranda explica que ha seguido un proceso de divulgación responsable y que ha omitido parte del código y de los detalles más sensibles para evitar que su trabajo se convierta en un “manual de instrucciones” para delincuentes. Aun así, lo que sí se cuenta basta para dibujar un cuadro preocupante:

  • comunicaciones sin cifrado a nivel de aplicación,
  • ausencia de autenticación robusta,
  • un sistema de actualización por WiFi no documentado,
  • credenciales compartidas entre dispositivos,
  • y falta de firma digital en el firmware.

Todo ello en un producto obligatorio por ley e integrado en una infraestructura nacional crítica.


Mensajes sin candado: datos sensibles que viajan “a la vista”

El funcionamiento básico de la baliza es el esperado: al encenderla, el dispositivo intenta obtener coordenadas GPS y se conecta a la red NB-IoT del operador. A partir de ahí, envía periódicamente mensajes con la hora, la posición, el identificador del dispositivo y parámetros de red al servidor del fabricante, que procesa la información y la reenvía a la DGT.

Según el informe, el problema está en cómo se protege —o no se protege— esa información. El tráfico de aplicación viajaría en texto claro, sin cifrado propio ni mecanismos sólidos que permitan al servidor comprobar que el mensaje procede de una baliza legítima y que no ha sido manipulado.

Eso abre tres frentes:

  • Privacidad: quien estuviera en posición de ver ese tráfico podría saber dónde y cuándo se ha activado una baliza concreta, e incluso vincularlo a su IMEI.
  • Suplantación: si el servidor se fía de un identificador enviado en claro, resulta mucho más sencillo fabricar mensajes falsos que parezcan legítimos.
  • Manipulación: sin firmas ni sellos de integridad, un tercero podría alterar coordenadas o datos técnicos antes de reenviarlos.

Los operadores suelen apelar al uso de APN privados —redes lógicas aisladas dentro de la red móvil— como barrera de seguridad. Pero el análisis recuerda que, una vez que alguien consigue entrar en esa red, por ejemplo desde un dispositivo manipulado, la “burbuja” deja de ser tan hermética.


Estaciones base falsas: la amenaza silenciosa de las fake eNodeB

La investigación entra también en un terreno conocido por expertos en ciberseguridad móvil: las estaciones base falsas o fake eNodeB. Con una radio definida por software relativamente asequible y software libre, un atacante puede levantar una antena LTE falsa que se presenta como la mejor opción disponible en la zona.

Si además realiza interferencias selectivas en las bandas que usan las balizas, puede conseguir que éstas se conecten a su antena en lugar de a la del operador. A partir de ahí, las posibilidades van desde captar y dejar caer el tráfico (provocando una denegación de servicio “silenciosa”) hasta leerlo, modificarlo y reenviarlo a su destino real en un escenario de ataque de hombre en el medio.

El cifrado propio de LTE protege el enlace radio, pero no el contenido de la capa de aplicación si este viaja sin cifrado adicional. En otras palabras: el canal radio puede ir cifrado, pero el “mensaje dentro del sobre” sigue en claro.


El modo oculto de actualización: un WiFi compartido y sin candado

La otra gran pieza del rompecabezas está en el mecanismo de actualización OTA (Over-The-Air). Según el informe, la baliza incorpora un modo de actualización por WiFi que no figura en manuales ni documentación comercial. Para activarlo, basta con mantener pulsado el botón durante unos 8 segundos.

Cuando entra en ese modo, el dispositivo busca una red con un SSID y una contraseña fijos, incrustados en el firmware. Miranda comprobó que al menos dos unidades compradas en momentos distintos compartían las mismas credenciales, lo que sugiere que todas las balizas del modelo utilizan la misma “llave” para actualizarse.

A partir de ahí, la baliza se conecta a ese WiFi y busca un servidor de actualizaciones desde el que descargar un archivo de configuración y, si procede, nuevo firmware. El problema es que:

  • la conexión se realiza sobre HTTP, no HTTPS,
  • no se comprueba la autenticidad del servidor,
  • ni se verifica criptográficamente que el firmware procede del fabricante.

Es decir, la baliza confía en cualquiera que responda como si fuera el servidor legítimo.


Cómo se podría explotar: un minuto, un punto de acceso y un firmware alterado

Con esos ingredientes, el escenario de ataque que plantea el informe es directo:

  1. Crear un punto de acceso WiFi con el mismo nombre y contraseña que la red de actualización.
  2. Montar un pequeño servidor DNS y HTTP en un ordenador o una placa tipo Raspberry Pi.
  3. Preparar un archivo de configuración y un firmware modificados.
  4. Poner la baliza en modo OTA manteniendo pulsado el botón.

En unos 30-60 segundos, la baliza podría conectarse al punto de acceso falso, “creerse” la dirección proporcionada por el servidor DNS malicioso y descargar el firmware manipulado desde el servidor HTTP. Tras reiniciarse, el control del dispositivo quedaría en manos de quien ha preparado la actualización.

Desde ese momento, el atacante podría decidir si la baliza envía ubicaciones falsas, deja de enviar avisos, se conecta al APN privado para lanzar otros ataques o simplemente se comporta como un dispositivo aparentemente normal, pero ya no fiable.


El debate con INCIBE y el significado de “acceso físico”

Miranda trasladó estas vulnerabilidades al Instituto Nacional de Ciberseguridad (INCIBE). Según relata, el organismo declinó inicialmente tramitar la asignación de identificadores CVE al considerar que se trataba de fallos que requerían “acceso físico” al dispositivo.

El investigador discrepa en parte: una cosa es tener que desarmar la electrónica y otra, muy distinta, pulsar un botón durante unos segundos. Más aún cuando ese gesto puede convertir un acceso puntual en un control remoto sostenido en el tiempo gracias al firmware malicioso.

El caso está también en manos de MITRE, la organización estadounidense que mantiene la base de datos CVE, para que valore si este tipo de vectores deben considerarse vulnerabilidades de ciberseguridad en el contexto del Internet de las Cosas.


Consumidores atrapados entre la norma, el mercado y la seguridad

Todo esto ocurre mientras la presión sobre los conductores aumenta. La DGT ha reiterado que no habrá prórroga en la obligación de disponer de una baliza V16 conectada y que, desde 2026, los triángulos dejarán de ser válidos como único sistema de señalización.

Al mismo tiempo, asociaciones como FACUA y OCU denuncian un “fraude masivo” en la venta de balizas que se presentan como válidas cuando en realidad no cumplirán la normativa de 2026, bien porque no están conectadas, bien porque no figuran en los listados oficiales de dispositivos homologados.

La investigación sobre Help Flash IoT añade una capa más compleja: plantea que incluso un dispositivo homologado, conectado y vendido por canales oficiales puede arrastrar fallos de diseño en ciberseguridad que no se han tenido suficientemente en cuenta en su evaluación.


Qué piden los expertos y qué puede hacer hoy un conductor

Los especialistas en seguridad consultados en otros debates sobre la V16 conectada coinciden en tres líneas de actuación:

  • elevar los requisitos mínimos de ciberseguridad en la normativa y en los procesos de homologación,
  • incorporar cifrado de extremo a extremo, firmas digitales y arranque seguro como condición obligatoria,
  • y reforzar los programas de divulgación responsable para que fabricantes e investigadores trabajen alineados.

Para el conductor de a pie, el margen de maniobra es más limitado pero no inexistente. Los expertos recomiendan:

  • comprobar que la baliza está efectivamente homologada y conectada a DGT 3.0,
  • no manipular ni modificar el dispositivo,
  • estar atento a posibles comunicados del fabricante o de la DGT sobre actualizaciones de seguridad o sustituciones,
  • y adquirir los dispositivos en canales de confianza, recelando de ofertas que no indiquen claramente la homologación.

La paradoja es evidente: quien ya ha hecho el esfuerzo de comprar una baliza conectada para cumplir la normativa y aumentar su seguridad, se encuentra ahora con preguntas que solo fabricantes y autoridades pueden responder.


Preguntas frecuentes sobre balizas V16 conectadas y seguridad informática

¿Por qué será obligatoria la baliza V16 conectada a partir de 2026?
La DGT ha decidido que, desde el 1 de enero de 2026, la baliza V16 conectada sustituya a los triángulos como único sistema válido para señalizar un vehículo inmovilizado. El objetivo es mejorar la seguridad vial permitiendo avisar sin salir del coche y, al mismo tiempo, enviar la ubicación a la plataforma DGT 3.0 para gestionar mejor las incidencias en carretera.

¿En qué consisten las vulnerabilidades detectadas en la baliza Help Flash IoT?
La investigación de Luis Miranda Acebedo describe dos grandes bloques de fallos: comunicaciones hacia los servidores del fabricante sin cifrado ni autenticación robusta, y un sistema de actualización por WiFi no documentado que se activa manteniendo pulsado un botón, utiliza una red con credenciales comunes para todos los dispositivos y descarga firmware por HTTP sin verificar su origen ni su integridad. En conjunto, estos fallos podrían permitir interceptar, manipular o falsificar las alertas que envía la baliza.

¿Cómo puede saber un conductor si su baliza V16 es válida y segura?
En primer lugar, debe comprobar que la baliza está homologada y conectada a DGT 3.0, revisando que aparezca esa mención en el dispositivo y que figure en los listados oficiales. Organizaciones como OCU y FACUA aconsejan desconfiar de balizas muy baratas, sin referencia clara a la conectividad ni al número de homologación. En cuanto a la seguridad informática, hoy por hoy depende del diseño de cada fabricante; por eso se pide que la normativa incorpore requisitos específicos de ciberseguridad.

¿Qué deberían hacer la DGT y los fabricantes tras conocerse estos fallos de seguridad?
Los expertos señalan tres pasos clave: auditar en profundidad los modelos afectados y publicar actualizaciones de firmware firmadas que corrijan las debilidades; revisar los criterios de homologación para exigir cifrado, autenticación y arranque seguro en todos los dispositivos conectados; y mejorar la comunicación con los usuarios, de forma que cualquier incidencia o sustitución se gestione con transparencia y plazos claros. También se reclama una coordinación más estrecha con investigadores independientes y organismos como INCIBE y MITRE para que casos como este no queden en un limbo.

vía: Seguridad en Balizas v16

Scroll al inicio