Security researcher “tokay0” recently published a serious vulnerability affecting Shark robot vacuums. A certificate extracted from one compromised Shark robot vacuum could be used to access other devices, exposing live camera feeds, stored home maps and Wi-Fi credentials held in plaintext. During a 24-hour observation, the researcher identified more than 1.5 million Shark serial numbers in one AWS region, with approximately 674,000 devices responding to a command probe.
Edwin Shuttleworth, Lead Penetration Tester and Security Researcher at Finite State, offered the following comments:
“This is a classic authentication-versus-authorization failure. The certificate issued to each device correctly authenticated the holder of that device’s private key. An attacker who had fully compromised a vacuum could extract the key and authenticate as that legitimate device. The cloud backend, however, did not correctly enforce authorization. As a result, a validly authenticated device was permitted to access data and perform actions involving other devices it should not have been able to reach.
“This is a common security design mistake: treating a successfully authenticated identity as broadly trusted instead of applying narrowly scoped, per-device permissions. Security professionals reviewing IoT systems should verify both that device identities are unique and that each identity is restricted to its own resources and required operations.
“Manufacturers must assess the complete connected-product environment because the most serious vulnerabilities often arise from interactions between multiple layers rather than a single isolated flaw. This case illustrates that clearly. Weaknesses in the device’s boot and debug protections allowed an attacker to obtain privileged access to the vacuum and extract its credentials. Those credentials were then accepted by the cloud service and granted access to MQTT resources belonging to other devices. Finally, dangerous command-handling functionality allowed cloud-delivered messages to result in remote code execution.
“Individually, each weakness might have appeared limited. Together, they created an attack chain that turned the compromise of one physical device into a potential fleet-scale compromise. Testing firmware, cloud permissions, credential storage or backend infrastructure only in isolation could therefore miss the true severity of the vulnerability.
“Manufacturers should avoid storing sensitive information that is not necessary for the device’s function or business operations and should avoid transmitting sensitive information to the cloud when it is not needed. When information must be transmitted, robust encryption should be used to prevent access by unauthorized parties. Security testing must also be performed early and regularly to prevent compromises like this and minimize their impact when they occur.”
This is precisely why I am working towards making all of my IoT gear, of which I don’t have a lot, not talk to the Internet. My concern is that I don’t know who they are talking to. That is a huge problem as evidenced by this report.
Shark robot vacuum flaw exposes fleet-wide IoT risks
Posted in Commentary with tags IoT on July 22, 2026 by itnerdSecurity researcher “tokay0” recently published a serious vulnerability affecting Shark robot vacuums. A certificate extracted from one compromised Shark robot vacuum could be used to access other devices, exposing live camera feeds, stored home maps and Wi-Fi credentials held in plaintext. During a 24-hour observation, the researcher identified more than 1.5 million Shark serial numbers in one AWS region, with approximately 674,000 devices responding to a command probe.
Edwin Shuttleworth, Lead Penetration Tester and Security Researcher at Finite State, offered the following comments:
“This is a classic authentication-versus-authorization failure. The certificate issued to each device correctly authenticated the holder of that device’s private key. An attacker who had fully compromised a vacuum could extract the key and authenticate as that legitimate device. The cloud backend, however, did not correctly enforce authorization. As a result, a validly authenticated device was permitted to access data and perform actions involving other devices it should not have been able to reach.
“This is a common security design mistake: treating a successfully authenticated identity as broadly trusted instead of applying narrowly scoped, per-device permissions. Security professionals reviewing IoT systems should verify both that device identities are unique and that each identity is restricted to its own resources and required operations.
“Manufacturers must assess the complete connected-product environment because the most serious vulnerabilities often arise from interactions between multiple layers rather than a single isolated flaw. This case illustrates that clearly. Weaknesses in the device’s boot and debug protections allowed an attacker to obtain privileged access to the vacuum and extract its credentials. Those credentials were then accepted by the cloud service and granted access to MQTT resources belonging to other devices. Finally, dangerous command-handling functionality allowed cloud-delivered messages to result in remote code execution.
“Individually, each weakness might have appeared limited. Together, they created an attack chain that turned the compromise of one physical device into a potential fleet-scale compromise. Testing firmware, cloud permissions, credential storage or backend infrastructure only in isolation could therefore miss the true severity of the vulnerability.
“Manufacturers should avoid storing sensitive information that is not necessary for the device’s function or business operations and should avoid transmitting sensitive information to the cloud when it is not needed. When information must be transmitted, robust encryption should be used to prevent access by unauthorized parties. Security testing must also be performed early and regularly to prevent compromises like this and minimize their impact when they occur.”
This is precisely why I am working towards making all of my IoT gear, of which I don’t have a lot, not talk to the Internet. My concern is that I don’t know who they are talking to. That is a huge problem as evidenced by this report.
Leave a comment »