A few weeks ago, a story broke that caught our attention: a security researcher accidentally discovered that DJI’s brand-new Romo robot vacuum was leaking live video, audio, and floor maps from thousands of devices worldwide. The root cause? A missing access control configuration on DJI’s cloud infrastructure.
Since we build IoT software for device manufacturers, this is exactly the kind of incident we think about constantly. Let’s break down what happened, why it happened and what it means for anyone building connected products.
The discovery
Sammy Azdoufal, a software engineer based in Spain, bought a DJI Romo shortly after its European launch. His goal was simple: build a custom app to drive the vacuum with a PlayStation 5 gamepad. To do that, he needed to understand how the device talks to DJI’s servers.
Using an AI coding assistant 1, he reverse-engineered the DJI mobile app, identified the communication protocol (MQTT) and extracted his own device’s authentication token. When he connected his custom client to DJI’s backend, however, he discovered he could read data from roughly 7,000 other devices across 24 countries.
The data accessible through this vulnerability included:
- Live camera video feeds from active Romo units
- Microphone audio from active units
- Real-time 2D floor maps of homes being cleaned
- Cleaning routes revealing room layouts and occupancy patterns
- Device serial numbers, battery levels, and other telemetry
- Approximate device locations via IP address geolocation
On top of the fleet-wide access issue, the camera feed could also be accessed without the device’s security PIN — a separate authorization bypass.
What went wrong: missing MQTT ACLs
The DJI Romo uses MQTT for real-time communication between devices and DJI’s cloud. MQTT is a publish/subscribe protocol common in IoT: devices publish messages to named topics, clients subscribe to topics, and a central broker routes traffic between them.
Besides using channel encryption (MQTTs), security in MQTT depends on the broker enforcing access control lists (ACLs) — rules that define which authenticated clients can subscribe to which topics.
Without ACLs, any authenticated client can subscribe to any topic, including those belonging to other users: this is an example of what happens when the system handles authentication but forgets authorization.
DJI’s broker had no per-topic ACLs. When Azdoufal authenticated with his own token and subscribed to a wildcard topic (#), the broker returned everything. The exploit chain was remarkably simple:
- Authenticate to DJI’s MQTT broker using your own device token
- Subscribe to the wildcard topic:
#- Receive real-time data from every device on the network
No additional credentials, no firmware exploits, no sophisticated attack.
Authentication vs. authorization
This is the critical distinction at the heart of the vulnerability. DJI’s system correctly authenticated the client (confirmed it was a legitimate user), but failed to authorize it (verify that the user was allowed to access the specific data being requested).
The vulnerability is classified as a Broken Object Level Authorization (BOLA) issue, also known as Insecure Direct Object Reference (IDOR) in the OWASP taxonomy.
DJI emphasized that all communications were TLS-encrypted, and that’s true — but it’s irrelevant here! TLS protects data in transit from third-party interception. It does nothing to restrict what an authenticated client can request once it’s connected.
Think of it this way: encrypting the connection is like locking the front door of a building, but once you’re inside, every apartment door is wide open.
A cloud-side failure, not a device issue
An important detail: this was entirely a server-side problem. The fix required no firmware update to any Romo device. DJI deployed two server-side patches to enforce topic-level isolation per authenticated user.
The broader infrastructure was also affected: DJI’s Power portable battery stations, which share the same MQTT broker, were exposed alongside the vacuum data.
Why this keeps happening
This isn’t an isolated incident in the robot vacuum space. Similar authorization failures have been documented in Ecovacs devices in 2024 and multiple other brands in 2025. The pattern is always the same: access control is implemented in the client application (the official app correctly shows you only your device’s data) but is not enforced at the server level.
It’s architecturally equivalent to a database that enforces row-level access in the application layer but allows any authenticated user to run arbitrary queries directly. The app presents the right data; the infrastructure doesn’t restrict it.
What this means for device manufacturers
If you’re building connected products, this incident reinforces a few principles that should be non-negotiable:
Enforce authorization at the server level. Client-side restrictions are a UX feature, not a security boundary. Your broker, API gateway, or backend must independently verify that every request is scoped to the authenticated user’s resources.
Scope authentication tokens to specific devices. A token issued for Device A should never grant access to Device B’s data. Tokens should carry claims that bind them to specific resources, and the server should validate those claims on every request.
Treat MQTT ACLs as critical infrastructure. If you’re using MQTT, topic-level ACLs are not optional. A wildcard subscription (#) from any single client should never return cross-user data.
Never rely on protocol obscurity. The barrier to reverse-engineering proprietary protocols has dropped dramatically. AI-assisted tools mean that a motivated user with no prior knowledge of your protocol can understand it in hours, not weeks.
How we approach this at Connhex
We don’t want to bring this up to point fingers: building secure IoT infrastructure at scale is genuinely hard and DJI is far from the only company to have stumbled on authorization. But this incident is a good opportunity to explain how Connhex is designed to prevent exactly this class of vulnerability.
The core idea is simple: in Connhex, every device can only communicate on its own channels. Each device has two dedicated MQTT topics:
- one for events (device-to-cloud)
- one for control (cloud-to-device)
The broker strictly enforces this boundary: there is no wildcard access, no fleet-wide subscriptions, no way for one device’s credentials to reach another device’s data.
To connect to the broker at all, a device needs three things: a unique device ID, a secret key, and a valid certificate. All three are verified before any message is exchanged. This approach is replicated across Connhex’s services: for example, the identity and access management layer treats authentication and authorization as inseparable.
If you’re curious about the details, our documentation on sending MQTT messages walks through the exact topic structure and credential requirements.
We’ve designed Connhex this way because we believe these guarantees should come from the platform, not from the discipline of individual engineering teams. When the platform enforces isolation by default, the DJI Romo scenario — where a single missing configuration exposes an entire fleet — simply can’t happen.
That said, no system is immune to every possible vulnerability. What matters is building layers of defense so that a single oversight doesn’t cascade into a fleet-wide exposure.
If you’re building connected products and want to talk about how to approach this, feel free to reach out: we’re always happy to talk!
This analysis is based on reporting from The Verge, Popular Science, Malwarebytes, and DJI’s official statements. We don’t have any internal knowledge on DJI’s systems.
- Claude Code↩