Shark Vacuum Flaw Exposes Root Access

A security researcher using the handle tokay0 has detailed a method to achieve root-level command execution on Shark-branded robot vacuums. By accessing the device's mainboard, an attacker can extract credentials that grant access to other units within the same cloud region, enabling control over camera feeds, navigation, and Wi-Fi credentials.

The Mechanics of Cloud Access

The vulnerability stems from how the devices authenticate with the company's cloud infrastructure. The certificates stored on the devices are governed by an overly permissive policy that fails to scope access to the individual unit. Instead of restricting requests to a specific device, the certificate allows the holder to interact with the broader AWS broker as if they were any device it serves.

The issue does not involve memory corruption or complex privilege escalation. Instead, it relies on the device shadow—a state document stored in the cloud. By sending an update to the shadow containing an Exec_Command field, an attacker can trigger the vacuum's management daemon to execute arbitrary commands via the popen function. The researcher demonstrated this by landing a reverse shell on an AV1102ARUS model and accessing its live camera feed.

Quantifying the Potential Impact

The researcher conducted observations within a single AWS region to estimate the scope of the vulnerability. The data collected indicates a significant number of potentially affected devices:

• 1,517,605 unique Shark serial numbers observed over 24 hours.
• 673,816 devices, or 44% of the total observed, emitted an Exec_Response.
• The command handler runs code under 1,000 bytes.

Disclosure and Vendor Response

The researcher reported the findings to SharkNinja on March 1. Despite the company’s vulnerability disclosure policy, which commits to providing regular updates, the researcher stated that correspondence stalled. After initial contact and an April 27 update stating the report was under review, no further progress was confirmed by the July 10 deadline. The researcher put the method online on July 13.

The company has not issued a CVE identifier for the issue, and as of July 16, no public advisory has been released. The researcher noted that the company questioned whether a CVE was appropriate for the vulnerability.

Server-Side Remediation Requirements

Because the vulnerability lies in the cloud policy configuration rather than the device firmware, the fix must be implemented on the server side. Following remediation guidance provided by AWS, the company could replace the existing policy with a scoped version using the CreatePolicyVersion command. Until such a change is deployed, the only effective mitigation for owners is to disconnect the devices from their local network.

This situation highlights the risks inherent in cloud-managed IoT ecosystems where improper policy scoping can turn a single compromised device into a broad access vector. For consumers, the inability to patch server-side flaws locally leaves them dependent on the manufacturer's security maintenance, which can result in long windows of exposure when disclosure and remediation timelines do not align.