The Robot Vacuum That Should Have Stayed Offline

It’s Friday, and instead of my usual regulatory/legal analysis, I thought some Hollywood stunt hacking might be a nice change of pace. For example, a device designed to clean your floors can drive through your bedroom at 3am while streaming live video to a stranger. Researcher tokay0 published a full writeup on July 16, 2026 documenting remote code execution in Shark robot vacuums affecting hundreds of thousands of devices (full post, archived copy). This isn’t the first time that I’ve covered IoT; back in 2019 the IEEE had me on talking about the risks of IoT cameras, and not much has changed since other than my fashion style.

Me in 2019 complaining about IoT risks in front of a live audience.

Shark vacuums authenticate to AWS IoT Core using device certificates. In theory, each certificate should scope a device to its own MQTT topic. In practice, Shark’s cloud permissions let one certificate subscribe to every device’s topic in the same AWS region and publish commands to those devices. However, only certificates carrying the broken (older) policy can wildcard-subscribe and act as a “skeleton key” in this scenario. This means that an attacker needs physical access to a single older vacuum to extract its certificate from flash storage – and extraction needs only a screwdriver and a UART connection, not specialized lab equipment. After that, the entire attack is remote. Send an Exec_Command payload to any victim’s serial number, and the vacuum’s appd daemon passes the string to popen() and runs anything under 1,000 bytes with no sanitization and no authentication between the cloud message and execution.

Tokay0 confirmed 673,816 devices in a single AWS region responded to Exec_Response in a way indicating they run the vulnerable command handler. These are devices the researcher saw replying, not devices they tested or compromised. That figure represents about 44% of 1.5 million tracked devices in that region over a twenty-four hour period, so the actual number is probably higher. Tokay0 linked the Shark vulnerability to a similar flaw in DJI ROMO vacuums disclosed earlier in 2026 (over-permissive cloud/MQTT authorization). However, in that case, it was only 6,700 – 7,000 devices across 24 countries, and DJI patched within weeks, and later paid a $30,000 bounty to the researcher.

Most of the tech coverage is focusing on the Wi-Fi passwords Shark leaves in plaintext, and floor plan maps the device stores locally. A few privacy advocates have talked about the risks of behavioral data collection and occupancy pattern profiling.

But both angles undersell the problem. These devices have cameras on them. They move through rooms where you expect privacy, operating at floor level during cleaning cycles when you may be undressed or having a conversation you consider private. The privacy of your home stops being a thing when a motorized appliance with a live camera and microphone can drive through it on command.

High-value targets like politicians and executives deal with adversaries who have resources and patience. Linking a serial number to a specific person would take some effort, like reviewing purchase records or physical proximity to read a device label. However, in this case, one certificate opens a large fleet of cameras at once. An implant on a rooted device survives reboots, so the vacuum cleans the floor while the implant captures audio and video. In theory, a sophisticated APT group could easily assign an intern to review the footage and identify high-value targets. And they wouldn’t notice until the extortion attempt arrives.

Microphones add a second layer of exposure. Models with voice assistant features ship with them installed. Tokay0 tested camera extraction and command execution, but pulling audio from a rooted Linux device is routine work. The ALSA audio pipeline sits in the filesystem, accessible to anyone with root access.

SharkNinja has known about this since March 2026. The fix is server-side: update AWS IoT policies, re-provision certificates at scale. Months passed. Tokay0 noted that SharkNinja questioned whether a CVE is “appropriate” for remote code execution on a camera-equipped device in someone’s bedroom.

This pattern has been repeating across the IoT industry for as long as we have had IoT devices. The Ecovacs Deebot X2 suffered remote camera and microphone activation in 2024. DJI ROMO carried the same class of flaw. Smart TVs and baby monitors have accumulated years of equivalent vulnerabilities, not to mention that most of them are parts of botnets. Manufacturers ship faster than they secure, and consumers who bought an appliance to clean floors suffer the damage.

• Disconnect anything from the internet that doesn’t require a connection
• If your vacuum works offline, disable remote access in the app and accept that app control, scheduling, and maps might stop working
• Turn off cameras and microphones you aren’t using
• Place IoT or “smart” devices on a separate VLAN

SharkNinja hasn’t patched this. Until they do, treat your connected Shark vacuum as a surveillance device that’s already been compromised.