A critical vulnerability has been uncovered in **SharkNinja**'s robot vacuum cleaners, specifically the **Shark RV2320EDUS** model, which could allow malicious actors to remotely control devices, access live camera feeds, and exfiltrate sensitive home data, including Wi-Fi credentials. ### The Root of the Problem: Overly Permissive AWS Policies **tokay0**, the researcher who publicly disclosed the method, discovered that by extracting a certificate from a **Shark RV2320EDUS** vacuum, an attacker could run root commands on other **Shark** vacuums within the same **AWS** region. This is due to an overly permissive policy attached to the device's certificate, which was never properly scoped to the device holding it. The **AWS** cloud broker accepts commands published from such a certificate, regardless of the target device. This isn't a complex memory corruption or privilege escalation exploit. Instead, it leverages a misconfiguration where the device's 'shadow' document in **AWS** includes an `Exec_Command` field. The `appd` management daemon on the robot reads this field and passes its content (up to 1,000 bytes) to a function named `execute_command`, which then executes it via `popen`. ### Proof of Concept and Cross-Model Vulnerability **tokay0** demonstrated the exploit by subscribing to the `$aws/things/#` topic, harvesting serial numbers, and then publishing a shadow update to a target device's topic. This allowed him to land a reverse shell on an **AV1102ARUS** model, which he used to pull a live feed from its onboard camera while the robot was in motion. Obtaining the necessary certificate is alarmingly straightforward. A screwdriver provides access to the mainboard's UART pins. The **U-Boot** console, lacking a password, allows booting into a root shell by setting `init=/bin/sh` in the boot arguments. From there, the device's key and certificate are easily accessible in `/mnt/res/vapp/certs/`. Certificates are pinned to their respective **AWS** regions, meaning a key lifted in one region can only affect devices in that region. However, obtaining another certificate from a different region with the same flawed policy would extend the attack's reach. ### AWS Device Defender Flagged This Years Ago Significantly, **Amazon**'s own **IoT** fleet auditing service, **Device Defender**, is designed to flag this exact policy shape. The `IOT_POLICY_OVERLY_PERMISSIVE_CHECK` audit control rates such policies as critical, warning that a compromised certificate with such a policy allows an attacker to "read or modify shadows, jobs, or job executions for all your devices." This suggests **SharkNinja** failed to adhere to recommended **AWS** security practices. It appears that newer **Shark** models, like the **AV1102ARUS**, have correctly scoped certificates, preventing them from being used as 'keys' to compromise other devices. However, any vacuum that implements the `Exec_Command` handler remains a target, regardless of its own certificate's scope. **tokay0** attributes this to a provisioning fix that never reached the older fleet's certificates.  In a 24-hour observation of one **AWS** region, **tokay0** counted 1,517,605 unique **Shark** serial numbers. Of these, 673,816 (44%) emitted an `Exec_Response`, indicating they run the command handler and are thus potentially vulnerable. The researcher believes the true number is likely higher. ### Four Months Without a Patch **tokay0** initially contacted **SharkNinja** on March 1st, providing full details by March 11th. Despite acknowledging the report and stating it was under review, **SharkNinja** failed to provide a confirmed completion date for a fix, as promised. The researcher published his findings on July 13th, after four months of inaction. He also noted that **SharkNinja** reportedly downplayed the severity and questioned the appropriateness of a **CVE**. **SharkNinja**'s own [vulnerability disclosure policy](https://www.sharkninja.com/vulnerability-disclosure-policy.html) commits to providing "regular updates until the reported vulnerability is resolved" and requests researchers to withhold disclosure until a fix is confirmed. As of this report, no public patch or advisory has been issued by **SharkNinja**. Furthermore, no **CVE** identifier has been assigned. **tokay0** requested an ID from **MITRE**'s CNA of last resort on June 11th but received no response before publishing. The lack of a **CVE** and **CVSS** score makes it challenging for vulnerability management programs to track and prioritize this critical flaw. ### Server-Side Fix, User-Side Mitigation The good news is that the primary fix for this vulnerability is server-side, residing within **SharkNinja**'s **AWS** account, not the robot's firmware. According to **AWS**'s [remediation guidance](https://docs.aws.amazon.com/iot-device-defender/latest/devguide/audit-chk-iot-policy-permissive.html#audit-chk-iot-policy-permissive-how-to-fix), non-compliant policies can be replaced by pushing a properly scoped version using `CreatePolicyVersion` with the `setAsDefault` flag. This would immediately make the new policy operative for all certificates using it, without requiring a firmware update. Reissuing certificates with proper scoping, as **tokay0** recommended in March, is a more comprehensive, albeit longer-term, solution. Until **SharkNinja** implements these server-side fixes, the only mitigation available to owners is to disconnect their vacuums from Wi-Fi. This, however, disables smart features like app control, scheduling, and mapping, effectively reverting the product to a basic vacuum cleaner. **tokay0** has withheld his scripts while the vulnerability remains active. He also speculates that other connected **SharkNinja** products, such as smart grills and wireless meat probes, could be susceptible to similar vulnerabilities, given they originate from the same vendor with the same unfulfilled disclosure commitments.