Unpatched Shark vacuums: regional root, no CVE, no patch

On Monday, a researcher publishing as tokay0 posted the writeup SharkNinja hadn’t shipped a patch for. The bug is in the AWS IoT device certificate baked into Shark robot vacuums: it lets any owner subscribe to and publish on message topics belonging to any other Shark vacuum in the same AWS region. Root command execution on other people’s vacuums, live camera feed, house floor plan, Wi-Fi password in plaintext. Coverage from The Hacker News on Wednesday confirmed no patch is out. SharkNinja missed its own promised update date and reportedly asked whether a CVE was “appropriate,” which is not a question a responding vendor gets to ask.

What actually changed

The vulnerability class is boring in the way most consumer-IoT failures are boring: an over-permissive AWS IoT policy attached to the device’s client certificate. tokay0’s report — reproduced in the Hacker News piece — pulls the certificate from a Shark RV2320EDUS’s flash, then uses it against an AV1102ARUS on the same AWS region. The policy grants subscription on $aws/things/#, a wildcard covering every device the region’s MQTT broker knows about, rather than the per-thing scope that AWS’s own IoT Device Defender check — IOT_POLICY_OVERLY_PERMISSIVE_CHECK, critical severity — is built to catch. AWS has documented this misconfiguration and its fix for years. Shark shipped it anyway.

What that gets an attacker, per tokay0’s writeup:

• Live camera feed from the vacuum’s onboard cameras
• The stored floor plan of the house
• The Wi-Fi SSID and password, in plaintext, as the vacuum publishes them for provisioning
• Drive commands issued to the vacuum’s motors

I’m not walking through the topic-hijack mechanics beyond that; the researcher’s post has them, and if you’re the AWS IoT team at another vendor you should be reading that post today anyway. The point of this article isn’t to teach the exploitation. It’s to say the class is the failure — an over-permissive IoT policy shipped into a consumer device with a camera in it — and it’s caught by tooling AWS has offered the vendor the whole time.

Disclosure timeline, from tokay0’s post:

• March 1, 2026 — first contact with SharkNinja
• March 11 — full report submitted
• March 12 — vendor acknowledges
• April 27 — flagged “under review”
• July 3 — vendor commits to a completion date by July 10
• July 10 — no update
• June 11 — researcher requests a CVE ID from MITRE’s ADP CNA of last resort, no response received by publication
• July 13 — public disclosure via tokay0’s blog
• July 16 — no patch confirmed

SharkNinja’s published vulnerability disclosure policy promises “regular updates until the reported vulnerability is resolved.” The response reported by tokay0 does not match that policy. Neither does asking whether a CVE is appropriate on a bug that returns a plaintext Wi-Fi password to any device on the same regional broker.

What to do

The honest timeline for this one is: SharkNinja hasn’t committed to a fix, so the mitigation is on you.

1. If you own a Shark robot vacuum with a camera, unplug it and take it off Wi-Fi today. Not “after the next firmware update,” not “when I get around to it.” The Wi-Fi password on that device is retrievable by any other Shark owner in your AWS region right now. That’s not a hypothetical PoC — it’s the demonstrated capability in tokay0’s writeup.
2. Rotate the Wi-Fi password on the network the vacuum was joined to. If you skip this and just take the vacuum offline, the credential sitting in someone else’s captured MQTT traffic is still the credential for your home Wi-Fi. Rotate the PSK and rejoin the devices you care about.
3. Enterprise angle: your users have these on their home networks, and their laptops are on those networks. If your WFH population plugs into the corporate VPN from a household segment shared with a Shark robot vacuum, the “just an IoT toy” framing doesn’t hold. This is a real path to a Wi-Fi password, and from there to whatever your users have running on that network. It doesn’t require the attacker to physically touch the vacuum.
4. Do not wait for the CVE ID before treating this as real. MITRE’s CNA of last resort hasn’t answered the researcher, and the vendor is contesting whether a CVE is warranted. There is no ID to grep for and there won’t be one this week. The advisory is tokay0’s post; that’s the reference.
5. AWS IoT teams at other vendors: run the Device Defender audit against your own fleet this week. IOT_POLICY_OVERLY_PERMISSIVE_CHECK is exactly the finding here, and Shark is not the only vendor shipping devices with wildcard $aws/things/# subscriptions on production certificates. Catch it in your own fleet before someone else catches it for you.

Priority call

This does not rank above the Oracle EBS Payments KEV addition or the SharePoint chain CISA named with a July 17 deadline on this week’s enterprise queue. Those are being actively exploited; this is a public disclosure without confirmed in-the-wild abuse yet. But it ranks above every other bug on any list you keep for your household, and it belongs on the “what our users have at home” section of the risk register if you keep one. Consumer-IoT failures are enterprise problems the moment the shared network is a jumping-off point, and this class of over-permissive AWS IoT policy is common enough that the “just a vacuum” reflex is what the industry keeps getting wrong.

If Shark ships a firmware update this week, that changes the recommendation to “apply it.” Until then, unplug it.

Track future IoT and cloud-backend disclosures at /topics/threat-intel/.

Sourcing

• tokay0. Millions of Shark vacuums vulnerable to RCE, 2026-07-13.
• The Hacker News. Unpatched Shark Vacuum Flaw Could Let Attackers Control Other Vacuums Region-Wide, 2026-07-16.
• SharkNinja. Vulnerability Disclosure Policy.
• AWS. IoT Device Defender — Overly permissive IoT policy check.
• MITRE. CVE Program partner information.