Blatant Design Flaw: How DJI’s “Romo” Robot Vacuum Became a Global Security Risk
- A developer identified a cloud security vulnerability in DJI’s “Romo” robot vacuum, through which around 6,700 devices in 24 countries were accessible.
- The cause was apparently a misconfigured MQTT server with insufficient token binding and enabled wildcard subscriptions.
- Potentially affected were video streams, apartment floor plans, and device data; DJI deployed server-side updates.
A developer wanted to control his robot vacuum using a PlayStation controller. Instead, a digital window opened into thousands of homes worldwide. The case shows how fragile the security architecture of many IoT devices still is.
The starting point was a harmless experiment: developer Sammy Azdoufal wanted to control the “Romo” robot vacuum from Chinese manufacturer DJI—also known for its remote-controlled drones—using a PlayStation 5 controller. To do so, he programmed his own app that communicated with the device via the official cloud infrastructure.
What happened next was not a classic hack: within minutes, he received responses—not only from his own device, but from thousands of other Romo robots worldwide. The servers apparently accepted his authentication token not just for a single device, but system-wide.
MQTT as the Gateway
The technical basis of the problem was the MQTT (Message Queuing Telemetry Transport) protocol. MQTT is a lightweight messaging protocol frequently used in the Internet of Things (IoT). Devices use it to exchange status messages and control commands with a so-called broker server. According to research by several specialized media outlets, the server configuration allowed so-called wildcard subscriptions. This means a client could subscribe to message streams from multiple devices. At the same time, authentication tokens were apparently not strictly bound to individual devices.
Azdoufal was not only able to control other people’s robots, but also gained:
- Access to status data such as battery level and cleaning progress
- Visibility of 2D floor plan maps of scanned apartments
- Access to live video streams from integrated cameras
- Insight into audio data via built-in microphones
- Visibility of serial numbers and IP-based location data
In a demonstration to US media, around 6,700 devices in 24 countries were reportedly accessible within minutes. More than 100,000 MQTT messages were generated in the process.
Not an Exploit, but an Architectural Problem
Proper classification is important: Azdoufal did not exploit a zero-day vulnerability in the strict sense. He did not manipulate firmware. He did not bypass encryption. He used legitimate credentials from his own device.
The problem lay in the server architecture. If a valid token is not restricted to a single device and the broker does not enforce proper access control lists (ACL), an authentication credential effectively becomes a master key.
It was therefore not a sophisticated cyberattack, but a blatant design flaw.
DJI’s Response
DJI responded after being notified and deployed server-side updates. According to the company, the central vulnerabilities were closed on February 8 and 10. Users did not need to perform a manual update, as the changes were implemented cloud-side.
According to reports, internal communication was initially contradictory. While DJI publicly stated that the vulnerability had been closed, devices could reportedly still be accessed. Whether additional security-relevant issues exist has not yet been conclusively clarified publicly.
The Structural Problem of Cloud IoT
The incident joins a long list of IoT security problems. Smart devices equipped with cameras and microphones are almost always connected to cloud infrastructures. Security therefore depends not only on hardware, but on the entire server architecture.
Many security tests focus on encryption during transmission. Less attention is paid to authorization logic and tenant separation at the server level. That is precisely where the problem lay in the Romo case.
For consumers, this means: a device may appear secure locally. However, if the cloud infrastructure is misconfigured, even strong end-to-end encryption offers little protection.
Privacy in the Living Room
A robot vacuum with a camera is not a harmless gadget. It creates apartment floor plans. It detects furniture layouts. Depending on the model, it can even transmit live images. Such devices move autonomously through private spaces. If access to them is inadequately secured, this creates a significant privacy risk.
The global dimension is particularly sensitive. Devices in Europe, the United States, and China were apparently affected. The incident therefore also touches on issues of international data transfers and regulatory oversight.
Market and Regulation
The market for smart household devices continues to grow rapidly. According to industry analyses, robot vacuums are among the fastest-growing segments in the smart home sector. Competition includes manufacturers such as Roborock, Ecovacs, and iRobot.
At the same time, regulatory requirements are increasing. In the European Union, cybersecurity rules for connected products are becoming more stringent. The Romo case shows that technical standards alone are not sufficient if implementation and configuration are flawed.
A Case Study for the “Internet of Trash”
The Romo incident is not a spectacular intelligence case. It is a case study in inadequate access control in the Internet of Things. It shows how thin the protective layer between convenience and surveillance risk can be. And it demonstrates that highly complex attacks are not always necessary. Sometimes a misconfigured server is enough. The societal relevance is clear: the more cameras and microphones move into everyday devices, the higher the requirements for transparent security architectures. Trust is not created by marketing, but by clean technical implementation.











