Pull the certificate off the flash of a Shark RV2320EDUS robot vacuum, and you can run root commands on other people's Shark vacuums across the same AWS region: watch the camera, drive the robot, read the map of the house, and take the Wi-Fi password in plaintext.
A researcher publishing under the handle tokay0 put the method online on Monday, having tested it only against vacuums he bought himself. The flaw was unpatched then.
He says SharkNinja, the company behind the Shark and Ninja appliance brands, has had his report since March.
The policy attached to that certificate was never scoped to the device holding it. Present it to Shark's cloud broker, and the broker accepts whatever you publish, addressed to any device it serves.
No memory corruption, no privilege escalation, no password to guess. The command that runs is an ordinary field in the device shadow, the per-device state document AWS keeps in the cloud.
Using the certificate from an RV2320EDUS, the researcher subscribed to $aws/things/# and watched the traffic crossing the broker, harvesting serial numbers as he went. Publishing works the same way. The shadow carries an Exec_Command field that the management daemon appd reads and hands to a function named execute_command, which runs anything under 1,000 bytes through popen.
Send a shadow update carrying that field to a device's topic. If that device implements the handler, it runs the command.
He proved the cross-model path, landing a reverse shell on an AV1102ARUS he bought purely as a target, then using that shell to pull a live feed off the model's onboard camera while the robot drove around.
The certificate comes off with a screwdriver. The mainboard exposes UART pins, the U-Boot console asks for no password, and init=/bin/sh in the boot arguments drops you to a root shell, where the per-device key and certificate sit in /mnt/res/vapp/certs/ as ordinary files.
Certificates are pinned to their AWS region, the closest thing here to a limit: a key lifted in one region only reaches that region's devices. Reaching another region takes another certificate, provisioned there, and carrying the same broken policy.
Amazon has an audit check for this exact policy shape. Device Defender, AWS's IoT fleet auditing service, flags device policies granting publish or subscribe on $aws/things/* instead of pinning the topic to the connecting device with ${iot:Connection.Thing.ThingName}.
It appears as IOT_POLICY_OVERLY_PERMISSIVE_CHECK, and AWS rates it critical, warning in its documentation that a compromised certificate carrying such a policy lets an attacker "read or modify shadows, jobs, or job executions for all your devices."
Not every certificate is a skeleton key. A vacuum whose certificate carries the broken policy is an attacker's key. Any vacuum that runs Exec_Command is a target, whether or not its own certificate is scoped correctly. The AV1102ARUS is a target and not a key: its certificate was scoped correctly and could not wildcard-subscribe. Its firmware was several years newer.
He reads that as a provisioning fix that never reached the older fleet's certificates. That is why the cross-model shell worked, and why his claim that every internet-connected Shark vacuum is vulnerable needs splitting in two.
The headline on his post says millions. The figure he verified is narrower. Watching one AWS region for 24 hours, tokay0 counted 1,517,605 unique Shark serial numbers, of which 673,816, or 44%, emitted an Exec_Response, which he treats as confirmation that the device runs the command handler. Those are devices observed replying, not devices tested or compromised, and he says the true number is likely higher.
Four Months and Counting
By tokay0's account of the correspondence, he contacted SharkNinja on March 1 and sent details on March 11. The company acknowledged receipt the next day, told him on April 27 that the report was under review, and on July 3 said it would send a confirmed completion date by Friday, July 10. No email arrived.
He published on July 13. He says the vendor downplayed the severity and questioned whether "a CVE is appropriate."
On IoT reports specifically, SharkNinja's published vulnerability disclosure policy commits the company to "provide regular updates until the reported vulnerability is resolved." The same policy asks researchers to stay quiet until the company confirms a fix or authorizes disclosure in writing.
SharkNinja had published nothing on the flaw as of Thursday. The Hacker News has reached out to the company for comment on the patch status and the disclosure timeline, and will update this story with any response.
There is also no CVE. He asked MITRE's CNA of last resort, the assigner that handles vulnerabilities no vendor CNA covers, for an ID on June 11 and had heard nothing by the time he published. No identifier, no CVSS, no advisory: nothing for a vulnerability management program to key on.
The Fix Is Server-Side
The fix is not the owner's to install. It lives in SharkNinja's AWS account, not the robot's firmware. Per AWS's remediation guidance, a non-compliant policy is replaced by pushing a scoped version with CreatePolicyVersion and the setAsDefault flag, which makes that version operative for every certificate using the policy.
No firmware rollout required. Reissuing the certificates properly, which tokay0 recommended in March, is the longer job behind that.
Until SharkNinja does one or the other, the only mitigation available to an owner is to disconnect the vacuum from Wi-Fi. That ends app control, scheduling, and maps, and turns the product back into a vacuum.
tokay0 withheld his scripts while the flaw is live. He judged his other findings too minor to write up.
He never examined the rest of SharkNinja's connected lineup either, the smart grills and the wireless meat probes, which he says are probably vulnerable too. Those products come from the same company whose policy promises regular updates until a flaw is resolved. Four months on, this one is not.