Full Report
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
Analysis Summary
# Vulnerability: SharkNinja IoT Cloud Orchestration and Command Execution Flaw
## CVE Details
- **CVE ID:** Not yet assigned (Vendor reportedly questioned appropriateness of a CVE)
- **CVSS Score:** Estimated 9.0 - 10.0 (Critical)
- **CWE:** CWE-284: Improper Access Control; CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
## Affected Systems
- **Products:** Shark brand robot vacuums (confirmed on RV2320EDUS and AV1102ARUS).
- **Versions:** Potentially millions of internet-connected units; specifically those responding to the `Exec_Command` handler.
- **Configurations:** Devices provisioned with overly permissive AWS IoT policies within a specific geographic AWS region.
## Vulnerability Description
The vulnerability consists of two primary components:
1. **Broken Cloud Access Control:** Certain Shark vacuum models (e.g., RV2320EDUS) contain identity certificates with an AWS IoT policy that is not scoped to the specific device. Instead of pinning permissions to the individual "ThingName," the policy uses wildcards (`$aws/things/#`). This allows any device with such a certificate to subscribe to and publish updates for the "shadow" documents (state files) of any other Shark device within the same AWS region.
2. **Unauthenticated Remote Code Execution (RCE):** The device management daemon (`appd`) monitors the device shadow for a field named `Exec_Command`. When this field is populated, the daemon passes the string (up to 1,000 bytes) to an `execute_command` function, which executes the input via `popen` with root privileges.
## Exploitation
- **Status:** PoC available; researcher verified cross-model exploitation.
- **Complexity:** Low (Requires physical access to one "key" device to extract the certificate, then network access to interact with the cloud broker).
- **Attack Vector:** Network (once a certificate is obtained via initial physical access to a single unit).
## Impact
- **Confidentiality:** High (Access to live camera feeds, house maps, and plaintext Wi-Fi passwords).
- **Integrity:** High (Ability to drive the robot and execute arbitrary root-level system commands).
- **Availability:** High (Potential to brick or disable the device fleet).
## Remediation
### Patches
- **Status:** Unpatched at the time of the report. The vendor has been aware since March 2026 but has not released a confirmed completion date for a fix.
### Workarounds
- **Isolate Devices:** Place IoT devices on a dedicated, isolated VLAN to prevent the robot from accessing other sensitive data on the local network (e.g., sniffing Wi-Fi credentials).
- **Disable Internet Access:** For users concerned with immediate privacy, disconnecting the vacuum from the Wi-Fi will prevent cloud-based exploitation.
## Detection
- **Indicators of Compromise:** Unexpected `Exec_Command` entries in the AWS IoT device shadow history (if logs are accessible to the user). Unusual robot behavior (unauthorized movement or camera activation).
- **Detection Methods:** AWS Device Defender flags this specific policy configuration as `IOT_POLICY_OVERLY_PERMISSIVE_CHECK`.
## References
- **Researcher Original Post:** hxxps[://]tokay0[.]com/posts/millions-of-shark-vacuums-vulnerable-to-rce[.]html
- **Vendor Policy:** hxxps[://]www[.]sharkninja[.]com/vulnerability-disclosure-policy[.]html
- **AWS Best Practices:** hxxps[://]docs[.]aws[.]amazon[.]com/iot-device-defender/latest/devguide/audit-chk-iot-policy-permissive[.]html