Lead: In early February a Barcelona-based developer, Sammy Azdoufal, discovered that DJI’s new Romo robot vacuum family was answering commands and streaming data far beyond his own device. While attempting to control his Romo with a PS5 controller he reverse-engineered the device’s cloud protocol and, during a live demonstration, cataloged roughly 6,700 Romo units across 24 countries and collected more than 100,000 telemetry messages; including DJI Power stations, his scanner reached over 10,000 devices. DJI issued two patches — on February 8 and February 10 — and company engineers said the vulnerability was closed, but researchers warn the root access model and server-side permissions raised exposed millions of data points before the fixes landed.
Key Takeaways
- Researcher Sammy Azdoufal discovered global access while building a PS5-controller app for his DJI Romo; in nine minutes his tool cataloged about 6,700 Romo devices across 24 countries and captured over 100,000 MQTT messages.
- Including DJI Power portable stations, Azdoufal’s scanner reached more than 10,000 devices that phoned home to the same MQTT infrastructure.
- Azdoufal says he obtained his device’s private token and used it to subscribe to MQTT topics; absent strict topic-level ACLs, he could see other devices’ telemetry and in some cases live video streams.
- DJI deployed two backend updates — an initial patch on February 8 and a follow-up on February 10 — and said the issue was resolved; the company also stated ROMO device-to-server traffic uses TLS encryption.
- Security experts caution TLS protects transport but not improper server-side permissions; researchers say weak access controls can let an authenticated client subscribe to wildcard topics and read messages from all devices.
- DJI told reporters most activity appeared linked to independent researchers testing their own units; the company said confirmed live-video exposures were extremely rare.
- Past smart-home incidents (Ecovacs 2024, Dreame reports in 2025) show robovacs and IoT devices remain a recurring privacy risk when cloud permissions are lax.
Background
Robot vacuums increasingly rely on cloud services to offer remote control, mapping and live video — features many buyers expect. To provide out-of-home control, devices relay telemetry and camera streams through vendor-managed MQTT brokers or similar message systems, which centralize device data but also concentrate risk. Vendors often ship devices with convenience-first authentication and rely on TLS for transport security; when server-side topic access controls are incomplete, authorized clients can overreach.
DJI, best known for drones, has been under regulatory and public scrutiny for years over data and export concerns, and the company’s move into home robotics has raised fresh questions about cloud trust and regional data handling. Independent researchers and national agencies have flagged prior robovac flaws: public incidents include Ecovacs units hijacked in 2024 and South Korean reports in 2025 about camera-exposure bugs in Dreame and other brands. Those precedents shape expectations for disclosure, bug bounties and vendor transparency.
Main Event
Azdoufal set out to make a simple remote-control app for his Romo using a PS5 gamepad. While reverse-engineering the Romo protocol with the assistance of an AI-assisted coding tool, he extracted the device’s private token — a credential the server treats as proof the requester owns that device. When he pointed his scanner at DJI’s MQTT endpoints, thousands of devices began replying. Each device reported serial number, room names, battery percentage, travel distance, obstacle encounters and status updates every three seconds.
During a live demo Azdoufal showed the author’s review unit appear live in his scanner after providing its 14-digit serial; the tool accurately reported that the robot was cleaning the living room with roughly 80% battery and then produced a 2D floorplan generated from the robot’s mapping messages. He also says he was able to pull up his own Romo’s live camera stream without entering its local security PIN before DJI restricted that access; he demonstrated the bypass with a friend who confirmed viewing and listening to a live feed.
DJI responded that it first identified the issue internally in late January and began remediation immediately. The company says it deployed an initial patch on February 8 and completed a follow-up update on February 10, re-enabling and restarting remaining service nodes. DJI characterized the root cause as a backend permission-validation issue with MQTT-based communication and asserted that device-to-server traffic was encrypted with TLS and that data for European devices was hosted on U.S.-based AWS infrastructure.
Analysis & Implications
Technically, the incident highlights a common misconception: TLS secures the channel between client and server but does not prevent an authorized participant on the broker from subscribing to wide swaths of topics if topic-level access controls are permissive. Azdoufal and other researchers note that once a client is authenticated to an MQTT broker, lack of strict ACLs can permit wildcard subscriptions (for example, ‘#’) and expose messages from unrelated devices at the application layer.
From a privacy and policy standpoint, the case reopens questions about centralized telemetry and who can access it. Even when cloud hosts are regionally located, vendor employees or compromised accounts with server-side access may read device data. DJI’s statement that European device data resides on U.S. AWS does not, by itself, mitigate concerns about insider access or cross-border data flows.
Operationally, the episode underscores the importance of layered defenses: token protection, per-device or per-account topic ACLs, end-to-end encryption of sensitive payloads, strict logging and rapid, transparent disclosure. For consumers, the event will likely reduce trust in always-on camera- or microphone-equipped appliances, and for regulators it may justify closer oversight of IoT data practices.
Comparison & Data
| Metric | Observed value |
|---|---|
| Romo devices discovered (demo) | ~6,700 |
| Telemetry messages collected | >100,000 |
| Countries with observed devices | 24 |
| Total devices including power stations | >10,000 |
| Initial patch deployed | February 8 |
| Follow-up update completed | February 10 |
These figures place the Romo event alongside several recent IoT privacy incidents: Ecovacs hijacks in 2024 and South Korean disclosures about Dreame and other vacuums in 2025. The scale here — thousands of devices replying to a single researcher’s scanner within minutes — is notable because it reflects systemic permissioning weaknesses rather than an isolated misconfiguration on a single device.
Reactions & Quotes
After Azdoufal shared his findings with reporters and DJI, the company updated its public statement and said it had identified a backend permission validation issue and rolled out two patches. DJI also asserted that nearly all flagged activity came from independent researchers testing their own units.
“I didn’t infringe any rules, I didn’t bypass, I didn’t crack, brute force, whatever,”
Sammy Azdoufal, developer and researcher
Context: Azdoufal emphasizes he used his own device token and did not claim to have breached DJI servers; he says his goal was practical (gamepad control) and that he publicized the problem after rapid testing and contact attempts. He also told reporters he withheld description of one particularly serious flaw until DJI had time to patch it.
“The vulnerability involved a backend permission validation issue affecting MQTT-based communication… The issue was addressed through two updates,”
DJI spokesperson statement (company)
Context: DJI framed the incident as a server-side permission bug and provided a remediation timeline: internal discovery in late January, followed by patches on February 8 and February 10. The company maintained that device traffic uses TLS and said confirmed live-video access was extremely rare.
“A server being based in the US in no way, shape, or form prevents .cn DJI employees from access,”
Kevin Finisterre, independent security researcher
Context: Finisterre and others stressed that geographic hosting alone does not prevent vendor-side or insider access; the larger control question centers on who has rights to read device payloads on the server and how tightly those rights are scoped.
Unconfirmed
- Whether any malicious third parties (beyond independent researchers) exploited the Romo server permissions before DJI’s February 8–10 patches is not publicly confirmed.
- Claims by Azdoufal that additional, undisclosed vulnerabilities exist have not been independently verified and were withheld from public disclosure pending remediation.
Bottom Line
The Romo episode is a concrete reminder that convenience-focused cloud models can leak far more context about home life than users expect if server-side permissions are permissive. Even with TLS in place, poor ACLs and overbroad topic naming can expose telemetry and camera streams to other authenticated clients. Vendors must treat server permissions as a first-class security control and assume that credential theft or misconfiguration will occur.
For consumers: apply updates immediately when vendors issue patches, remove or disable microphones/cameras if unwanted, and consider network segmentation for IoT devices. For policymakers and enterprise buyers: require demonstrable server-side access controls, third-party audits, and transparent disclosure timelines that differentiate researcher activity from confirmed exploitation.