There is a machine in your house that has driven into every room, bumped along every wall, and built a dimensioned floor plan of where you live. It knows which rooms you use and when. Many models carry a camera. All of them know your Wi-Fi password, because they had to.
In July 2026, a security researcher demonstrated that for hundreds of thousands of Shark robot vacuums, all of that was reachable by anyone willing to buy one vacuum and unscrew it.
What the Researcher Actually Did
The researcher, who publishes as tokay0, bought a Shark RV2320EDUS, opened the case, and connected to the board’s U-Boot console — the bootloader — which required no authentication at all. From there they extracted the device’s AWS IoT client certificate: the credential the vacuum uses to identify itself to Shark’s cloud.
That much is expected. Physical access to a device you own generally means access to its secrets, and no vendor can fully prevent it. The interesting part is what that one certificate turned out to be permitted to do.
In a correctly configured AWS IoT deployment, each device certificate is scoped to that device: it may publish and subscribe only to topics containing its own serial number. Its cloud “shadow” — the record of its state and pending commands — is its own private inbox. One certificate, one device.
Shark’s policy was not scoped that way. The certificate lifted from a single vacuum could:
- Subscribe to wildcard MQTT topics, receiving the message traffic of other people’s vacuums
- Publish to the AWS IoT Shadow state of any Shark vacuum in the same AWS region
And the shadow had a field called Exec_Command, which passed up to 1,000 bytes straight to a shell running with high privileges on the target device. That is not a data leak. That is unauthenticated remote code execution on someone else’s appliance, in someone else’s house.
The Blast Radius
tokay0 monitored the MQTT traffic for 24 hours and counted 1,517,605 unique Shark serial numbers in one AWS region alone. Of those, roughly 673,816 — about 44% — accepted remote command execution.
What an attacker could reach on each one:
| Asset | What it means for the owner |
|---|---|
| Live camera feed | Real-time video from floor level, throughout your home |
| Stored home maps | Room layout, dimensions, furniture, which rooms get used |
| Wi-Fi credentials | Stored in plaintext — the key to your entire home network |
| Movement control | Drive the vacuum, and its camera, anywhere on that floor plan |
The Wi-Fi password is the detail that turns this from a creepy-privacy story into a network-security one. A robot vacuum sits on your home network like any other device. Hand an attacker its stored SSID and passphrase and they no longer need the vacuum — they have the network the vacuum lives on, and everything else on it.
The home map deserves a second look too. A floor plan of your house, annotated with which rooms are trafficked and when, is exactly the intelligence product a burglar would commission if they could. This is the same category of data that made robot vacuum manufacturers’ cloud practices a privacy flashpoint long before anyone found a remote-code-execution path to it.
The Timeline
- March 2026 — tokay0 reports the flaw to SharkNinja. The company acknowledges receipt.
- July 13, 2026 — Still unremediated four months on, the researcher publishes the full writeup: No Shark is Safe: Millions of Shark Vacuums are Vulnerable to RCE.
- July 20, 2026 — SharkNinja deploys a fix. The company states it is “aware of the researcher’s report on some of our robot vacuums, and we have completely addressed the identified vulnerability.”
Credit where due: once disclosure forced the issue, the fix landed in a week. The four months before that are the part worth sitting with.
Why You Could Not Have Patched This
Here is the uncomfortable structural lesson, and it is bigger than one vacuum brand.
The vulnerability was not in the vacuum. It was in an AWS IoT authorization policy sitting on Shark’s cloud infrastructure. No firmware update was ever going to fix it. There was no setting to toggle, no update button to press, no advisory to act on. Every diligent owner who kept their firmware current was exactly as exposed as everyone else — and there was no action available to them that would have helped.
We talk endlessly about firmware updates and default passwords because those are the parts owners control. But a modern smart-home device is a thin client for a vendor’s cloud, and the security of that cloud’s identity and authorization model is invisible to you, unauditable by you, and unfixable by you. You are trusting an engineering decision you will never see. When it is wrong, you find out from a researcher’s blog post.
That is the same shape as the Brinks and ADT breaches, where the failure was in a vendor’s cloud CRM rather than anything in the customer’s home, and it is why the EU Cyber Resilience Act’s incoming reporting clock matters: a four-month silence after a valid report is precisely what that regulation is designed to make untenable.
What To Actually Do
You cannot audit a vendor’s IAM policies. You can shrink what one bad policy costs you.
Put every appliance on an IoT VLAN or guest network. If the vacuum’s stored Wi-Fi credentials only unlock a segment containing other appliances — no laptops, no NAS, no phones — then leaking them is an annoyance rather than a breach. This single control neutralizes most of the damage in this story, and it works against the vulnerability nobody has found yet. Our complete guide to securing your smart home network walks through the setup.
Prefer a camera-less model unless you have a real use for the camera. Obstacle-avoidance cameras are a genuine convenience. They are also a fleet of internet-connected cameras at knee height in your home, governed by a cloud you cannot inspect. Many vacuums navigate perfectly well on LiDAR alone.
Turn off remote access when you do not use it. If you only ever start the vacuum from the same room you are standing in, the cloud round-trip is buying you nothing and costing you exposure.
Give appliances a dedicated network password. Not the one that also opens your primary network. If a device stores a credential in plaintext, make it a credential you can rotate without re-pairing your whole house.
Weigh disclosure track record when buying. The gap between “reported in March” and “fixed in July” is a product attribute, as real as suction power. Vendors who publish a security contact, run a disclosure program, and ship fixes on a clock are telling you something about the cloud you are about to depend on.
Bottom Line
One certificate, extracted from one vacuum bought at retail, unlocked root-level command execution against roughly 674,000 other people’s machines — their cameras, their floor plans, their Wi-Fi passwords. It was fixed on July 20, 2026, and no owner did anything to earn that fix.
The device in your house is the small half of the system. The cloud account behind it is the large half, and it is the half you cannot see. Buy accordingly, and segment as though the cloud will eventually let you down — because periodically, it does.
Sources
- tokay0: No Shark is Safe — Millions of Shark Vacuums are Vulnerable to RCE
- The Hacker News: Unpatched Shark Vacuum Flaw Could Let Attackers Control Other Vacuums Region-Wide
- Malwarebytes: Shark vacuum flaw exposes cameras, home maps and Wi-Fi passwords
- Tom’s Hardware: Robot vacuum flaw lets one stolen certificate run root commands on other Shark robovacs in the same AWS region
- The Security Ledger: Robot Vacuum Flaw Could Give Hackers Control Over Millions of Home Devices
- Cybernews: Unpatched Shark vacuum flaw enables remote camera spying, researcher says
