He Just Wanted to Play With His Robot Vacuum. Instead, He Accidentally Hacked 7,000 of Them.
A hobbyist's weekend project exposed a catastrophic authorization failure in DJI's cloud infrastructure — and his refusal to play by the rules may have been the only thing that got it fixed.
Sammy Azdoufal wasn't hunting for vulnerabilities. He wasn't running a bug bounty program, writing a research paper, or trying to embarrass a Chinese drone company. He just bought a DJI Romo — DJI's first-ever consumer robot vacuum — and thought it would be hilarious to drive it around with a PlayStation 5 gamepad.
That innocent weekend project turned into one of the most embarrassing IoT security disclosures of 2026.
Secure IoT House
The Setup: Vibe Coding Meets MQTT
To build his custom controller, Azdoufal used Anthropic's Claude Code AI assistant to reverse-engineer the DJI mobile app's communication protocols. No deep offensive security background required. No manual binary analysis. He fed the app to an AI, asked it to figure out how the thing talks to DJI's servers, and the AI obliged.
What he found underneath was an MQTT broker — a lightweight publish/subscribe messaging protocol ubiquitous in IoT devices. MQTT works by routing messages through a central server. Devices publish data to "topics," and authorized clients subscribe to receive it. The entire security model depends on one critical assumption: the broker enforces which clients can see which topics.
DJI's broker made no such enforcement.
When Azdoufal extracted his own Romo's private authentication token — the credential that tells DJI's servers "this is a legitimate user" — and connected to the MQTT broker, the server didn't limit him to his own device. It handed him everything. He subscribed to a wildcard topic (#) and the broker responded by streaming real-time telemetry from every DJI Romo on the planet.
In nine minutes, his laptop had catalogued 6,700 devices across 24 countries and collected over 100,000 messages.
What He Could See (And Do)
This wasn't passive data exposure. The access was active and deeply invasive:
- Live camera feeds from inside strangers' homes, bypassing the device's security PIN entirely
- Live microphone audio through the vacuum's onboard mic
- Real-time floor plans — accurate 2D maps of home layouts generated as the vacuums cleaned
- Cleaning routes and obstacle data — behavioral patterns revealing when residents were home, which rooms they used, and how they lived
- Serial numbers and IP addresses — enough to geolocate devices to a rough physical location
- Remote movement commands — the ability to actually drive another person's vacuum around their house
To demonstrate the severity to The Verge, Azdoufal was given just the 14-digit serial number of a journalist's review unit in a different country. From Barcelona, he identified the device, confirmed it was cleaning the living room at 80% battery, and generated an accurate floor plan of the journalist's home. He did this without any credentials beyond his own device token.
He also pulled up his own Romo's live video feed without needing its PIN, then walked into his living room and waved at the camera while the journalist watched in real time from across the internet.
The Root Cause: TLS Protects the Pipe, Not What's Inside It
DJI's initial response leaned heavily on one talking point: TLS encryption was always in place. Data was encrypted in transit.
That's technically accurate and completely beside the point.
As Azdoufal explained: "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 and see all messages from all devices in plaintext at the application layer. TLS does nothing to prevent this — it only protects the pipe, not what's inside the pipe from other authorized participants."
Security researcher Kevin Finisterre, who has been tracking DJI's security posture for nearly a decade, put it more bluntly: a US-based server location in no way prevents DJI employees in China — or anyone else who obtains a valid token — from accessing the data inside it. The geographic and legal claims about AWS storage are irrelevant when the application layer has no access controls.
This is a foundational MQTT security failure. Every MQTT deployment should implement per-client Access Control Lists that restrict which topics each authenticated client can publish to or subscribe from. Without ACLs, authentication is theater — you've verified who someone is, but you've given everyone the same keys to the same kingdom.
DJI's Response: Premature Declarations and Partial Patches
DJI's handling of the disclosure compounded the technical failure with a communications failure.
When Azdoufal and The Verge contacted the company, spokesperson Daisy Kong issued a statement declaring the vulnerability resolved. That statement was timestamped approximately 30 minutes before Azdoufal demonstrated live access to thousands of vacuums — including the journalist's own review unit — still reporting in.
The actual fix required two separate patches: an initial deployment on February 8, and a follow-up on February 10 to cover service nodes the first patch had missed. By the time DJI acknowledged the full scope of the issue, Azdoufal had already gone public.
Even after both patches, Azdoufal disclosed that additional vulnerabilities remain. One — the ability to view your own Romo's camera stream without the required security PIN — was published. A second, described by The Verge as serious enough not to detail publicly, was still unpatched as of February 17. DJI told the publication it would be addressed within weeks.
He Skipped Responsible Disclosure. He Doesn't Apologize For It.
This is where the story gets uncomfortable for the security community.
Azdoufal isn't a professional researcher. He didn't file through DJI's bug bounty program. He didn't give the company a 90-day disclosure window. He livetweeted the entire incident in real time, including demonstrations of active access, before DJI had fully remediated anything.
When asked about it, he didn't hedge: "Yes, I don't follow the rules, but people stick to the bug bounty program for money. I f***ing don't care, I just want this fixed. Following the rules to the end would probably make this breach happen for a way longer time."
He also doesn't believe DJI's claim that it identified the issue internally in late January — before his discovery. He notes that the company only ever responded to him via DM on X, never to his emails, and that its initial public statement was factually wrong about the fix status at the time it was issued.
There's a legitimate debate here. Responsible disclosure norms exist for a reason — coordinated timelines give vendors time to protect users before exploits are publicized. But those norms assume good-faith vendor engagement, accurate disclosure communication, and timely remediation. DJI failed on all three counts. Azdoufal's chaos-driven approach produced a faster fix than a formal process likely would have.
Whether that justifies the approach is a values question. The outcome is not in dispute.
The Bigger Picture: AI Just Lowered the Bar for IoT Offense
Something easy to miss in this story: Azdoufal isn't a penetration tester. He used an AI coding assistant to decompile a mobile app, understand an undocumented protocol, build a custom client, and accidentally demonstrate a fleet-level compromise. Start to finish.
The population of people capable of doing this just expanded by orders of magnitude.
Security through obscurity — the implicit assumption that IoT protocol complexity serves as a deterrent — is now even less viable than it was before. If Claude Code can extract an authentication token and build a working MQTT client in an afternoon, so can a lot of people who have never opened Burp Suite in their lives.
This matters beyond DJI. MQTT is deployed in thermostats, industrial sensors, medical devices, fleet vehicles, and building management systems. The ACL misconfiguration Azdoufal found is not exotic — it's a well-documented deployment failure that happens constantly. The only thing novel here is that an AI made finding it trivially easy.
This Is a Pattern, Not an Anomaly
DJI is not uniquely negligent. But they're also not getting a pass.
In 2024, hackers commandeered Ecovacs robot vacuums across US cities, using the devices to chase pets and broadcast slurs through their speakers. The flaw: PIN verification was enforced only by the app, never by the server or the device itself — a conceptually identical failure to what DJI shipped.
In 2025, South Korea's consumer protection agency tested six major robovac brands. Samsung and LG performed well. Three Chinese-manufactured models — including devices from Dreame, Ecovacs, and Narwal — had serious vulnerabilities allowing camera access and photo theft.
The pattern is consistent: connected cleaning devices, especially those from Chinese manufacturers, have repeatedly shipped with server-side authorization failures that treat encryption as a substitute for access control. They are not the same thing.
DJI's situation is complicated by its existing US regulatory exposure. The company is effectively banned from US government use due to national security concerns, and this incident will be weaponized in those conversations regardless of how quickly or thoroughly it patches the remaining issues.
Security researcher Kevin Finisterre — who has been publicly documenting DJI's security posture since 2017 — noted the consistency: in 2017, credentials were left exposed in public code. In 2026, homes were left exposed through a misconfigured MQTT broker. Encryption was present both times. Permission models were broken both times. Nine years of the same category of failure.
What This Means for Security Professionals
A few takeaways that apply beyond the DJI specific incident:
MQTT deployments require explicit ACL configuration. Authentication is not authorization. Every MQTT broker — Mosquitto, HiveMQ, EMQX, AWS IoT Core — supports per-client topic ACLs. If you're deploying or auditing IoT infrastructure, ACL enforcement is a non-negotiable checklist item.
TLS is table stakes, not a security posture. The number of vendors that have responded to breach disclosures by pointing to encryption in transit is remarkable. Encryption protects data from network-level interception. It does nothing to prevent authorized clients from accessing data they shouldn't see. These are separate threat models.
AI-assisted protocol analysis is now a standard offensive capability. Assessments of IoT products need to account for the reality that reverse engineering barriers are significantly lower than they were two years ago. Your obscure binary protocol is not a security control.
Microphones on vacuum cleaners are a questionable design decision. Azdoufal himself flagged this: "It's so weird to have a microphone on a freaking vacuum." When a device category that maps your home layout also has persistent audio capture capability and routes all of it through a cloud broker with inadequate access controls, the attack surface is significant. Product security reviews should question whether hardware capabilities are justified relative to the risk they introduce.
The Bottom Line
Sammy Azdoufal wanted to play a video game with his vacuum cleaner. He accidentally compromised the live camera feeds of 7,000 homes across 24 countries, did it without breaking a single law, disclosed it chaotically and without apology, and was probably right that his approach got it fixed faster than the alternative.
DJI shipped a product with a microphone, a camera, and home mapping capability, then failed to implement basic server-side access controls on the broker handling all of that data. They announced a fix before it was complete, required two patches to close the primary hole, and still have unresolved issues weeks after initial disclosure.
The regulatory and geopolitical implications will play out in policy circles. The security lesson is simpler: authentication is not authorization, TLS is not access control, and any IoT device that maps your home and listens to you deserves the same security scrutiny you'd apply to an endpoint in your corporate network.
Because that's effectively what it is.
Sources: The Verge (February 14 & 17, 2026), Malwarebytes, Android Authority, DJI official statement via spokesperson Daisy Kong. Additional context from security researcher Kevin Finisterre.
