www.it-connect.fr
Shark Robot Vacuums: One Certificate Is Enough to Spy on Neighbors’ Devices
673,816 Shark vacuums responding to a command sent with a single certificate, in 24 hours, in a single AWS region. A researcher claims he can take over other people’s Shark robots: camera, remote control, apartment map, and plaintext Wi-Fi password. Four months after reporting it to SharkNinja, there is still no fix and no CVE.
According to a report published by a researcher nicknamed tokay0, there appears to be a major security issue affecting Shark robot vacuums. 2026. He claims that if you exfiltrate the certificate stored in the flash memory of a vulnerable Shark vacuum, you can then execute commands as root on other Shark vacuums in the same AWS region. He says he tested his attack only on devices he bought himself, and notified the Shark and Ninja brands back in March. To no avail.
One certificate, and the entire robot vacuum fleet is within reach
No memory corruption, no privilege escalation, no password to guess. Here, the problem is the AWS IoT policy attached to the certificate used by the robot vacuums. In fact, it is never limited to the device that holds it. In practice, this certificate would be accepted regardless of the target, and the command to be executed would just be a field (Exec_Command) associated with the device state on AWS. On the robot, the appd daemon would read this field and pass it to an execute_command function, which would execute any content under 1,000 bytes. This then makes it possible to remotely control vulnerable robots.
Apparently, nothing is being done to prevent tampering, since physical access is enough to retrieve the famous certificate. But still, if it is your robot, that is easy. The researcher explains that the operation is made easier for several reasons:
- The motherboard exposes UART pins.
- The
U-Bootconsole would not require any password. - The
init=/bin/shboot argument would open a root shell. - The certificate and its key are lying around in
/mnt/res/vapp/certs/, as plain files.
Even so, a quick look at the image below is enough to understand that this is not within everyone’s reach either.
Then, any vacuum that executes the Exec_Command field becomes a potential target, regardless of the certificate it holds. Researcher tokay0 claims he obtained a reverse shell on an AV1102ARUS model purchased solely to use as a target, then retrieved its camera stream while the robot was moving around. The only real limitation would be geographical, since the certificates are tied to their AWS region.
A major security problem, and yet AWS flags it. Indeed, the AWS Device Defender service, through the IOT_POLICY_OVERLY_PERMISSIVE_CHECK control classified as critical, flags policies that grant excessive permissions. Which is the case here, and the AWS documentation states: a compromised certificate associated with such a policy allows an attacker "to read or modify the shadows, jobs, or job executions of all your devices".
It is hard to know how many devices are actually vulnerable, especially since there is segmentation by AWS region. The title of the report published by tokay0 mentions millions of devices, and by observing a single AWS region for 24 hours, he says he counted 1,517,605 unique serial numbers. Among them, 673,816 (44%) robot vacuums emitted an Exec_Response, which indicates that the command handler is indeed running.
How can you protect yourself from this vulnerability?
First, let’s put things into context: the researcher contacted Shark 4 months ago, and as of now, the security issue is still present. Indeed, here is the timeline of events:
- March 1: initial contact with SharkNinja, technical details sent on March 11 and acknowledgment received on March 12.
- April 25: follow-up. On the 27th, SharkNinja responds that the report is under review.
- June 7: another follow-up. On the 9th, the 90-day responsible disclosure window expires.
- June 11: a
CANis reserved with MITRE, via the last resort assigner (CNA-LR), in an attempt to obtain a CVE. - June 28: the researcher warns SharkNinja that he plans to disclose the flaw.
- July 3: SharkNinja says it will be finalized by Friday, July 10.
- July 10: no email.
- July 13: tokay0 publishes the report.
The researcher says the manufacturer downplayed the severity and questioned whether assigning a CVE was even appropriate. To date, this flaw has no identifier, no CVSS score, and not the slightest official statement from the brand.
If you have a Shark robot vacuum, there is nothing you need to do. The fix must be implemented by Shark’s technical teams within the AWS environment, not in the robot’s firmware. If it takes this long, it may be because Shark also wants to issue new certificates across all devices: a major undertaking that appears to be taking time.
In the meantime, you only have one possible option to protect your robot (if you set aside getting rid of it): cut off the vacuum’s Wi-Fi so it can no longer connect to the Internet. But then there is no app, no scheduling, and not even access to your apartment maps anymore — just a plain old vacuum again.
