VicOne a identifié 28 failles zero-day en moins de deux jours, grâce à une recherche assistée par IA menée sur des logiciels et des outils qui font vivre l'écosystème de l'IA physique. Parmi les projets concernés figurent des développements de Google, NVIDIA et Meta, entre autres. Ces vulnérabilités zero-day en robotique n'ont été qualifiées de zero-day qu'à l'issue d'une première validation.
Ce décompte n'est pas définitif. Il peut évoluer après examen par les éditeurs et les autorités chargées des vulnérabilités, et certaines des failles n'ont pas encore d'identifiant CVE. La divulgation coordonnée est toujours en cours : le détail de chaque faille n'a donc pas été publié.
Ce que couvrent ces découvertes
Beaucoup des outils touchés servent à entraîner, simuler, tester et exploiter des robots. Cela les distingue d'une faille dans le firmware d'un seul robot. Une faiblesse dans un outil d'entraînement ou de simulation peut influencer les modèles qu'une équipe construit, les résultats de test auxquels elle se fie, et les instructions qui finissent par atteindre une machine.
VicOne a classé les failles selon trois étapes du cycle de vie d'un robot : développement et entraînement, simulation et validation, déploiement et exécution. Dans cet ensemble, 75 % des failles concernaient des outils de développement, d'entraînement, de simulation ou de validation. L'essentiel de l'exposition se situe donc dans les étapes que traverse un robot avant d'être déployé.
La rapidité compte à cause de ce qu'est un zero-day : une faille jusque-là inconnue, pour laquelle aucun correctif n'existe. Selon VicOne, l'IA peut accélérer certaines phases de la recherche de vulnérabilités, notamment l'analyse du code, le suivi des échanges entre systèmes et la vérification qu'une faiblesse présumée est exploitable. L'entreprise ajoute que des attaquants pourraient recourir à des capacités similaires. Une découverte plus rapide ne signifie pas qu'une attaque a eu lieu, mais les équipes peuvent disposer de très peu de temps pour déterminer si elles utilisent les logiciels concernés et ce qu'un attaquant pourrait atteindre ou modifier.
Trois étapes, trois types d'exposition
VicOne décrit un scénario pour chaque étape. Aucun n'est présenté comme un résultat démontré pour chacune des failles. Les effets réels dépendent de l'accès de l'attaquant, de la conception du système, et de l'existence d'autres garde-fous empêchant les modifications d'atteindre le comportement physique.
Au stade du développement et de l'entraînement, une équipe peut télécharger un modèle préentraîné pour l'adapter à son robot. Charger un fichier malveillant pourrait donner à un attaquant accès au système d'entraînement, et donc la possibilité d'altérer les données d'entraînement ou le modèle. Un modèle manipulé pourrait se comporter normalement lors des tests courants, puis réagir de façon incorrecte face à un objet, une scène ou une commande précise après son déploiement.
Au stade de la simulation et de la validation, l'importation d'une scène ou d'un modèle de robot compromis pourrait donner à un attaquant accès à l'environnement de simulation. Avec un contrôle suffisant, il pourrait modifier les mesures des capteurs simulés, les conditions physiques ou les résultats des tests. Un robot pourrait alors réussir des tests qui auraient dû révéler un comportement dangereux, et l'équipe l'approuverait sur la foi de preuves trompeuses.
Au stade du déploiement et de l'exécution, un attaquant pourrait modifier des fichiers qui influencent la planification de trajectoire, ou envoyer des données cartographiques malveillantes qui font planter l'écran de supervision d'un opérateur. La compromission d'un poste de téléopération pourrait aussi mettre en danger les instructions envoyées au robot. Selon les protections en place, ces faiblesses pourraient modifier les mouvements ou empêcher les opérateurs de voir ce qui se passe.
Une démonstration sur l'arrêt à distance et le problème des correctifs
Dans une démonstration distincte, des chercheurs de VicOne ont exploité une vulnérabilité pour empêcher le fonctionnement de la commande d'arrêt à distance d'un robot. Le cas est plus restreint que l'ensemble des 28 failles, mais il montre une fonction de protection mise en échec par le logiciel qui la soutient.
VicOne soutient aussi qu'un correctif publié ne met pas fin au travail. Les équipes doivent encore identifier les systèmes concernés, vérifier la compatibilité et s'assurer que la mise à jour préserve le comportement attendu. Un test réussi auparavant reste un élément utile, mais une faiblesse nouvellement découverte peut mettre en jeu des conditions que ce test n'a jamais examinées.
L'entreprise propose trois questions. Où le logiciel concerné est-il utilisé, y compris sur les postes d'entraînement, dans les environnements de simulation et sur les robots déployés ? Que pourrait modifier la faiblesse : les modèles, les résultats de test, la visibilité des opérateurs ou le comportement du robot ? Comment vérifier la protection, c'est-à-dire à la fois que le correctif referme la faille et que le système mis à jour fonctionne toujours comme prévu ? Lorsqu'une mise à jour immédiate n'est pas envisageable, elle indique que les équipes devront peut-être recourir à des mesures provisoires, comme restreindre l'accès à un service touché le temps de préparer un correctif validé.
Ce que cela implique pour le secteur, et ce qui reste à prouver
L'enseignement le plus utile de ces découvertes tient à leur localisation. La sécurité des robots est souvent abordée sous l'angle de la machine sur la chaîne de production ou sur le terrain. Ici, la plupart des faiblesses signalées se trouvent en amont, dans les outils qui déterminent ce qu'un robot apprend et s'il est jugé sûr. Un environnement de test compromis pose un problème particulier : il peut fausser les preuves sur lesquelles repose la validation de sécurité, sans aucun défaut visible sur le robot lui-même.
L'ensemble touche aussi des projets de grandes organisations très largement utilisés, ce qui laisse penser que l'exposition ne se limite pas à des logiciels confidentiels. Les équipes qui s'appuient sur des outils open source partagés héritent des failles qu'ils contiennent, et ne les suivent pas forcément comme faisant partie de leur surface d'attaque.
Plusieurs points restent non prouvés. Les 28 failles résultent de la validation initiale de VicOne elle-même, publiée dans un texte qui fait aussi la promotion des produits de l'entreprise, et aucun tiers indépendant n'a confirmé ce décompte. La source n'indique ni la gravité de chaque faille, ni combien sont exploitables dans un déploiement type, ni si l'une d'elles a servi lors d'une attaque. Les scénarios décrivent des conséquences possibles, non des conséquences démontrées.
L'affirmation sur la vitesse manque elle aussi d'un point de référence. Trouver 28 candidats zero-day en moins de deux jours est un chiffre frappant, mais la source ne le compare pas au temps qu'exigerait une recherche manuelle classique sur les mêmes logiciels. Elle ne précise pas non plus la part du travail effectuée par l'IA et celle des chercheurs. Ce chiffre étaye l'idée, plus modeste, qu'une recherche assistée par IA peut faire remonter rapidement de nombreux candidats. Il ne prouve pas que ce rythme vaut aussi pour des vulnérabilités confirmées, corrigées et divulguées.
Il faudra surveiller la suite du processus de divulgation. À mesure que les éditeurs examineront ces failles, le décompte final, l'attribution des CVE et les correctifs montreront combien de ces vulnérabilités zero-day en robotique se confirment, et à quelle vitesse les projets concernés pourront livrer des correctifs que les équipes de robotique sont en mesure de valider.
