DJI ROMO Security Breach: Researcher Remotely Accessed 7,000 Home Cameras — And One Hole Remains

Sammy Azdoufal wanted to drive his new DJI ROMO robot vacuum with a PS5 controller. Just for fun. So he used Claude Code to reverse-engineer the DJI app’s communication protocols, built a custom client, and connected it to DJI’s servers. What came back wasn’t just his vacuum. Roughly 7,000 ROMO units across 24 countries started responding to him as their operator — live camera feeds, microphone access, real-time floor plans of strangers’ homes.

He didn’t hack anything. He used his own device token. The server handed him everyone else’s homes for free.

• The vulnerability: DJI’s MQTT message broker — which handles real-time communication between ROMO devices and DJI’s cloud — had no topic-level access controls. Any authenticated client could subscribe to wildcard topics and read traffic from every device on the network.
• What was exposed: Live camera feeds, microphone audio, cleaning routes, serial numbers, and detailed 2D floor plans of homes. DJI Power portable battery stations — marketed for home backup power — ran on the same infrastructure and showed up too.
• The fix: Two automatic patches — February 8 and February 10 — addressed the wildcard access issue. No user action required. But at least one vulnerability remains unpatched as of today, February 17.
• Source: The Verge, February 14, 2026 and February 17, 2026.

The Technical Failure Was Basic

MQTT is a standard protocol for connected devices — lightweight, efficient, widely used in IoT products. It works by routing messages through a central broker. Devices publish to topics; subscribers receive those messages. The security model depends entirely on the broker enforcing which clients can subscribe to which topics. Without access control lists, a single authenticated client can subscribe to everything.

That’s what happened here. Azdoufal extracted his own vacuum’s authentication token — the key that tells DJI’s servers “this user has access to their device” — connected to the MQTT broker, and the broker showed him all devices. In nine minutes, his scanner collected over 100,000 messages. He could locate a specific vacuum by serial number, confirm it was cleaning at 80% battery, and generate an accurate floor plan of that home — all from Barcelona.

DJI’s official statement said TLS encryption was always in place. That’s true and beside the point. TLS protects data moving between the device and the server. Once you’re an authenticated client on the broker with no ACL enforcement, the encryption doesn’t matter — you’re already inside reading everything in plaintext at the application layer.

DJI says the fix was already underway before Azdoufal went public. That may be accurate — the company says it identified the issue internally in late January. But according to The Verge’s reporting, DJI spokesperson Daisy Kong told the publication the vulnerability had been fixed shortly before Azdoufal demonstrated that thousands of vacuums, including the journalist’s own review unit, were still reporting in live. The first patch had not been applied across all service nodes. I’ve seen DJI walk this exact line before — announcing a fix while the exposure is still active. It happened in 2017 too.

One Hole Remains Open

Azdoufal told The Verge he found at least two additional vulnerabilities beyond what the February patches addressed. One — a PIN bypass that lets you view your own ROMO camera stream without the security code — was disclosed publicly. The second is serious enough that The Verge agreed not to describe it while DJI works on a fix.

DJI says it will address the remaining issue within weeks. For a device with a camera and a microphone that autonomously maps the inside of your home, “within weeks” is not a tight window.

The Regulatory Timing Is Terrible For DJI

As we reported in our December coverage of the automatic FCC ban deadline, DJI was added to the FCC Covered List on December 22, 2025, following a classified Executive Branch interagency determination that foreign-made drones posed “unacceptable risks to national security.” DJI argued no transparent, evidence-based security audit was ever conducted, and that the company was never given the opportunity to rebut specific findings — a process it had publicly requested from five federal agencies for months.

DJI’s defense has always been: look at the audits. Booz Allen Hamilton. FTI Consulting. TÜV SÜD. Every independent assessment of DJI drone hardware found no unexpected data transmission, no backdoors, no evidence of exfiltration to China. That argument is legitimate and well-documented. But the ROMO breach isn’t about drone hardware. It’s about whether DJI’s server infrastructure can be trusted with cameras inside people’s homes.

When we covered the ROMO’s European launch in October 2025, we noted that the device stored room maps locally rather than in the cloud — a privacy architecture we characterized as “privacy by design” and a likely response to years of data security scrutiny. That local storage was a real protection. But the live camera feed accessible through a misconfigured MQTT broker is a separate problem entirely, and local map storage does nothing to address it. I remember thinking at the time that DJI had clearly put thought into the on-device data question. The server access question, apparently, was a different story.

The breach happened on a robot vacuum. In Washington, it will be discussed as a DJI security failure. Senator Rick Scott, who has pushed to retroactively revoke all DJI FCC authorizations issued after December 23, 2024, doesn’t need to understand MQTT access control lists to use this story effectively in a hearing. Neither does anyone else who has spent three years arguing DJI products shouldn’t be in American homes.

DroneXL’s Take

I covered Kevin Finisterre’s battle with DJI back in 2017, when I was still running DroneDJ. He found DJI developers had left AWS private keys in public GitHub repositories. With those keys, he accessed customer flight logs, passport scans, driver’s licenses, and government IDs. He reported it responsibly. DJI promised him a $30,000 bug bounty, then handed him a contract lawyers called unsignable, then threatened him with the Computer Fraud and Abuse Act, then called him a “hacker” in press statements.

The mechanism is different in 2026. But the core failure is identical: server-side access controls treated as an afterthought. In 2017, customer data was exposed because credentials were left in public code. In 2026, home cameras were exposed because the MQTT broker had no ACLs. Encryption was fine both times. The permission model was broken both times.

Finisterre is actually quoted in The Verge’s coverage of the ROMO breach — nine years later, same company, same category of problem. That detail should embarrass DJI more than the breach itself.

What matters now is whether DJI handles this differently than it handled 2017. Patching fast, publishing a real technical postmortem, treating Azdoufal as the partner he was rather than a liability — that’s the path that limits the damage. The remaining unpatched vulnerability is the test. “Within weeks” needs to mean days.

My prediction: DJI fixes it within the window and survives this news cycle. But expect this footage — a researcher in Barcelona remotely driving strangers’ vacuums and watching their living rooms live — to show up in congressional testimony before summer 2026. Kevin Finisterre will probably be in that room too.

Editorial Note: AI tools were used to assist with research and archive retrieval for this article. All reporting, analysis, and editorial perspectives are by Haye Kesteloo.