Imagine buying a robot vacuum, pairing it with a phone, and discovering that your little cleaning bot is just one of thousands answering to the same command center. That’s what happened to Sammy Azdoufal, who says he only wanted to steer his new DJI Romo with a PS5 controller and ended up talking to an ocean of devices instead. Within minutes his tool was cataloging thousands of DJI units and logging live camera, mapping and telemetry data – a reminder that a camera and mic inside your house aren’t risk-free if the cloud side is sloppy.
Azdoufal, who leads AI strategy at a vacation rental home company, says his homebrew app started talking to DJI’s MQTT servers after he reverse engineered the Romo’s protocol with the help of Claude Code. What returned wasn’t just his unit: roughly 7,000 DJI Romo vacuums worldwide began accepting commands and publishing status updates to his laptop. In a live demo he walked me through hundreds and then thousands of bots coming online, each sending MQTT packets every three seconds containing serial numbers, which rooms they were cleaning, battery level, distance traveled and obstacle reports.
After nine minutes running his scanner, Azdoufal’s computer had cataloged 6,700 DJI devices across 24 different countries and collected over 100,000 messages. Add DJI’s Power portable power stations – which use the same backend – and he says he could see more than 10,000 devices in total. He could pull up any robot by its 14-digit serial number, view live video streams, and even reconstruct accurate 2D floor plans of homes just from the device telemetry.
To be clear: Azdoufal says he didn’t break into DJI’s servers. Instead he extracted his Romo’s private token – the credential that tells DJI the client should get access to ”its own” data – and then the company’s MQTT backend apparently accepted his client as entitled to far more than that. He told me he could hit DJI’s pre-production server and live nodes for the US, China and the EU. He also shared a limited read-only version of his app with Gonzague Dambricourt, CTO of an IT firm in France, who confirmed he could watch his Romo’s camera feed before pairing it.
At first, some of this sounded like a hallucination – too wild to be real. So I asked a Verge colleague who reviewed the Romo to pass a serial number to Azdoufal. With nothing more than that 14-digit identifier he pulled up our review unit: it reported cleaning the living room, showed 80 percent battery and generated an accurate floor plan of the house. He also demonstrated bypassing the Romo’s security PIN to view his own unit’s live feed, then waved at the camera while I watched.
DJI reacted after Azdoufal and I contacted the company. By the time we spoke, DJI had already restricted the most direct ways Azdoufal was using to control and watch other units – and by Wednesday morning his scanner no longer showed any robots, including his own. But DJI’s initial public response was premature: the company told us it had fixed the problem before Azdoufal proved otherwise to my eyes, and only later acknowledged that the first patch hadn’t been applied across all service nodes.
Security-wise, the issue boiled down to backend permission validation and MQTT topic controls. Azdoufal and independent researcher Kevin Finisterre warned that TLS – which DJI says it used for device-to-server communication – only secures the transport. As Azdoufal put it, ”once you’re an authenticated client on the MQTT broker, if there are no proper topic-level access controls (ACLs), you can subscribe to wildcard topics (e.g., #) and see all messages from all devices in plaintext at the application layer.” In short: encryption on the wire doesn’t stop an authorized participant from reading everything the broker lets them read.
DJI identified a vulnerability affecting DJI Home through internal review in late January and initiated remediation immediately. The issue was addressed through two updates, with an initial patch deployed on February 8 and a follow-up update completed on February 10. The fix was deployed automatically, and no user action is required.
The vulnerability involved a backend permission validation issue affecting MQTT-based communication between the device and the server. While this issue created a theoretical potential for unauthorized access to live video of ROMO device, our investigation confirms that actual occurrences were extremely rare. Nearly all identified activity was linked to independent security researchers testing their own devices for reporting purposes, with only a handful of potential exceptions.
The first patch addressed this vulnerability but had not been applied universally across all service nodes. The second patch re-enabled and restarted the remaining service nodes. This has now been fully resolved, and there is no evidence of broader impact. This was not a transmission encryption issue. ROMO device-to-server communication was not transmitted in cleartext and has always been encrypted using TLS. Data associated with ROMO devices, such as those in Europe, is stored on U.S.-based AWS cloud infrastructure.
DJI maintains strong standards for data privacy and security and has established processes for identifying and addressing potential vulnerabilities. The company has invested in industry-standard encryption and operates a longstanding bug bounty program. We have reviewed the findings and recommendations shared by the independent security researchers who contacted us through that program as part of our standard post-remediation process. DJI will continue to implement additional security enhancements as part of its ongoing efforts.
DJI spokesperson Daisy Kong
That statement preserves important dates: DJI says it began internal remediation in late January and rolled out an initial fix on February 8 with a follow-up on February 10. But Azdoufal says some problems remain – including the ability to view a Romo’s stream without its PIN – and he claims DJI didn’t fully fix everything before confirming resolution to journalists. He notes the company initially communicated through DMs instead of email and that he worries about insider access: the servers may be U.S.-hosted, but employees with access could still read device data.
There are precedents: Ecovacs vacuums were hijacked in 2024 to chase pets and broadcast slurs (read more), and South Korean agencies flagged a Dreame X50 Ultra flaw in 2025 that could expose camera feeds (report). Camera manufacturers have stumbled before too – see reporting on Wyze and Anker’s Eufy that raised similar privacy alarms (Wyze, Eufy, Eufy follow-up).
”This is a server-side authorization failure, not a cryptography problem,” says Dr. Lena Ortiz, senior analyst at SecureHome Labs. ”Companies can and should enforce topic-level ACLs and minimum-privilege patterns on MQTT brokers to prevent a single valid token from turning into a universal key.”
Azdoufal says he didn’t publish sensitive data or try to exploit anyone’s device for harm; he livestreamed his findings while tinkering with controller support and put the Romo gamepad code on GitHub (yamasammy/dji-romo-video-control). He also admits he ignored the usual responsible-disclosure dance – ”I fucking don’t care, I just want this fixed,” he told me – because he wanted pressure on DJI to act faster than a standard bug bounty timeline might have allowed.
Why this matters
Cloud-first device models make modern smart-home gadgets useful outside the local network, but they also concentrate risk on the server. If a backend accepts broader-than-intended subscriptions, any authenticated client could snoop on or send commands to unrelated devices. That matters more when devices have cameras and microphones. People don’t expect a vacuum to double as a potential spy.
What to watch next: will DJI harden server-side ACLs, offer a more transparent postmortem, and push a firmware or app change to enforce per-device authentication? Regulators and enterprise customers may also take renewed interest – DJI already faced U.S. restrictions tied to broader national-security concerns (background).
Takeaway
This episode is a reminder that securing smart devices requires more than TLS and a bug bounty. Companies must design backends with least-privilege access in mind and make sure patches actually reach every service node. Expect more scrutiny of IoT cloud practices, and don’t be surprised if buyers start asking whether a vacuum needs a microphone at all.
For now, DJI says it has deployed fixes and that the issue was addressed via updates on February 8 and February 10. But the fact that a researcher in Barcelona could enumerate thousands of robots and, for a time, view live feeds across regions will be a hard sell to anyone who values privacy. If history is any guide, sunlight plus clear technical fixes is the only path back to consumer trust.