VicOne trouve 28 zero-days dans la robotique en moins de 48 heures : l'IA accélère la chasse aux failles (et les masque)

VicOne trouve 28 zero-days dans la robotique en moins de 48 heures : l'IA accélère la chasse aux failles (et les masque)

🔎 Deux jours, 28 failles : la recherche de vulnérabilités vient de changer d'échelle

VicOne, la société de cybersécurité dédiée à la mobilité née de Trend Micro, a annoncé avoir découvert 28 vulnérabilités zero-day dans des logiciels de robotique et d'IA physique — dont des projets liés aux écosystèmes de Google, NVIDIA et Meta — en moins de 48 heures, grâce à du fuzzing assisté par IA. Un rythme que des équipes expérimentées mettent traditionnellement plusieurs mois à atteindre.

Pourquoi c'est important maintenant ? Parce que deux courbes se croisent. D'un côté, la robotique entre dans sa phase d'industrialisation : plus de 4 millions de robots industriels en opération dans le monde (IFR, 2024) et un marché des humanoïdes projeté à 38 milliards de dollars d'ici 2035 (Goldman Sachs, 2024). De l'autre, les modèles agentiques compressent le temps de découverte de failles de plusieurs semaines à quelques heures.

Le chiffre de 28 n'est pas le plus intéressant. La répartition, si : 75 % de ces failles ne touchent pas les robots déployés, mais les outils de développement, d'entraînement et de simulation qui servent à les fabriquer. Autrement dit, l'usine à robots est plus exposée que les robots.

L'essentiel

• 28 zero-days en moins de 48 heures, découverts par VicOne via du fuzzing assisté par IA dans des logiciels de robotique et d'IA physique liés à Google, NVIDIA et Meta, comme le rapporte The Robot Report.
• 75 % des failles concernent les outils de dev, d'entraînement et de simulation, pas les robots en production.
• Impacts démontrés : une commande d'arrêt à distance neutralisée, des pipelines d'entraînement empoisonnables, des simulateurs capables de renvoyer des résultats falsifiés.
• Certaines failles n'avaient pas de CVE à la publication : la divulgation coordonnée ne suit plus le rythme de découverte.
• Conseil central de VicOne : re-vérifiez les correctifs contre le comportement attendu, pas seulement contre un numéro de version.

Outils recommandés

Si vous développez ou exploitez des systèmes robotiques, ces outils permettent de reproduire ce type de chasse — strictement en environnement isolé.

28 zero-days en deux jours : ce que VicOne a réellement fait

VicOne n'a pas trouvé « une » faille : il en a trouvé 28, en utilisant des LLM pour guider le fuzzing — la technique qui consiste à bombarder un programme d'entrées malformées jusqu'à le faire planter — contre des logiciels de robotique et d'IA physique.

La différence avec le fuzzing classique tient en une phrase : le fuzzing traditionnel mute des entrées au hasard ou selon la couverture de code, aveugle au sens. Un LLM, lui, comprend les formats, lit la documentation, génère des entrées structurées et cible les parseurs les plus prometteurs. Moins de bruit, plus de crashs réellement exploitables. Résultat : 28 vulnérabilités uniques en moins de deux jours, détaillées par AI Weekly.

Le périmètre compte autant que le chiffre. Les failles touchent des composants liés aux écosystèmes Google, NVIDIA et Meta : simulateurs, frameworks d'entraînement, outils de développement. La pile logicielle qui fait naître les robots, pas seulement celle qui les fait tourner.

Mon avis : ce résultat dit moins de choses sur la robotique que sur l'économie de la recherche de failles. Hier, la ressource rare était l'expertise — savoir où chercher, comment écrire un cas de test pertinent. Aujourd'hui, la ressource rare devient le temps de correction. Et ça, aucun éditeur ne l'a compressé.

75 % des failles ne touchent pas les robots, mais l'usine qui les construit

L'enseignement central de cette recherche, c'est que la surface d'attaque critique de la robotique s'est déplacée en amont : vers les simulateurs, les frameworks d'entraînement et les outils de développement.

