A Shark vacuum vulnerability lets anyone with physical access to one device take over other Shark robot vacuums. The reach extends across an entire Amazon Web Services region. The flaw sits in how SharkNinja scoped its AWS IoT certificates. Researcher tokay0 went public with it on 13 July, after four months of chasing a patch that never arrived.
How the Shark vacuum vulnerability works
Every Wi-Fi connected Shark vacuum carries a unique AWS IoT certificate. It also holds a private key, stored on its flash memory. Tokay0 found that opening a Shark RV2320EDUS with a screwdriver exposes an unauthenticated U-Boot console. That console leads straight to the certificate files at /mnt/res/vapp/certs/. No login is required at any step.
The certificate itself is not the real problem. What matters is the AWS IoT policy attached to it. That policy was not scoped to the one device. So the same credentials could subscribe to wildcard MQTT topics covering other vacuums in the region. They could also publish to those vacuums’ AWS IoT Shadow states. Each vacuum runs a daemon that reads an Exec_Command field from its shadow. It hands up to 1,000 bytes of that field to a shell, with high privileges attached.
Tokay0 confirmed the Shark vacuum vulnerability crosses hardware models. Using a certificate pulled from an RV2320EDUS, the researcher ran commands on a separate AV1102ARUS bought for the test. From there, the reach was wide. It took in a target vacuum’s live camera feed, its movement controls, the stored map of the owner’s home, and the household Wi-Fi password in plain text.
Millions of devices, one bad policy
To size the exposure, tokay0 watched MQTT traffic in a single AWS region for 24 hours. The haul: more than 10.5 million messages, from roughly 1.52 million unique device serial numbers. About 673,816 of those devices, 44%, answered with an Exec_Response message. That response confirms they run the vulnerable command handler.
Numbers like that point to a fleet-wide setup mistake, not a one-off bug in a single unit. AWS’s own IoT guidance warns against exactly this pattern. A certificate policy that is not scoped to a specific device lets an attacker read or modify shadows, jobs and job executions for every device on the account. AWS IoT Device Defender exists to catch that exact risk before a product ships.
The affected policy sits on SharkNinja’s cloud account, not on the vacuum itself. So other connected products under the same brand could plausibly share the mistake, including smart grills and wireless meat thermometers reported elsewhere in the coverage. Tokay0’s published research focuses on the vacuums. No one has confirmed elsewhere whether the kitchen devices carry the same flaw.
No patch, and the fix isn’t on the device
This is a cloud policy problem, not a firmware bug. So SharkNinja cannot fix it by pushing a device update. The company needs to reissue scoped AWS IoT policies for its fleet. That work happens entirely on its own AWS account. It does not require touching a single vacuum in the field.
Tokay0’s disclosure timeline shows SharkNinja first contacted on 1 March 2026. Full technical detail followed on 11 March. The typical 90-day coordinated disclosure window lapsed in June, without a fix. SharkNinja told the researcher on 3 July that it would confirm a completion date by 10 July. That date passed with nothing, so tokay0 published on 13 July. The researcher also says SharkNinja questioned whether a CVE was even appropriate for the bug. Tokay0 requested an identifier through MITRE’s CNA-LR programme once the standard window had run out.
Until SharkNinja ships a server-side fix, owners have one real option. Pulling the vacuum off Wi-Fi disables the Shark vacuum vulnerability, but it also kills app control, scheduling and mapping.
For defenders, the lesson travels beyond one vacuum brand. Any product that issues a shared or loosely scoped device certificate creates a single point of failure. One unit falling into the wrong hands, through resale, repair, theft or a curious owner with a screwdriver, is enough to expose the whole fleet.
Not the first consumer IoT fleet bug, and unlikely to be the last
Robot vacuums are an unglamorous product category to find a fleet-wide flaw in. That is exactly why this one matters. These devices ship with cameras and microphones as standard features. They map the inside of a home, room by room. They connect to the same Wi-Fi network as laptops, phones and, increasingly, smart locks. A vendor that gets device-to-cloud trust wrong is not protecting a niche gadget. It is protecting a sensor sitting in millions of living rooms.
Similar cloud-policy mistakes have surfaced before in other connected-device categories. The root cause is usually the same: a certificate template copied across a product line, without per-device scoping, because scoping takes more engineering effort than a shared policy does. What sets the Shark vacuum vulnerability apart is the scale tokay0 measured directly, rather than estimated from shipment figures. The four-month gap between a working proof of concept and any public fix stands out too.
What happens next depends on SharkNinja. A server-side policy change could close this without a single firmware update. There is no technical reason for the exposure to continue much longer. That puts it in a different category from flaws baked into silicon, such as the Apple SecureROM exploit that has no possible patch. This one is a configuration change SharkNinja could make today. Whether that translates into a fast fix, after public disclosure and renewed press attention, is the part worth watching.