Case Study: Root on a Robot Vacuum, and Other People’s Cameras

A robot vacuum with a camera is a moving camera inside someone’s home. We tested one: the device, its app and the cloud behind it. The manufacturer’s name does not matter here. The pattern does, because we see it again and again.

What we tested

The complete product, as an attacker would see it:

• the device itself
• the mobile app
• the cloud API the app talks to
• the MQTT channel between device and cloud
• the WebRTC video connection for the live camera

What we found

Root on the device

We gained full root access to the vacuum. With root, an attacker controls everything the device can do: drive, record, listen on the network it is connected to, and read whatever the manufacturer stored on it.

Other people’s devices through the API

The more serious findings were in the cloud. The API had the three classic authorization flaws:

Flaw	What it meant here
IDOR / BOLA	Requests for a device were answered for devices that belonged to other users
BFLA	Functions that should be restricted could be called from a normal user account
Excessive data exposure	API responses contained far more information than the app ever displayed

MQTT

The messaging channel between devices and cloud had weaknesses of its own, which widened what a single logged-in user could see and do.

The impact: a live camera in a stranger’s home

Combined, these findings gave us access to the WebRTC camera stream of other people’s vacuums. Not our test device: devices of other users. No malware, no physical access, no guessing of passwords. A normal account and the right requests were enough.

Why it happened

None of this needed advanced exploitation. The root cause was the same in every finding: the backend trusted what the client sent. It checked that a user was logged in, but not whether the device in the request belonged to that user.

This is the most common serious flaw in connected products, and it is invisible to automated scanners, because every single request looks legitimate.

What manufacturers should take from it

1. Check ownership on every request. On the server, for every device ID, every time. Not in the app.
2. Treat MQTT like an API. Every client may only publish and subscribe to its own topics.
3. Return only what is needed. If the app does not show a field, the API should not send it.
4. Assume the device will be opened. Anything stored on it, keys included, will be read.
5. Test the whole product. Device, app and cloud together. The worst findings come from combining them.

Under the Cyber Resilience Act, a product like this must not ship with known exploitable vulnerabilities, and the manufacturer has to handle and report them. A test before launch is cheaper than a recall after.

Want to know what your device gives away? See IoT security testing, web and API pentests or what a test costs.