Rappel du fonctionnement moderne : les politiques motrices des robots s'apprennent en simulation, puis sont déployées sur le matériel réel — le fameux sim-to-real. Deux conséquences de sécurité en découlent directement.

Un simulateur capable de renvoyer des résultats falsifiés, c'est une certification truquée : vous validez un comportement sur des données manipulées, et ce comportement part sur le terrain. Un pipeline d'entraînement empoisonnable, c'est pire : le modèle apprend la mauvaise leçon à votre insu, et personne ne le voit dans les métriques finales.

Ce déplacement de la surface d'attaque arrive au pire moment. L'IA physique passe full-stack — Genesis AI enchaîne modèle fondateur GENE-26.5 et mains robotiques humanoïdes, comme on le voit dans notre analyse de l'annonce Genesis AI — et chaque couche ajoutée à la pile élargit mécaniquement la surface à attaquer.

Pendant des années, la question sécurité de la robotique se résumait à « le robot peut-il être piraté ? ». La bonne question est désormais : « qui peut corrompre ce qui a appris au robot ? ». Franchement, presque personne n'a d'answer prêt.

Arrêt d'urgence neutralisé, entraînement empoisonné, simulation falsifiée : les trois impacts qui comptent

Trois scénarios d'impact ont été démontrés par VicOne, et chacun frappe un point de contrôle différent de la chaîne robotique.

La commande d'arrêt à distance neutralisée. Un attaquant capable d'interférer avec un arrêt d'urgence ne vole pas des données : il crée un risque physique. Dans un entrepôt ou une usine, ce n'est pas un problème de conformité, c'est un enjeu de sécurité des personnes.

Le pipeline d'entraînement empoisonné. Injecter des données malveillantes dans l'entraînement produit un modèle qui se comporte normalement dans 99 % des cas et dangereusement dans le 1 % restant. Détecter ce genre de porte dérobée après coup est extrêmement coûteux.

Le simulateur qui ment. Un simulateur qui renvoie des résultats falsifiés transforme la validation en théâtre : les tests passent, les métriques sont vertes, et rien ne garantit que le robot réel se comportera comme validé.

Ces failles amont ne rendent pas les robots déployés inoffensifs pour autant — loin de là. L'injection de commandes découverte dans le module de charge du Unitree Go2 (CVE-2026-115995), sur le port 9610, le prouve : les robots du commerce portent leurs propres failles directes. VicOne ajoute simplement un second front : la chaîne qui fabrique les comportements est aussi attaquable que le robot lui-même.

Sur l'e-stop, soyons directs : un chemin logiciel qui commande un arrêt d'urgence devrait être traité avec le niveau d'exigence de l'avionique. Le considérer comme un composant secondaire, c'est de la négligence organisée.

L'IA change-t-elle vraiment la recherche de failles ? Oui, sur trois plans — pas sur tous

Oui, l'IA change la recherche de failles : sur la vitesse, sur le coût d'entrée et sur le passage à l'échelle de l'exploitation. Non, elle ne résout ni la validation de l'exploitabilité ni la coordination de la divulgation.

1. La vitesse, d'abord

La compression temporelle est désormais documentée partout. Le red teaming d'agents IA est passé de plusieurs semaines à quelques heures, et VicOne applique la même compression au bug hunting : 28 zero-days en 48 heures. Ce n'est pas une amélioration incrémentale, c'est un changement de régime.

2. Le coût d'entrée, ensuite

Un LLM lit le code, la documentation, génère des entrées structurées et trie les crashs. Des équipes de deux ou trois personnes font aujourd'hui ce que demandait une dizaine de spécialistes. Les modèles agentiques de pointe — GPT-5.5 d'OpenAI, Claude Opus 4.7 (Adaptive) d'Anthropic, Gemini 3 Pro Deep Think de Google — repoussent le plafond de ce qui est trouvable automatiquement. Et les modèles auto-hébergés comme Kimi K2.6 (Moonshot AI) ou GLM-5 (Z.AI) permettent aux laboratoires de travailler sur du code sensible sans l'envoyer à des API tierces.

3. Le passage à l'échelle de l'exploitation, enfin

