A security researcher says SharkNinja has left a cloud authorization flaw open that lets a certificate taken from one Shark robot vacuum send root-level commands to other Shark vacuums in the same Amazon Web Services region.
The researcher, who publishes as tokay0, published the technique Monday and said he reported it to SharkNinja on March 1. According to tokay0, the issue can expose live camera video, saved home maps and Wi-Fi credentials stored in plaintext on affected devices.
The bug sits in SharkNinja’s AWS IoT setup, according to tokay0, not in a piece of firmware that customers can patch themselves. The client certificate used by a Shark vacuum to log in to Amazon’s cloud broker was not limited to that one robot. A certificate extracted from one device can, in the same AWS region, subscribe to broader device traffic and publish messages aimed at other vacuums.
The ugly part is what the robots do with those messages. tokay0 says Shark vacuums receive commands through an Exec_Command field in a per-device state document kept in AWS. A management process on the robot then hands command content under 1,000 bytes to a shell. That turns an overbroad cloud permission into remote command execution, which is a grimly efficient way to make a vacuum cleaner act like a compromised Linux box with wheels.
tokay0 said he tested only hardware he owned. His tests included using one model to obtain a reverse shell on an AV1102ARUS Shark IQ Robot Vacuum XL, then pulling a live camera feed from that robot.
He also monitored one AWS region for 24 hours and counted 1,517,605 distinct Shark serial numbers. Of those, 673,816, or 44%, responded to a command probe, according to his write-up. Those figures describe observed responses, not devices he claims to have taken over. The certificates are region-bound, so a certificate from one AWS region does not provide access to Shark devices in another region.
tokay0 said SharkNinja acknowledged his report on March 12, said on April 27 that it was under review, and on July 3 promised a completion date by July 10. He said that date passed without the promised update. He also said SharkNinja questioned the severity and whether the issue needed a CVE, despite the company’s published disclosure policy saying it will provide regular updates until a reported vulnerability is resolved. SharkNinja had not posted a public notice about the flaw as of July 16, according to tokay0.
The fix described by tokay0 is not exotic. Amazon’s IoT guidance says an overbroad policy can be replaced inside the operator’s AWS account with one that scopes each certificate to the intended device. SharkNinja could also reissue certificates. Either way, the work is on SharkNinja’s side of the cloud.
The disclosure follows a similar robot vacuum security failure involving DJI Romo vacuums reported in February, where an authorization flaw exposed about 6,700 devices, including camera feeds, audio and floor plans. DJI patched that issue within weeks, and the researcher later received a $30,000 bounty, according to prior reporting cited by tokay0’s disclosure context.
For Shark owners, the uncomfortable fact is that a robot vacuum with a camera, maps and Wi-Fi credentials is only as private as the vendor’s cloud permissions. In this case, tokay0 says the lock is still too broad.
This story draws on original reporting from Tom's Hardware.
