Une faille critique sur les aspirateurs robots Shark permet d’utiliser un seul certificat volé pour exécuter des commandes root sur d’autres appareils de la même région AWS. Le défaut expose des flux vidéo en direct, des cartes du domicile et des mots de passe Wi‑Fi stockés en clair, sans correctif disponible au 17 juillet 2026.
Le point le plus important tient au mode de correction. Cette vulnérabilité ne demande pas de mise à jour firmware sur le robot. Elle exige une modification côté cloud par SharkNinja, qui avait été alerté dès le 1er mars 2026 et n’avait toujours publié ni patch, ni avis de sécurité officiel, ni CVE à la date de publication.
Faille Shark et AWS IoT : un certificat suffit pour viser toute une région
Le chercheur tokay0 décrit une erreur de configuration dans la politique AWS IoT utilisée par SharkNinja. En clair, le certificat d’authentification d’un robot n’est pas limité à l’appareil qui le porte. Une fois extrait, il peut servir à s’abonner à un trafic bien plus large.
Selon le rapport, ce certificat peut écouter le trafic de flotte et publier des commandes vers n’importe quel appareil servi par le broker AWS de la même région. La limite est géographique. Un certificat récupéré dans une région AWS ne permet pas d’atteindre les robots d’une autre région.
L’exploitation commence par l’extraction du certificat client stocké dans la mémoire flash d’un robot. Le chercheur l’a montré sur un modèle Shark RV2320EDUS. Il mentionne des pins UART exposés parmi les voies d’accès physique possibles.
Ensuite, l’attaque passe par le champ standard Exec_Command du “device shadow” géré par AWS. Un daemon de gestion du robot récupère alors le contenu de ce champ, tant qu’il reste sous 1 000 octets. D’après le rapport, ce daemon transmet directement la charge à une fonction shell, ce qui ouvre la voie à un reverse shell et à l’exécution de commandes en root.
Le point notable est l’accès cross-modèle. Tokay0 dit avoir utilisé le certificat d’un RV2320EDUS pour prendre le contrôle d’un AV1102ARUS Shark IQ Robot Vacuum XL. Il affirme avoir limité ses tests à des appareils achetés par lui-même.
1,5 million de numéros de série observés en 24 heures dans une seule région AWS
L’ampleur potentielle de l’exposition ressort des chiffres collectés sur une seule région AWS. Pendant 24 heures, le chercheur a observé 1 517 605 numéros de série Shark uniques.
Parmi eux, 673 816 appareils, soit environ 44 %, ont répondu à une commande de test via un retour Exec_Response. Ce point mérite une nuance importante. Le rapport ne dit pas que ces centaines de milliers de robots ont été compromis. Il indique qu’ils ont répondu et qu’ils semblent capables d’exécuter ce type de commande.
Le chercheur relie cette capacité à des données très sensibles. Il cite l’accès aux flux caméra en direct, aux cartes du domicile stockées et aux identifiants Wi‑Fi en texte clair. Dans son test, il dit avoir récupéré un flux vidéo live depuis le robot contrôlé.
Pour l’utilisateur, le risque ne se limite donc pas au pilotage du robot. Il touche aussi la vie privée du foyer. Un appareil compromis peut révéler le plan d’un logement et les informations réseau qui y sont associées.
Cette affaire s’inscrit aussi dans un contexte plus large de sécurité des objets connectés. Sur l’actualité high-tech, les défaillances cloud pèsent de plus en plus lourd dans l’évaluation des produits domestiques connectés. Ici, le problème ne vient pas d’un composant obscur. Il vient d’un contrôle d’accès cloud jugé trop large.
Chronologie : signalement en mars 2026, publication en juillet, toujours aucun correctif
La chronologie fournie par le rapport est précise. Tokay0 dit avoir signalé la faille à SharkNinja le 1er mars 2026. L’entreprise a reconnu la réception le 12 mars. Le 27 avril, elle a indiqué que le dossier était “en cours d’examen”.
Le 3 juillet, toujours selon le chercheur, SharkNinja a promis une date d’achèvement au 10 juillet. Cette échéance n’a pas été respectée. Le 16 juillet, faute de correctif, tokay0 a publié publiquement sa méthode. Au 17 juillet 2026, le rapport affirme que la faille restait non corrigée.
Le chercheur reproche aussi à SharkNinja d’avoir minimisé la gravité du problème. Il affirme que l’entreprise a questionné la nécessité d’un CVE. Pourtant, le rapport mentionne une politique de divulgation qui promet des mises à jour régulières jusqu’à la résolution.
À ce stade, aucun CVE n’a été attribué. Aucun avis public de sécurité n’a non plus été publié par le fabricant, selon le rapport. Cette absence complique la communication vers les utilisateurs et les administrateurs de flotte domestique.
Pas de firmware à attendre : la correction AWS doit venir de SharkNinja
Le volet technique est clair sur un point. La correction n’exige pas de mise à jour locale du robot. Elle doit intervenir dans le compte AWS de SharkNinja.
Le rapport indique que le fabricant doit restreindre la politique AWS IoT pour lier chaque certificat à l’appareil concerné. Une autre option consiste à réémettre des certificats correctement limités. Dans les deux cas, l’action se joue côté serveur.
Pour les propriétaires, cela change la lecture de la crise. Attendre un firmware ne suffit pas, puisque le problème principal réside dans le cloud. Tant que la politique n’est pas corrigée, l’exposition persiste à l’échelle de la région concernée.
Le rapport mentionne une seule mesure de mitigation immédiate pour l’utilisateur : déconnecter l’aspirateur du Wi‑Fi. Cette étape coupe l’accès au cloud AWS et réduit le risque d’exploitation à distance. En revanche, elle peut aussi désactiver certaines fonctions connectées du produit.
- Risque principal : exécution de commandes root à distance.
- Données exposées : vidéo live, cartes du domicile, Wi‑Fi en clair.
- Étendue observée : 1 517 605 numéros de série en 24 heures dans une seule région.
- Appareils réactifs : 673 816, soit 44 % des unités observées.
- Mitigation actuelle : déconnexion du Wi‑Fi en attendant un correctif cloud.
Ce que les prochaines semaines impliquent pour les propriétaires de Shark
Le prochain jalon concret reste la publication d’un correctif cloud, ou au minimum d’un avis officiel de SharkNinja. À ce jour, le rapport n’en signale aucun. Pour les utilisateurs, la surveillance doit donc porter sur une éventuelle modification côté service, pas sur une mise à jour firmware visible dans l’application.
En attendant, le message est simple. Si votre robot Shark dépend du cloud, la seule protection immédiate citée par le rapport consiste à le sortir du réseau Wi‑Fi. La situation mérite aussi une attention particulière si le robot embarque une caméra ou conserve des cartes détaillées du domicile.