La découverte n'est que la moitié de l'équation. GreyNoise a documenté la première campagne mondiale d'exploits générés par des agents IA : Codex pilotait un modèle DeepSeek pour déployer des exploits zero-day PaperCut contre 395 organisations. Découverte et exploitation s'industrialisent en même temps. C'est cette combinaison qui doit inquiéter, pas l'une ou l'autre isolément.

Ce qui ne change pas (encore)

Valider qu'un crash est exploitable, coordonner avec les éditeurs, écrire et déployer un correctif : tout cela reste humain, lent et séquentiel. L'IA trouve plus vite qu'on ne corrige — et l'écart entre les deux vitesses ne fait que se creuser.

L'IA n'invente pas les vulnérabilités ; elle supprime le temps mort. Et ce temps mort, jusqu'ici, c'était votre marge de manœuvre.

Des failles sans CVE : le maillon masqué de la divulgation

Plusieurs des 28 vulnérabilités signalées par VicOne n'avaient pas de CVE attribuée au moment de la publication. C'est peut-être le détail le plus sous-estimé de toute l'annonce.

Le processus CVE — demande, assignation, coordination avec l'éditeur, publication — prend des semaines, parfois des mois. L'IA compresse la découverte, pas l'administration. Il en résulte une classe croissante de failles réelles, démontrées, mais invisibles pour vos scanners, vos tableaux de conformité et vos SOC.

Le « masquage » évoqué dans le titre a trois visages concrets.

Premier visage : l'invisibilité administrative. Sans CVE, la faille n'existe pas pour vos outils de gestion de vulnérabilités — alors qu'elle existe très bien pour un attaquant motivé.

Deuxième visage : le correctif superficiel. Un patch peut supprimer le symptôme sans corriger la cause, surtout quand il est produit à la chaîne. VicOne insiste lourdement sur ce point : re-vérifiez les correctifs contre le comportement attendu. Un correctif validé « à l'aveugle » ne prouve rien.

Troisième visage : la fausse confiance. « On a fuzzé avec de l'IA, donc c'est bon » — non. Le fuzzing trouve des crashs ; il ne démontre jamais l'absence de failles. Confondre les deux, c'est remplacer une ignorance assumée par une ignorance certifiée.

Un correctif qui ne restaure pas le comportement attendu n'est pas une correction, c'est un pansement. Et l'IA, en accélérant tout le cycle, multiplie les occasions d'en poser.

Sécuriser votre stack robotique : cinq mesures à prendre cette semaine

Trois priorités ressortent de cette recherche : cartographier la chaîne dev/sim/entraînement, la cloisonner, et vérifier les correctifs par le comportement — pas par le numéro de version.

1. Inventoriez vos outils de simulation et d'entraînement comme des actifs de production. Ils produisent le comportement de vos robots ; un outil compromis, c'est un robot compromis par procuration. S'ils ne figurent pas dans votre CMDB, c'est qu'ils sont gérés par personne.

2. Cloisonnez. Réseau de laboratoire et réseau de production doivent être séparés, avec des règles explicites. Les chemins logiciels de l'arrêt d'urgence doivent être isolés du reste et testés régulièrement.

3. Vérifiez les correctifs fonctionnellement. Écrivez des jeux d'essai de régression sur les comportements de sécurité — l'e-stop fonctionne, les sorties du simulateur restent plausibles — et faites-les passer après chaque mise à jour. C'est exactement la vérification que VicOne demande.

4. Automatisez le fuzzing en CI. OSS-Fuzz ou AFL++ sur vos parseurs, vos interfaces de communication et vos points d'entrée de données. Mieux vaut trouver le crash avant un agent IA hostile.

5. Isolez physiquement vos environnements de test. Un VPS dédié — par exemple chez Hostinger — plutôt qu'une infrastructure partagée, et jamais de cible de fuzzing sur le réseau de production. Le coût de la séparation est dérisoire comparé à celui d'un incident.

Le réflexe sim-to-real

Ce que vous certifiez en simulation finit dans le réel. Protégez l'intégrité de votre simulateur comme celle de vos données de production : contrôle d'accès, journaux, vérification d'intégrité des sorties. Un simulateur non protégé n'est pas un outil de dev, c'est un cheval de Troie en sursis.

