A significant security vulnerability has been discovered in Shark RV2320EDUS robot vacuums, allowing unauthenticated remote command execution on other devices across the same Amazon Web Services (AWS) region. The flaw, detailed by a researcher using the handle tokay0, enables an attacker to access a victim’s robot vacuum’s camera, control its movement, retrieve house maps, and extract plaintext Wi-Fi credentials. SharkNinja, the parent company of Shark and Ninja appliance brands, was reportedly notified of the issue in March but has yet to deploy a fix.
The vulnerability stems from an improperly scoped AWS IoT policy attached to a certificate found on the Shark RV2320EDUS vacuum. When this certificate is presented to Shark’s cloud broker, it grants broad permissions to interact with any device served by that broker, regardless of the certificate’s origin. This bypasses standard security checks, allowing attackers to execute arbitrary commands on other vulnerable Shark vacuums without needing to exploit memory corruption or bypass authentication.
Shark RV2320EDUS Robot Vacuum Vulnerability Exposes User Data
According to researcher tokay0, the method for exploiting this Shark RV2320EDUS robot vacuum vulnerability involves a straightforward process. By extracting a certificate from the device, an attacker can subscribe to AWS IoT traffic and monitor communications, harvesting serial numbers. Publishing commands is equally simple: a specially crafted update to the device’s “shadow” document, which stores the per-device state in the cloud, can include an “Exec_Command” field. A management daemon on the vacuum then processes this field, executing any command under 1,000 bytes through the popen function.
To demonstrate the cross-model exploit potential, the researcher successfully landed a reverse shell on a different Shark model, the AV1102ARUS. From this compromised device, the attacker was able to access the live camera feed and control the robot’s movement. The initial certificate is reportedly easy to obtain, requiring only a screwdriver to access the mainboard and expose UART pins. The U-Boot console, which requires no password, and the use of “init=/bin/sh” in the boot arguments grant root access, allowing direct retrieval of the device’s private key and certificate files.
The scope of this Shark RV2320EDUS robot vacuum vulnerability is limited by AWS region; a certificate from one region can only affect devices within that same region. However, obtaining a certificate from another region would allow for similar attacks targeting devices there, provided they carry the same flawed policy. This situation is particularly concerning given that AWS’s own IoT fleet auditing service, Device Defender, is designed to flag such over-permissive policies, specifically identifying those granting publish or subscribe access to “$aws/things/*” without device-specific scoping.
AWS documentation warns that such vulnerabilities can allow attackers to “read or modify shadows, jobs, or job executions for all your devices.” While not every Shark vacuum certificate possesses the overly permissive policy, any vacuum running the “Exec_Command” handler is a potential target. The AV1102ARUS, used in the demonstration, was a target rather than a key, with its certificate correctly scoped and its firmware being more recent, suggesting the vulnerability lies in older provisioning practices that may not have been retroactively applied to older device fleets.
Widespread Impact and Disclosure Delays
The researcher estimates that millions of Shark vacuums could be vulnerable. In one AWS region observed over 24 hours, tokay0 identified over 1.5 million unique Shark serial numbers. Of these, nearly 45% emitted “Exec_Response,” indicating that the device runs the command handler. These figures represent observed devices, not necessarily compromised ones, and the true impact could be higher.
A significant point of contention is the timeline of the disclosure. The researcher claims to have reported the vulnerability to SharkNinja on March 1, providing full details on March 11. SharkNinja acknowledged the report the following day, informed the researcher the report was under review on April 27, and promised a confirmed completion date by July 10. No such update was received, leading to the public disclosure on July 13. According to the researcher, SharkNinja downplayed the severity of the flaw and questioned the appropriateness of a CVE identifier.
SharkNinja’s published vulnerability disclosure policy commits the company to providing regular updates on resolved vulnerabilities and requests researchers to withhold disclosure until a fix is confirmed. However, as of this reporting, SharkNinja has not released any official statement or patch regarding this specific flaw. The Hacker News has reached out to SharkNinja for comment on the patch status and disclosure timeline.
Adding to the lack of transparency, a CVE identifier has not yet been assigned. The researcher’s request to MITRE, the designated CVE Numbering Authority, on June 11 has reportedly gone unanswered, leaving a significant gap in formal tracking and alerting mechanisms for affected customers and cybersecurity professionals.
The Server-Side Fix and User Mitigation
The solution to this Shark RV2320EDUS robot vacuum vulnerability rests with SharkNinja, not the end-user. The fix involves updating the AWS IoT policies to properly scope them to individual devices, a procedural change that does not require a firmware update for the vacuums themselves. According to AWS remediation guidance, this can be achieved by pushing a scoped policy version and setting it as the default, a process that reissues policies for all associated certificates.
Until SharkNinja implements this server-side fix, the only recourse for consumers is to disconnect their vulnerable vacuums from Wi-Fi. This action will disable app control, scheduling, and map features, effectively reverting the smart device to a basic vacuum cleaner function. The researcher has withheld the specific scripts used for the exploit while the vulnerability remains unpatched.
Furthermore, the researcher has indicated that other connected SharkNinja products, such as smart grills and wireless meat probes, may also be susceptible to similar vulnerabilities, given that they likely share the same underlying cloud infrastructure and security practices. The company’s commitment to regular updates remains to be seen, as this reported flaw has persisted for over four months without a resolution.