Unpatched Shark Vacuum Flaw Could Let Attackers Control Other Vacuums Region-Wide

Summary

A researcher disclosed a critical vulnerability in Shark RV2320EDUS robot vacuums that allows attackers to extract a device certificate and use it to control other vacuums in the same AWS region, access cameras, read maps, and obtain Wi-Fi passwords in plaintext. The flaw stems from an overly permissive AWS IoT policy that was never scoped to individual devices. SharkNinja received the report in March 2026 but had not patched the issue as of the July 2026 disclosure, affecting an estimated 673,816+ devices confirmed to run the vulnerable command handler.

Full text

Unpatched Shark Vacuum Flaw Could Let Attackers Control Other Vacuums Region-Wide Swati KhandelwalJul 16, 2026IoT Security / Vulnerability Pull the certificate off the flash of a Shark RV2320EDUS robot vacuum, and you can run root commands on other people's Shark vacuums across the same AWS region: watch the camera, drive the robot, read the map of the house, and take the Wi-Fi password in plaintext. A researcher publishing under the handle tokay0 put the method online on Monday, having tested it only against vacuums he bought himself. The flaw was unpatched then. He says SharkNinja, the company behind the Shark and Ninja appliance brands, has had his report since March. The policy attached to that certificate was never scoped to the device holding it. Present it to Shark's cloud broker, and the broker accepts whatever you publish, addressed to any device it serves. No memory corruption, no privilege escalation, no password to guess. The command that runs is an ordinary field in the device shadow, the per-device state document AWS keeps in the cloud. Using the certificate from an RV2320EDUS, the researcher subscribed to $aws/things/# and watched the traffic crossing the broker, harvesting serial numbers as he went. Publishing works the same way. The shadow carries an Exec_Command field that the management daemon appd reads and hands to a function named execute_command, which runs anything under 1,000 bytes through popen. Send a shadow update carrying that field to a device's topic. If that device implements the handler, it runs the command. He proved the cross-model path, landing a reverse shell on an AV1102ARUS he bought purely as a target, then using that shell to pull a live feed off the model's onboard camera while the robot drove around. The certificate comes off with a screwdriver. The mainboard exposes UART pins, the U-Boot console asks for no password, and init=/bin/sh in the boot arguments drops you to a root shell, where the per-device key and certificate sit in /mnt/res/vapp/certs/ as ordinary files. Certificates are pinned to their AWS region, the closest thing here to a limit: a key lifted in one region only reaches that region's devices. Reaching another region takes another certificate, provisioned there, and carrying the same broken policy. Amazon has an audit check for this exact policy shape. Device Defender, AWS's IoT fleet auditing service, flags device policies granting publish or subscribe on $aws/things/* instead of pinning the topic to the connecting device with ${iot:Connection.Thing.ThingName}. It appears as IOT_POLICY_OVERLY_PERMISSIVE_CHECK, and AWS rates it critical, warning in its documentation that a compromised certificate carrying such a policy lets an attacker "read or modify shadows, jobs, or job executions for all your devices." Not every certificate is a skeleton key. A vacuum whose certificate carries the broken policy is an attacker's key. Any vacuum that runs Exec_Command is a target, whether or not its own certificate is scoped correctly. The AV1102ARUS is a target and not a key: its certificate was scoped correctly and could not wildcard-subscribe. Its firmware was several years newer. He reads that as a provisioning fix that never reached the older fleet's certificates. That is why the cross-model shell worked, and why his claim that every internet-connected Shark vacuum is vulnerable needs splitting in two. The headline on his post says millions. The figure he verified is narrower. Watching one AWS region for 24 hours, tokay0 counted 1,517,605 unique Shark serial numbers, of which 673,816, or 44%, emitted an Exec_Response, which he treats as confirmation that the device runs the command handler. Those are devices observed replying, not devices tested or compromised, and he says the true number is likely higher. Four Months and Counting By tokay0's account of the correspondence, he contacted SharkNinja on March 1 and sent details on March 11. The company acknowledged receipt the next day, told him on April 27 that the report was under review, and on July 3 said it would send a confirmed completion date by Friday, July 10. No email arrived. He published on July 13. He says the vendor downplayed the severity and questioned whether "a CVE is appropriate." On IoT reports specifically, SharkNinja's published vulnerability disclosure policy commits the company to "provide regular updates until the reported vulnerability is resolved." The same policy asks researchers to stay quiet until the company confirms a fix or authorizes disclosure in writing. SharkNinja had published nothing on the flaw as of Thursday. The Hacker News has reached out to the company for comment on the patch status and the disclosure timeline, and will update this story with any response. There is also no CVE. He asked MITRE's CNA of last resort, the assigner that handles vulnerabilities no vendor CNA covers, for an ID on June 11 and had heard nothing by the time he published. No identifier, no CVSS, no advisory: nothing for a vulnerability management program to key on. The Fix Is Server-Side The fix is not the owner's to install. It lives in SharkNinja's AWS account, not the robot's firmware. Per AWS's remediation guidance, a non-compliant policy is replaced by pushing a scoped version with CreatePolicyVersion and the setAsDefault flag, which makes that version operative for every certificate using the policy. No firmware rollout required. Reissuing the certificates properly, which tokay0 recommended in March, is the longer job behind that. Until SharkNinja does one or the other, the only mitigation available to an owner is to disconnect the vacuum from Wi-Fi. That ends app control, scheduling, and maps, and turns the product back into a vacuum. tokay0 withheld his scripts while the flaw is live. He judged his other findings too minor to write up. He never examined the rest of SharkNinja's connected lineup either, the smart grills and the wireless meat probes, which he says are probably vulnerable too. Those products come from the same company whose policy promises regular updates until a flaw is resolved. Four months on, this one is not. Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post. SHARE     Tweet Share Share Share SHARE  Access Control, AWS security, Cloud security, Data Exposure, device security, iot security, network security, Privacy, remote code execution, Vulnerability ⚡ Top Stories This Week 16-Year-Old Linux KVM Flaw Lets Guest VMs Escape to Host on Intel and AMD x86 Systems BeyondTrust Patches Critical Auth Bypass Flaws in Remote Support and PRA Court Filing Reveals Windows Device ID Helped FBI Trace Alleged Scattered Spider Hacker Rogue Agent Flaw Could Have Let Attackers Hijack Google Dialogflow CX Chatbots RedWing MaaS Packages Android Bank Fraud as a Telegram Rental Service 15-Year-Old GhostLock Flaw Enables Root and Container Escape on Most Linux Distros GitHub Copilot Refuses Harmful Requests in Chat, Then Writes Them in Code New HalluSquatting Attack Could Trick AI Coding Assistants Into Installing Botnet Malware GhostApproval Symlink Flaws Could Let Malicious Repos Run Code in AI Coding Agents Top AI Agents Built to Catch Malicious Code Can Be Tricked Into Running It Meta's New AI Image Tool Lets Others Use Your Public Instagram Photos in AI Images ThreatsDay: Cloud Bucket Hijacking, Windows LPE Chain, Global Fraud Bust + 17 More Stories Dormant GitHub Accounts Help Attackers Blend In While Mapping Corporate Orgs Attackers Exploit 'Ill Bloom' Vulnerability to Drain Over $5 Million From Cryptocurrency Wallets Unpatched XRING Flaw in XQUIC Lets Remote Clients Crash HTTP/3 Servers Researcher Details WhatsApp-to-Host Attack Chain Using Three OpenClaw Flaws New TrojPix Attack Leaks Data From Air-Gapped Systems via Video Cable Emissions Unpatched Flaws Disclosed in Filesystem Bundled Into Millions of Embedded Devices New "Bad Epoll" Linux Kernel

Indicators of Compromise

• malware — Shark RV2320EDUS firmware vulnerability
• mitre_attack — T1021 - Remote Services
• mitre_attack — T1555 - Credentials from Password Stores
• mitre_attack — T1040 - Network Sniffing

Entities