"Watching one AWS region for 24 hours, I counted 1,517,605 unique Shark serial numbers, of which 673,816, or 44%, emitted an Exec_Response."
How tokay0 demonstrated cross-model control
The researcher publishing as tokay0 bought a Shark RV2320EDUS, extracted its certificate from the device's flash, and used that credential against SharkNinja's AWS broker to run root commands on other vacuums in the same AWS region. He subscribed to $aws/things/# to observe broker traffic and harvest serial numbers, then published shadow updates carrying an Exec_Command field. The device-management daemon appd reads that field and hands it to a function named execute_command, which invokes popen to run any payload under 1,000 bytes.
Using this method, tokay0 landed a reverse shell on an AV1102ARUS he purchased solely as a target, then pulled a live feed from that model's onboard camera while the robot drove. He tested only devices he bought himself and withheld exploit scripts while the flaw remained unpatched.
The AWS policy error and Device Defender audit
The root cause is policy scoping: the certificate tokay0 extracted carried a device policy that was never pinned to the device holding it. Presenting that certificate to SharkNinja's cloud broker lets an attacker publish commands addressed to any device the broker serves. Amazon's IoT fleet auditing service, Device Defender, contains an audit check that specifically flags this pattern as IOT_POLICY_OVERLY_PERMISSIVE_CHECK. AWS documents that such a policy lets a compromised certificate "read or modify shadows, jobs, or job executions for all your devices," and rates the finding critical.
Scope, regional limits, and measured numbers
Certificates are pinned to an AWS region, which limits an extracted key to devices in the same region; reaching other regions requires provisioning another certificate carrying the same permissive policy. Tokay0 watched one region for a day and observed 1,517,605 unique Shark serial numbers. Of those, 673,816 devices—44%—emitted an Exec_Response, which tokay0 treated as confirmation the device runs the command handler. He notes these are devices observed replying, not devices independently tested or fully compromised, and that the true number may be higher.
SharkNinja's disclosure timeline and the missing CVE
By tokay0's account he contacted SharkNinja on March 1 and sent technical details on March 11. The company acknowledged receipt the next day, told the researcher on April 27 that the report was under review, and on July 3 said it would provide a confirmed completion date by July 10—no email arrived. Tokay0 published his write-up on July 13 and says the vendor downplayed the severity and questioned whether "a CVE is appropriate."
He also contacted MITRE's CNA of last resort on June 11 to request an identifier; by publication he had received no CVE, no CVSS score, and no advisory for vulnerability-management programs to key on. SharkNinja had published nothing on the flaw as of Thursday, and the researcher says he did not examine the rest of SharkNinja's connected lineup, though he judged smart grills and wireless meat probes "probably vulnerable too."
Mitigation, the server-side fix, and what owners can do
The remediation lives on SharkNinja's AWS account, not in device firmware. Per AWS guidance, operators replace a non-compliant policy by creating a scoped policy version and setting it as the default with CreatePolicyVersion and the setAsDefault flag, which makes the change effective for every certificate using that policy. Reissuing certificates properly, which tokay0 recommended in March, is a longer task.
Until SharkNinja performs one of those server-side actions, the only mitigation available to owners is to disconnect the vacuum from Wi‑Fi. That stops app control, scheduling, and maps—returning the product to a standalone vacuum. Extracting the certificate is straightforward in the tested devices: remove a few screws, connect to exposed UART pins, use the U-Boot console (which asks no password), and boot with init=/bin/sh to obtain a root shell where the per-device key and certificate sit as ordinary files at /mnt/res/vapp/certs/.
What this means for owners, security teams, and regulators
- Owners: If you want to block remote attack paths described by tokay0 without waiting for a vendor fix, disconnect your vacuum's Wi‑Fi. That action ends remote app features and mapping.
- Security teams and IoT managers: Audit device policies for publish/subscribe permissions scoped to ${{iot:Connection.Thing.ThingName}} rather than to $aws/things/*; AWS Device Defender exposes this specific misconfiguration as IOT_POLICY_OVERLY_PERMISSIVE_CHECK.
- Regulators and disclosure coordinators: The case highlights a disclosure timeline that began March 1 and led to public publication July 13 without a CVE or vendor advisory; the researcher says SharkNinja's own vulnerability-disclosure policy commits the company to "provide regular updates until the reported vulnerability is resolved."
Four months after initial contact, the flaw remains unpatched in the cloud account that matters, and the immediate technical fix is one command pushed into SharkNinja's AWS tenancy or a new default policy version. Until the vendor acts, researchers and defenders will be watching whether SharkNinja replaces the permissive policy, reissues certificates, or issues guidance—while owners decide whether to sacrifice smart features to cut the risk.
