Millions of internet-connected Shark robot vacuums may be vulnerable to a critical remote code execution (RCE) flaw that could allow attackers to control devices remotely, access onboard cameras, retrieve home maps, and potentially steal stored Wi-Fi credentials.
An independent researcher disclosed this issue following a 90-day reporting period, and it arises from overly permissive AWS IoT Core MQTT policies combined with an embedded command-execution feature in Shark vacuum firmware.
Millions of Shark Robot Vacuums Vulnerable
The researcher tested the flaw on the Shark RV2320EDUS and AV1102ARUS models, noting that the vulnerability affects all internet-connected Shark robot vacuums using the compromised provisioning configuration.
The reported attack chain begins with physical access to an affected device, enabling extraction of the device-specific AWS certificate and private key from the device’s firmware.
These credentials grant excessive permissions on an AWS IoT MQTT broker, enabling a compromised device to subscribe to wildcard topics that cover other Shark devices in the same region.
According to the report, a device certificate taken from a vulnerable RV2320EDUS vacuum could subscribe to the MQTT wildcard topic used by Shark devices, exposing telemetry and command traffic for many connected vacuums.
The researcher claimed that the same certificate could also publish messages to another device’s AWS IoT Shadow topic if the target’s serial number were known. Device serial numbers could allegedly be obtained directly from exposed MQTT traffic, thereby removing a significant barrier to targeting arbitrary systems.
The most severe aspect of the vulnerability involves an Exec_Command field managed by the vacuum’s appd device-management daemon. Reverse engineering the binary revealed that the daemon parses specially formatted MQTT messages and passes the provided command strings to a shell-execution function.
An attacker who can publish a crafted desired-state update to a target device’s MQTT Shadow topic could cause the vacuum to execute arbitrary commands with high privileges, according to the researcher.
The researcher confirmed the cross-device impact by using credentials from one vacuum to execute a payload on a separately purchased AV1102ARUS unit.
This successful test established that the vulnerability was not limited to a single device or serial number. While the proof of concept was executed only on devices owned by the researcher, the same mechanism could theoretically be used against exposed devices connected to the affected broker region.
The privacy and security implications extend beyond unauthorized cleaning commands. Some Shark robot vacuum models include cameras used for navigation and obstacle detection, and the researcher stated that a compromised device could be used to access a live camera feed and remotely control its motors.
Firmware analysis also identified locally stored household mapping data and plaintext Wi-Fi pre-shared keys, potentially providing attackers with a pathway from the vacuum to a victim’s broader home network.
During a 24-hour observation period, the researcher reported processing more than 10.5 million MQTT messages and identifying approximately 1.52 million unique devices in one AWS region.
Of those, about 673,816 devices, or 44%, sent an Exec_Response message indicating support for the command execution capability. The actual number of vulnerable devices may vary, as not all affected products may have communicated during the monitoring period.
The disclosure timeline illustrates that SharkNinja was first contacted on March 11, 2026, with technical details shared on March 11.
After repeated follow-ups, the researcher publicly disclosed the issue on July 13, stating that no patch or confirmed remediation date had been provided. SharkNinja reportedly acknowledged the report was under review and questioned whether a CVE was appropriate.
The researcher recommends that SharkNinja immediately restrict AWS IoT policies so that device certificates can only access their own MQTT topics, revoke or re-provision affected certificates, and remove or tightly authenticate the remote command execution functionality.
Until an official fix is available, owners should keep vacuum firmware up to date, isolate IoT devices on a separate network where possible, and monitor SharkNinja’s security advisories for remediation guidance.
Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.
