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. 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. 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.

At a glance

• 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.
• 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.
• 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.
• In 24 hours watching one Amazon region, the researcher counted 1,517,605 Shark vacuums, of which 673,816 answered a command probe.
• 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.

Background

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. 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.

The connection uses MQTT, the lightweight messaging system that many smart-home devices & their clouds use to exchange short messages. Each vacuum authenticates to Amazon's message router, called a broker, with its own certificate & private key. 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. The flaw is that Shark's certificates were allowed to reach every vacuum's mailbox, not just their own.

Camera, home map, and Wi-Fi password exposure

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. 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. Note that storing the Wi-Fi password in plaintext was not the primary vulnerability in this case. Devices using WPA2/WPA3-Personal (PSK) must retain the network credential (or an equivalent derived secret) to authenticate, so encrypting or obscuring it on the device would not have prevented recovery after the vacuum was already compromised.

tokay0 reported pulling a live camera feed from a driving AV1102ARUS and finding the home map and the Wi-Fi password stored, in his words, in plaintext.

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. The stored map reveals room layouts & which areas are used most. 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. tokay0 summarized the result as hackable cameras with wheels inside owners' homes.

Unscoped certificate and the Exec_Command field

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.

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. 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. 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. tokay0 wrote that the flaw gives an attacker full access to any Shark device using only its serial number.

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.

The Hacker News notes that Amazon's Device Defender service flags this policy shape as IOT_POLICY_OVERLY_PERMISSIVE_CHECK and rates it critical, warning that it lets an attacker read or modify shadows, jobs, or job executions for all your devices.

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. The AV1102ARUS was still a valid target, because it ran the Exec_Command handler. 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.

Number of devices observed

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. Those are devices observed responding, not devices he tested or compromised, & he says the true number is likely higher. 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.

In 24 hours watching one AWS region, tokay0's scanner logged 1,517,605 unique Shark vacuums, of which 673,816 (44%) returned an Exec_Response message.

Server-side fix and owner mitigation

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. 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.

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.

Disclosure timeline

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

Responsible-disclosure timeline

Date	Event
March 1, 2026	tokay0 contacted SharkNinja about a vulnerability in its product line
March 11, 2026	Full vulnerability details sent to SharkNinja
March 12, 2026	SharkNinja acknowledged receipt of the details
April 25, 2026	tokay0 followed up on the status of the assessment
April 27, 2026	SharkNinja responded that the report was under review
June 7, 2026	tokay0 followed up again on the status
June 9, 2026	The 90-day responsible-disclosure period ended with no fix
June 11, 2026	tokay0 reserved an identifier through MITRE's CNA of last resort to seek a CVE
June 28, 2026	tokay0 notified SharkNinja of the plan to disclose publicly
July 3, 2026	SharkNinja said it would send a confirmed completion date by Friday, July 10
July 10, 2026	No email arrived from SharkNinja
July 13, 2026	tokay0 published the writeup, with the flaw still unpatched

tokay0's disclosure timeline records first contact with SharkNinja on March 1, 2026 and publication of the unpatched flaw on July 13, 2026, after the 90-day disclosure window closed on June 9 with no fix.

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

Comparison to the DJI Romo flaw

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.

Two robot vacuum makers, one kind of cloud flaw

Response	SharkNinja (Shark)	DJI (Romo)
Flaw	Over-permissive cloud certificate allowing region-wide remote takeover	Authorization flaw exposing camera feeds, audio, & floor plans
Scale reported	673,816 devices confirmed responding to a command probe, of 1,517,605 seen in one region	Roughly 6,700 vacuums
Time to fix	Still unpatched four months after the March 1, 2026 report	Patched within weeks
Researcher outcome	Vendor questioned whether a CVE is appropriate	Researcher collected a $30,000 bounty

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.

Tom's Hardware contrasts SharkNinja's response with DJI, whose comparable Romo vacuum flaw exposed roughly 6,700 vacuums, was patched within weeks, and earned the researcher a $30,000 bounty.