A security researcher has disclosed a serious cloud-security flaw affecting Shark robot vacuums that could allow attackers to remotely control devices, access onboard camera feeds, read home maps, and retrieve Wi-Fi passwords in plaintext.
The issue was reported by a researcher using the handle tokay0, who says the flaw was tested only against Shark vacuums he personally purchased. According to the disclosure, the weakness remained unpatched when the research was published.
The most concerning part is that the flaw does not rely on a complex exploit.
No memory corruption.
No password guessing.
No local privilege escalation.
Instead, the issue appears to come from overly broad AWS IoT permissions attached to device certificates.
What Went Wrong
Shark robot vacuums communicate with the cloud using device certificates.
In a properly secured IoT environment, each device certificate should only be allowed to access cloud topics and commands belonging to that specific device.
That did not appear to be the case here.
According to the researcher, a certificate extracted from one Shark vacuum could be used to interact with other Shark vacuums in the same AWS region. The cloud broker accepted commands addressed to devices other than the one that owned the certificate.
This means the problem was not only inside the robot.
It was in the cloud trust model around the fleet.
Why the AWS IoT Policy Matters
AWS IoT supports per-device messaging using topics and device shadows.
A device shadow is a cloud-hosted state document that stores information about a device and allows cloud services or apps to update its desired state.
In this case, the researcher found that commands could be placed into a device shadow field read by the vacuum’s management daemon. If the target model supported the command handler, the robot would execute the instruction.
The root issue was an overly permissive IoT policy.
AWS provides auditing checks for this kind of mistake through AWS IoT Device Defender. One relevant check flags policies that allow broad access to $aws/things/* rather than restricting access to the specific connected device.
AWS considers this kind of policy problem critical because a compromised certificate can potentially allow access to shadows, jobs, or execution data across many devices.
Physical Access Leads to Cloud Impact
The researcher says the certificate could be extracted from a vacuum using physical access.
The device exposed hardware-level access paths that allowed the researcher to reach a root shell and retrieve the per-device certificate and key from the filesystem.
That alone would be concerning, but the real danger comes from what that certificate could do afterward.
A certificate taken from one device reportedly became a key to interact with other devices in the same AWS region.
That turns a local hardware weakness into a cloud-scale fleet risk.
What an Attacker Could Do
According to the disclosure, a vulnerable setup could allow remote commands against other Shark vacuums in the same region.
Potential impact includes:
- controlling the robot
- accessing the onboard camera on supported models
- retrieving maps of the home
- extracting Wi-Fi passwords in plaintext
- running commands on affected devices
- using the device as a foothold inside a home network
The researcher demonstrated the issue across models he owned, including using one device certificate to reach another model and obtain a reverse shell.
For obvious reasons, exploit scripts were withheld while the flaw remained live.
Not Every Device Is A “Key”
The vulnerability has two separate parts.
Some vacuums may act as a key because their certificates are attached to overly broad cloud permissions.
Other vacuums may act as a target because their firmware supports the command handler that executes cloud-delivered instructions.
The researcher found that a newer target model had a properly scoped certificate, meaning it could not be used as a wildcard key. However, it could still be targeted if another device’s poorly scoped certificate was used.
That distinction is important.
The issue is not necessarily that every Shark vacuum can unlock every other Shark vacuum. The risk depends on the certificate policy, region, and whether the target model supports the vulnerable command behavior.
Regional Limits, But Still Serious
The researcher noted one limiting factor: certificates appear to be pinned to an AWS region.
A certificate extracted from a vacuum in one region only reaches devices served by that same region.
That is a meaningful boundary, but it does not remove the risk.
Within one region, the researcher says he observed more than 1.5 million unique Shark serial numbers over a 24-hour period. Of those, more than 670,000 emitted responses consistent with support for the command handler.
These figures represent observed devices, not confirmed compromised devices.
Still, the scale is significant.
Disclosure Timeline Raises Concerns
According to the researcher, SharkNinja was first contacted in March and received technical details shortly afterward.
The company reportedly acknowledged the report and later said it was under review. The researcher says he was promised a confirmed completion date by July 10, but no update arrived.
He published the findings on July 13.
As of the disclosure, there was reportedly no public advisory, no CVE, no CVSS score, and no clear customer-facing mitigation beyond disconnecting devices from Wi-Fi.
That lack of an identifier makes the issue harder for vulnerability-management teams to track.
The Fix Is Mostly Server-Side
This is one of the most important parts of the case.
The immediate fix does not necessarily require every customer to install new firmware.
The most urgent mitigation appears to live in SharkNinja’s AWS IoT configuration.
The company can replace the overly permissive IoT policy with a properly scoped version that restricts each certificate to its own device identity. AWS supports this through policy versioning, allowing a corrected policy to become the default for certificates using that policy.
Longer term, SharkNinja may also need to reissue device certificates and review provisioning across older devices.
But the first step should be tightening the cloud policy.
What Owners Can Do
For individual owners, options are limited.
Because the weakness sits mainly in the vendor’s cloud configuration, customers cannot fully fix it themselves.
The only strong mitigation available to owners is to disconnect the vacuum from Wi-Fi.
That disables cloud control, app features, scheduling, mapping, and remote access, but it also prevents the robot from communicating with the vulnerable cloud infrastructure.
Owners should also consider:
- changing the home Wi-Fi password if exposure is suspected
- removing saved maps where possible
- reviewing app permissions
- checking for firmware updates
- monitoring vendor advisories
- avoiding camera-enabled operation in sensitive areas
The practical problem is that most users will not know whether their device was affected unless the vendor provides clear guidance.
What IoT Vendors Should Learn
This incident is a strong reminder that IoT security is not only about device firmware.
Cloud permissions are just as important.
Vendors should ensure that:
- each device certificate is scoped only to that device
- IoT policies never allow broad wildcard access across the fleet
- device shadows cannot carry dangerous command fields without strict authorization
- command execution paths are minimized or removed
- device certificates are protected on hardware
- firmware does not store sensitive secrets in plaintext
- camera and map access is tightly controlled
- AWS IoT Device Defender or equivalent audits are enabled
- vulnerability disclosure reports receive timely updates
A single overly broad cloud policy can turn one compromised device into a fleet-wide risk.
Final Thoughts
The Shark robot vacuum disclosure shows how dangerous IoT trust mistakes can become.
The device-level issue was serious, but the cloud permission model made it much worse. A certificate extracted from one vacuum could reportedly be used to interact with other vacuums in the same AWS region, and vulnerable targets could accept remote command instructions through cloud device-shadow updates.
For users, the risk includes privacy invasion, camera access, home mapping exposure, Wi-Fi credential theft, and remote control of the device. For vendors, the lesson is clear: IoT security must be enforced at every layer.
Device certificates must be scoped. Cloud policies must be audited. Remote command features must be tightly controlled. And when researchers report fleet-wide risks, disclosure handling needs to be fast, transparent, and customer-focused.
