A robot vacuum is easy to laugh off. It is also a networked computer with a camera, microphones, and a saved map of the inside of your home, and it sits on your wifi. So when the cloud that drives a whole fleet of them turns out to trust the wrong thing, that is worth taking seriously.

Over April 2026 I looked at the Ecovacs DEEBOT line and the cloud platform behind it, on my own devices and my own account. I found five issues. One of them, on its own, lets anyone with a valid Ecovacs login reach root on any DEEBOT in the global fleet. DEF CON Toronto coordinated the disclosure with Ecovacs, and these are the public advisories.

The one that matters: a broken tenancy boundary

Ecovacs devices talk to the cloud over MQTT, a lightweight message bus. Commands, including a remote shell command, travel on a topic tree. The broker is supposed to make sure you can only talk to your own device. It does not. The broker never ties the account you logged in with to the device you are addressing, so a command aimed at someone else’s robot is delivered anyway, and the robot runs it as root.

That is the whole game. One valid account, a command pointed at any other device, root on that device. No second bug needed to cross from one customer to another. Root on the robot reaches the home network it lives on, and the camera, microphones, and map it carries.

Everything you need to aim it

Three more findings make that reach practical. A misconfigured access rule on the same message bus hands any logged-in client the configuration pushes for the entire fleet, which is a ready-made list of device identifiers to point at. On the web side, three endpoints answer slightly differently depending on whether an account or a device exists and whether it is online. Individually they look minor. Together they are a quiet way to enumerate accounts and confirm live targets before you do anything loud.

That is the pattern worth remembering: the critical bug is an authorization failure, and the “low-severity” information leaks are what turn it from a lab trick into something you could actually aim.

What it means if you own one

There is nothing a device owner can change here. Every one of these lives in Ecovacs’ cloud, not on the device, so the fix has to come from the vendor. The single highest-value change is broker-side: bind every published command to the account that sent it. The device should also refuse to run anything that is not signed, so a broker slip does not become root a second time.

How we handled it

This went through coordinated disclosure, not a surprise drop. Ecovacs was contacted on April 20, signed a safe-harbour agreement, and received the full technical report. The 90-day embargo ran from their confirmation of receipt and expired on August 27. We are publishing after that window.

CVE identifiers have been requested for the five issues through MITRE’s CNA of Last Resort and are pending assignment; each advisory will be updated with its CVE ID as it lands. We are not releasing exploit code. The advisories describe the root cause and impact, which is the level a defender needs, and hold back a copy-paste weapon while fixes reach a fleet that does not update quickly.

DC416 coordinates disclosures like this one as a community: a member does the research, we handle the vendor process and the CVE paperwork, and the result lives in a public archive anyone can cite. That archive is the point. It is how a small group builds the track record to eventually assign CVE identifiers itself.

The advisories

Full index at defcontoronto.ca/advisories. Research and disclosure by Amir Hosseinpour, coordinated by DEF CON Toronto under our vulnerability disclosure policy.