❌ Erreurs courantes

Erreur 1 : « Nos robots ne sont pas connectés à Internet, on n'est pas concernés »

Le chiffre de 75 % démonte cet argument : on n'attaque plus seulement le robot, on attaque ce qui l'a fabriqué. Un modèle entraîné sur des données empoisonnées arrive chez vous « propre », certifié par un simulateur falsifié. La solution : cartographier la chaîne d'approvisionnement du comportement — modèles, données, simulateurs — et pas seulement celle du matériel.

Erreur 2 : Prendre le correctif pour la correction

Un patch déployé n'est pas une faille corrigée. VicOne le répète : vérifiez le comportement attendu, car un correctif peut masquer le symptôme sans toucher la cause. La solution : des tests fonctionnels de sécurité après chaque mise à jour, avec des critères écrits avant l'application du patch, pas après.

Erreur 3 : Confondre « pas de CVE » et « pas de risque »

L'assignation d'une CVE suit un calendrier administratif, pas la réalité technique. Des failles démontrées peuvent rester invisibles des scanners pendant des semaines. Suivez directement les avis des éditeurs et les recherches comme celles de VicOne, en complément — jamais en remplacement — de vos bases de vulnérabilités.

Erreur 4 : Croire que l'IA de votre côté rattrape l'IA de l'attaquant

Vos outils trouvent plus vite, mais votre organisation corrige au même rythme qu'avant. Si vous traitez les findings dans l'ordre d'arrivée, vous noyez vos équipes sous le volume. Priorisez par exploitabilité et impact sécurité : l'e-stop avant la fuite de logs, toujours.

❓ Questions fréquentes

Qu'est-ce qu'un zero-day, concrètement ?

Une vulnérabilité inconnue de l'éditeur au moment de sa découverte ou de son exploitation, donc sans correctif disponible. VicOne a signalé 28 failles de ce type à leurs éditeurs respectifs. Le terme ne préjuge pas de la gravité : un zero-day peut être anodin comme critique, et tout dépend de l'exploitabilité réelle.

Quels logiciels sont concernés par les 28 failles ?

Des logiciels de robotique et d'IA physique liés aux écosystèmes de Google, NVIDIA et Meta, selon les comptes rendus de The Robot Report et d'AI Weekly. L'essentiel — 75 % — concerne des outils de développement, d'entraînement et de simulation, plutôt que des piles logicielles embarquées dans des robots en production.

Ces failles permettent-elles de prendre le contrôle de robots déployés ?

Pas directement, pour la plupart : elles touchent l'outillage amont. Mais les impacts démontrés — arrêt d'urgence neutralisé, entraînement empoisonné, simulation falsifiée — tracent un chemin indirect vers le réel. Les robots déployés ont par ailleurs leurs propres failles, comme l'injection de commandes du Unitree Go2.

Pourquoi certaines failles n'ont-elles pas de CVE ?

Parce que l'assignation d'un identifiant CVE dépend d'un processus de coordination manuel entre chercheurs, éditeurs et autorités de numérotation. Quand la découverte s'effectue en 48 heures, l'administration ne suit plus. L'absence de CVE ne signifie absolument pas l'absence de vulnérabilité.

L'IA va-t-elle remplacer les chercheurs en sécurité ?

Non, elle change leur productivité et le rapport de force. L'IA accélère la génération d'entrées, le tri des crashs et l'exploration de code, mais la validation de l'exploitabilité, l'éthique de la divulgation et la correction restent humaines. Le vrai risque n'est pas le remplacement : c'est l'asymétrie entre attaquants équipés et défenseurs qui ne le sont pas.

✅ Conclusion

En 48 heures, VicOne a démontré que la question n'est plus de savoir si votre stack robotique contient des failles, mais combien de temps il reste avant qu'un agent IA ne les trouve — et éventuellement les exploite — avant vous. Auditez vos simulateurs et vos pipelines d'entraînement cette semaine : c'est là que se joue désormais la sécurité de vos robots.