Shark robot vacuum cloud vulnerability (2026)

An unpatched flaw in SharkNinja's internet-connected Shark robot vacuums lets a stranger who never sets foot in the house take control of them across an entire Amazon cloud region. On camera-equipped models, that access exposes the live camera feed, the stored map of the owner's rooms, & the home Wi-Fi password, which the vacuum keeps as readable text.^[1][2][3] The vacuums log in to Amazon's cloud with a device certificate (a digital ID badge that proves to the servers the machine is a genuine Shark vacuum) that SharkNinja did not lock to the individual machine, so a certificate copied off one vacuum's circuit board is accepted by the cloud as valid for commands aimed at any Shark vacuum in the same region.^[1][2] A researcher publishing under the handle tokay0 reported the flaw to SharkNinja, the maker of the Shark & Ninja appliance brands, on March 1, 2026, & published it unfixed on July 13, 2026, after four months without a patch.^[3][1]

• A stranger who never enters the home can watch the live camera feed of a camera-equipped Shark vacuum, drive it around the house, & read the saved map of the owner's rooms.^[3][1]
• The home Wi-Fi password sits on the vacuum as readable text, so an attacker who reaches the device gains a foothold on the whole home network, not just one robot.^[3][4]
• The attack starts with one certificate copied off a single vacuum the attacker buys; every step after that runs remotely over the internet against other Shark vacuums in the same Amazon region.^[1][4]
• In 24 hours watching one Amazon region, the researcher counted 1,517,605 Shark vacuums, of which 673,816 answered a command probe.^[3][1]
• The repair is SharkNinja's to make in its cloud, not the owner's: four months after being told, SharkNinja had not patched it, & the only owner step is to disconnect the vacuum from Wi-Fi.^[1][3][5]

Shark robot vacuums are internet-connected cleaning robots sold by SharkNinja. Each unit keeps a permanent connection to a server run by Amazon Web Services, the cloud-computing division of Amazon, so the owner can start, stop, schedule, & steer the machine from the SharkClean phone app.^[3] The higher-end AV1102ARUS, sold as the Shark IQ Robot Vacuum XL, carries a camera mounted on top that tokay0 took to be for obstacle detection.^[3][2]

The connection uses MQTT, the lightweight messaging system that many smart-home devices & their clouds use to exchange short messages.^[4] Each vacuum authenticates to Amazon's message router, called a broker, with its own certificate & private key.^[3] By Amazon's design, every device gets its own private mailbox in the cloud, a per-device state record that AWS calls a shadow, & a device is supposed to read & write only its own.^[4][1] The flaw is that Shark's certificates were allowed to reach every vacuum's mailbox, not just their own.^[4]

For the owner of a camera-equipped Shark vacuum, the exploit turns a household appliance into a surveillance device that a stranger controls. tokay0 wrote a script that pulled a live feed from the AV1102ARUS camera while the robot drove around, & he was able to take over the motors & drive the machine remotely.^[3] The same vacuum stored a file mapping the owner's house & the home Wi-Fi password in plaintext, meaning the password sat on the device as ordinary readable text rather than in scrambled form.^[3]

The stolen Wi-Fi password is the part that reaches past the vacuum. It is the key to the network every other device in the home shares, so an attacker who reads it gains a foothold on the owner's local network, not just control of one robot.^[4] The stored map reveals room layouts & which areas are used most.^[4] None of this requires the attacker to be near the house: the certificate is lifted once from a vacuum the attacker buys, & every step after that happens remotely over the internet.^[4][1] tokay0 summarized the result as hackable cameras with wheels inside owners' homes.^[3]

Getting the first certificate takes a screwdriver & one vacuum the attacker owns. The mainboard exposes UART pins (a debug connector on the circuit board), the U-Boot startup console asks for no password, & setting init=/bin/sh in the boot options drops the attacker into a root shell, meaning full administrative control of the device's software, where the certificate & its private key sit as ordinary files.^[1][3]

From there the attack is entirely in the cloud. tokay0 found that his device certificate carried no access controls limiting which mailboxes it could read: he subscribed to the wildcard address $aws/things/# & watched messages flowing to and from every vacuum in his region, harvesting their serial numbers as he went.^[3][1] Publishing worked the same way. Each vacuum's shadow carries a field named Exec_Command that the management program appd reads & hands to a function that runs any string under 1,000 bytes as a shell command.^[1][3] Sending a crafted shadow update to a target vacuum's mailbox makes that vacuum run the attacker's command, which is remote code execution: a stranger making the device execute their instructions over the internet.^[3] tokay0 wrote that the flaw gives an attacker full access to any Shark device using only its serial number.^[3]

Amazon publishes an automated check for exactly this misconfiguration. Its Device Defender auditing service flags any device policy that grants access to $aws/things/* instead of pinning each certificate to its own device, lists it as IOT_POLICY_OVERLY_PERMISSIVE_CHECK, & rates it critical, warning that a compromised certificate carrying such a policy lets an attacker read or modify shadows, jobs, or job executions for all your devices.^[1]

Not every certificate is a master key. tokay0 pulled the certificate from a second, camera-equipped AV1102ARUS & found it was scoped correctly & could not subscribe to the wildcard address, so it could not be used to attack others; the certificate that carried the broken policy came from his RV2320EDUS.^[3][1] The AV1102ARUS was still a valid target, because it ran the Exec_Command handler.^[1] tokay0 noted that the correctly-scoped AV1102ARUS ran firmware (the vacuum's built-in software) several years older than the RV2320EDUS, & inferred that the over-permissive policies were introduced at some point during device provisioning & then spread across the fleet.^[3]

The headline on tokay0's writeup describes millions of vulnerable vacuums; the figure he verified is narrower. Watching a single AWS region for 24 hours, he counted 1,517,605 unique Shark serial numbers, of which 673,816, or 44%, replied with an Exec_Response message that he treats as confirmation the device runs the command handler.^[3][1][2] Those are devices observed responding, not devices he tested or compromised, & he says the true number is likely higher.^[1][2] Because certificates are pinned to their AWS region, a key lifted in one region reaches only that region's devices, though an attacker could buy vacuums tied to other regions to extend the reach.^[1][3]

The repair is not the owner's to install. It sits inside SharkNinja's own AWS account, where a non-compliant policy is replaced by pushing a properly scoped version to the certificates, & no firmware update to the robots is required.^[1][5][2] Because the fault is in the manufacturer's cloud configuration rather than the hardware, there is no owner-side repair; the flaw cannot be patched on the device the customer owns.^[4]

Until SharkNinja rescopes the policy, the only step an owner can take is to disconnect the vacuum from Wi-Fi. That ends app control, scheduling, & maps, & turns the connected product back into a plain vacuum.^[1][5]

tokay0 published the full record of the correspondence with SharkNinja. The dates below are from that writeup.^[3]

By tokay0's account, SharkNinja downplayed the severity & questioned whether a CVE is appropriate for the situation.^[3][1] No CVE identifier had been assigned as of publication, leaving no advisory or severity score for a security team to track.^[1] SharkNinja's own published disclosure policy commits the company to provide regular updates until the reported vulnerability is resolved.^[1][2]

A near-identical flaw in a competitor's robot vacuum was fixed in a fraction of the time. Tom's Hardware compared SharkNinja's response with DJI's handling of an authorization flaw in its Romo vacuums, disclosed in February 2026.^[2]

Tom's Hardware noted that cloud-side failures, where a company's backend fails to limit device access, have driven a run of robot-vacuum breaches & pushed interest toward fully offline designs that keep mapping & camera data off any vendor cloud.^[2]