Starting January 1, 2026, all vehicles on Spanish roads will be required to replace emergency triangles with V16 luminous beacons connected to the DGT 3.0 platform. These signals, equipped with geolocation and IoT connectivity, are marketed as a significant advancement in road safety: they allow quick alerts to other drivers and traffic control centers without the affected person having to leave the vehicle.
However, an investigation published on December 5, 2025, by independent researcher Luis Miranda Acebedo has raised serious concerns. The technical analysis of the Help Flash IoT beacon—one of the most well-known models on the market, sold with Vodafone and approved by the DGT—describes a chain of vulnerabilities that, according to the author, could turn a device intended to save lives into a weak link within the critical traffic infrastructure.
According to data from the operator itself, Vodafone has already sold over 250,000 units of connected V16 Help Flash lights in Spain, vastly increasing the potential impact of any security flaw.
A Key Device in the New Connected Road Safety
Help Flash IoT is a V16 beacon developed by Galicia-based Netun Solutions. The device is magnetically fixed to the vehicle’s roof, emits a LED light visible from up to one kilometer, and automatically sends the vehicle’s location to the DGT 3.0 cloud via an eSIM and Vodafone’s NB-IoT network, with a data plan included for 12 years and no additional charges, as outlined in product datasheets and regulations.
The principle behind the connected V16 is simple: fewer people walking on the shoulder to place triangles, increased visibility from inside the vehicle, and real-time data to alert other drivers via variable message panels and navigation apps. On paper, an example of how the Internet of Things (IoT) can improve road safety.
Precisely because of its critical role—and the fact that it will be a legally mandatory device—its cybersecurity robustness becomes crucial, extending far beyond a mere car gadget.
The Investigation: From an Open Serial Port to a Chain of Vulnerabilities
In their public report, Miranda details that he analyzed several Help Flash IoT units obtained through commercial channels, without accessing third-party systems, following responsible disclosure practices. Some technical details and the full proof-of-concept code have been omitted intentionally to prevent widespread exploitation.
He describes two major vulnerability clusters:
- Unencrypted mobile communications and weak authentication.
- undocumented OTA (Over-The-Air) update system via WiFi, without authenticity or firmware integrity checks.
Combined, these issues create a scenario more reminiscent of a “how not to design an IoT device” manual than a certified product integrated with the national DGT 3.0 platform.
Clear Text Communications: The Beacon “Shouts” Its Location and Identity
The basic operation of Help Flash IoT, as the analysis shows, follows the expected pattern: upon activation, the beacon obtains GPS coordinates and connects via NB-IoT to the operator, periodically sending messages with information such as incident time, coordinates, device identifiers, and network parameters.
The problem, according to Miranda, is how this is done: data is transmitted in plain text, with no application-layer encryption and without robust mechanisms for message authentication or integrity. In other words, the server has no solid way to verify that the message truly comes from a legitimate beacon or to ensure it hasn’t been tampered with along the way.
This leads to three key risks:
- Privacy compromise. An attacker observing this traffic could track the device’s location in near real-time, know the exact time of the incident, and access unique identifiers like IMEI.
- Device impersonation. If the server trusts a simple identifier sent in clear text, it becomes easier for an attacker to craft fake messages that appear to originate from a specific beacon.
- Data alteration in transit. Without signatures or integrity checks, an intermediary attacker could modify coordinates or parameters before forwarding them.
Operators often argue that the use of private APN networks—isolated logical networks within the mobile infrastructure—limits external attack possibilities. But the report casts doubt on this “security through obscurity”: physical access to a beacon or using the device as a modem could allow connecting to this network and turning what appears to be a closed perimeter into a more vulnerable environment.
Fake eNodeB: False Base Stations to Intercept and Manipulate Traffic
The report goes further, presenting a scenario well known to mobile cybersecurity experts: using fake eNodeB stations to lure NB-IoT devices into controlled cells.
With affordable hardware—such as software-defined radios (SDRs) and Linux-based computers—and open-source software like srsRAN or OpenAirInterface, an attacker could deploy a fake LTE cell, perform selective interference over the beacon’s operating bands, and trick it into connecting to their tower instead of the legitimate network.
From there, the device would continue sending messages, but:
- In a basic mode, all traffic could be lost — a denial-of-service— while the attacker logs locations, IMEI, and other metadata.
- In a more advanced scenario, if the attacker gains access to the private APN, they could act as a man-in-the-middle, intercepting, modifying, or injecting messages before they reach the manufacturer’s servers.
Although LTE’s standard encryption protects the radio link, it does not encrypt application-layer UDP payloads if sent in plain text. The result is that the beacon fully trusts the mobile network, which, if misused, can become a covert channel for discreet, hard-to-detect attacks.
Backdoor in OTA Updates: An 8-Second Button
If the communication concerns are significant, the OTA update system described in the report adds another risk layer.
Miranda notes the beacon includes a WiFi update mode not declared in official documents. Activating it requires holding the power button for about 8 seconds—no PIN, app, or additional confirmation needed—just physical access for a brief moment.
Once activated, the beacon searches for a WiFi network with fixed SSID and password embedded in firmware, shared across all units analyzed. In other words, uniform credentials for tens or hundreds of thousands of devices.
The update process exhibits critical vulnerabilities:
- HTTP instead of HTTPS. Configuration and firmware are downloaded unencrypted and unprotected against tampering.
- No server verification. No certificate checks—the device accepts any server with the expected hostname.
- Unsigned firmware. The device cryptographically verifies nothing to confirm firmware authenticity.
Using these flaws, an attacker deploying a WiFi access point with matching credentials, a simple DNS server, and a hosting server on a portable device (e.g., Raspberry Pi) could trick the beacon into downloading and installing malicious firmware. The researcher has demonstrated in a lab environment that this can be accomplished in under a minute after pressing the button.
Once compromised, the attacker has full control: fake locations, disabling alerts, accessing the private APN, or turning the beacon into a “dumb light”—no longer compliant but still looking like an approved device.
From Physical Access to Remote, Widespread Exploits
One of the more sensitive points is how vulnerabilities escalate in scope. Initially, Miranda reported findings to INCIBE (National Cybersecurity Institute), which reportedly declined to assign CVEs, arguing that physical access was necessary for exploitation.
But the OTA mechanism changes this perspective: a single physical act—pressing a button for 8 seconds—can install firmware that permits remote, persistent control, exploiting other communication flaws without further physical interaction.
Miranda has submitted documentation to MITRE to evaluate whether such scenarios should be classified as cybersecurity vulnerabilities, within the CVE database. A decision is pending.
Attack Scenarios: From a Local Workshop to a Moving Van
The report outlines several practical—and some disturbingly realistic—cases where these vulnerabilities could be exploited:
- Vehicle repair shop compromise. A dishonest workshop could activate OTA mode and load malicious firmware in seconds, with no visible signs.
- Malicious access points in gas stations or service areas. Fake WiFi networks, set up with legitimate update credentials, could reprogram beacons entering OTA mode within those zones.
- Mobile fake eNodeB on the road. An attacker with a portable fake cell could traverse high-traffic areas to intercept, deny, or inject false alerts into the system.
The impact extends beyond privacy: a significant number of compromised beacons could undermine trust in the DGT 3.0 system, trigger false alarms, or even conceal real incidents in specific segments or times.
An Obligatory Device… With Optional Security
While consumer organizations like OCU and FACUA have warned for months about the sale of non-compliant or poorly connected V16 beacons, Miranda’s investigation raises another issue: what happens when the problem isn’t just homologation, but the cybersecurity behind the device?
The contrast is striking: the same ecosystem that demands drivers verify approval numbers and connect to DGT 3.0 relies on devices that, as shown, lack fundamental elements such as:
- End-to-end encryption in communication with backend servers
- Strong server and firmware authentication
- Digital signatures and secure boot to prevent unauthorized modifications
As of the date of this report, no public statements have been issued by manufacturers, the DGT, or involved operators regarding these findings. Nonetheless, a growing social concern exists about the widespread deployment of connected devices mandated by law, both for privacy implications and the potential for compromised systems within the intelligent mobility infrastructure.
What Should Happen Now
The case of Help Flash IoT exemplifies what many experts have warned: cybersecurity in IoT cannot be an afterthought, especially for critical safety devices under legal obligation.
Cybersecurity professionals recommend:
- Raising minimum security standards—including encryption, authentication, key management, and secure updates—as certification requirements.
- Implementing independent technical audits before and after certification—especially for devices integrated into national platforms like DGT 3.0.
- Enhancing vulnerability disclosure programs so researchers and manufacturers can coordinate without issues being unresolved in administrative limbo.
Meanwhile, drivers have limited options: manipulating or disabling beacons is risky both legally and for road safety, but there’s a valid expectation for transparency, security updates, and thorough review of affected models if vulnerabilities are confirmed.
Ultimately, the effectiveness of an emergency light depends not just on visibility but also on trust in an increasingly connected road safety model, where a simple design flaw could jeopardize millions of devices across the country.
Frequently Asked Questions About Connected V16 Beacons and Help Flash IoT Security
What is a connected V16 beacon, and why will it be mandatory in Spain?
The connected V16 beacon is an emergency luminous device mounted on the vehicle roof in case of breakdown or accident. It emits a 360º visible light and automatically transmits the vehicle’s exact location to the DGT 3.0 platform via an embedded eSIM and IoT connectivity. From January 1, 2026, it will replace emergency triangles as the only homologated signaling system in Spain, aiming to reduce accidents and improve incident management.
What vulnerabilities were identified in the Help Flash IoT beacon?
Research by Luis Miranda Acebedo highlights two main weaknesses: mobile communications occurring in plain text without strong authentication or integrity measures, and an undocumented OTA update system activated by holding the power button, based on a WiFi network with shared credentials, lacking HTTPS encryption and firmware signing. Together, these flaws could allow interception, manipulation, or forgery of alerts sent to the manufacturer’s infrastructure and subsequently to the DGT 3.0 platform.
What real risks does a driver face using a vulnerable V16 beacon?
The primary risk is device failure during an emergency: it may stop sending alerts, send incorrect locations, or behave unpredictably if compromised. Additional risks include privacy breaches—possible real-time tracking—and systemic threats: a large number of manipulated beacons could cause false alarms or interfere with actual incident management.
What can manufacturers, regulators, and users do after discovering these issues?
Manufacturers should review security design, publish signed firmware updates, close insecure access points, and establish effective vulnerability disclosure programs. Regulators like the DGT should assess whether current homologation standards address cybersecurity needs for critical IoT devices, incorporating explicit security requirements. Users should verify device approval, follow official guidelines, avoid tampering, and stay alert for updates or recalls from manufacturers or authorities.
Sources:
– Technical report “Vulnerabilities in Connected V16 Beacons: When Road Safety Becomes Unsafe,” by Luis Miranda Acebedo, published on GitHub on 12/05/2025.