VicOne identificó 28 hallazgos de día cero en menos de dos días, mediante investigación asistida por IA sobre software y herramientas que sustentan el ecosistema de la IA física. El conjunto incluye proyectos desarrollados o mantenidos por Google, NVIDIA y Meta, entre otros. Estas vulnerabilidades zero-day en robótica se clasificaron como tales únicamente en la validación inicial.
La cifra no es definitiva. Puede cambiar tras la revisión de los fabricantes y de las autoridades de vulnerabilidades, y algunos de los hallazgos aún no cuentan con números de seguimiento CVE. La divulgación coordinada sigue en curso, por lo que no se han publicado los detalles de cada fallo.
Qué abarcan los hallazgos
Muchas de las herramientas afectadas se usan para entrenar, simular, probar y operar robots. Eso las distingue de un fallo en el firmware de un solo robot. Una debilidad en una herramienta de entrenamiento o simulación puede condicionar los modelos que construye un equipo, los resultados de las pruebas en los que confía y las instrucciones que acaban llegando a una máquina.
VicOne clasificó los hallazgos en tres etapas del ciclo de vida de la robótica: desarrollo y entrenamiento, simulación y validación, y despliegue y ejecución. En este conjunto de investigación, el 75 % de los hallazgos afectaba a herramientas de desarrollo, entrenamiento, simulación o validación. Así, la mayor parte de la exposición se sitúa en los lugares por los que pasa un robot antes de ser desplegado.
La rapidez importa por lo que es un zero-day: un fallo desconocido hasta ahora y sin corrección disponible. VicOne afirma que la IA puede acelerar partes de la investigación de vulnerabilidades, como el análisis de código, el rastreo de cómo se comunican los sistemas y la comprobación de si una debilidad sospechosa se puede explotar. Añade que los atacantes podrían usar capacidades similares. Un descubrimiento más rápido no significa que se haya producido un ataque, pero puede dejar a los equipos poco tiempo para averiguar si usan el software afectado y a qué podría acceder o qué podría modificar un atacante.
Tres etapas, tres tipos de exposición
VicOne describe un escenario para cada etapa. Ninguno se presenta como un resultado demostrado para todos los hallazgos. Los efectos reales dependen del acceso del atacante, del diseño del sistema y de si otras salvaguardas impiden que los cambios lleguen al comportamiento físico.
En desarrollo y entrenamiento, un equipo podría descargar un modelo preentrenado para adaptarlo a su robot. Cargar un archivo malicioso podría dar a un atacante acceso al sistema de entrenamiento y, con ello, la capacidad de alterar los datos de entrenamiento o el modelo. Un modelo manipulado podría comportarse con normalidad en las pruebas rutinarias y luego responder de forma incorrecta ante un objeto, una escena o una orden concretos tras el despliegue.
En simulación y validación, importar una escena o un modelo de robot comprometidos podría dar a un atacante acceso al entorno de simulación. Con suficiente control, podría modificar las lecturas simuladas de los sensores, las condiciones físicas o los resultados de las pruebas. Un robot podría entonces superar pruebas que deberían haber revelado un comportamiento inseguro, y el equipo lo aprobaría con evidencias engañosas.
En despliegue y ejecución, un atacante podría modificar archivos que influyen en la planificación de movimientos, o enviar datos de mapa maliciosos que bloqueen la pantalla de monitorización de un operador. Comprometer un ordenador de teleoperación también podría poner en riesgo las instrucciones enviadas al robot. Según las salvaguardas existentes, estas debilidades podrían alterar el movimiento o dejar a los operadores sin poder ver lo que ocurre.
Una demostración de parada remota y el problema de los parches
En una demostración aparte, investigadores de VicOne aprovecharon una vulnerabilidad para impedir que funcionara la orden de parada remota de un robot. El caso es más acotado que los 28 hallazgos, pero muestra cómo una función de protección falla por culpa del software que la respalda.
VicOne sostiene además que publicar un parche no pone fin al trabajo. Los equipos aún deben identificar los sistemas afectados, comprobar la compatibilidad y verificar que la actualización conserva el comportamiento previsto. Una prueba anterior superada sigue siendo una evidencia útil, pero una debilidad recién descubierta puede implicar condiciones que esa prueba nunca examinó.
La empresa propone tres preguntas. ¿Dónde se usa el software afectado, incluidos los ordenadores de entrenamiento, los entornos de simulación y los robots desplegados? ¿Qué podría cambiar la debilidad: los modelos, los resultados de las pruebas, la visibilidad del operador o el comportamiento del robot? ¿Cómo se verifica la protección, es decir, tanto que la corrección cierra la debilidad como que el sistema actualizado sigue funcionando como se espera? Cuando no es viable actualizar de inmediato, indica que los equipos pueden necesitar medidas temporales, como restringir el acceso al servicio afectado mientras se prepara una corrección validada.
Qué implica para el sector y qué está sin probar
Lo más útil de los hallazgos es dónde se sitúan. La seguridad de los robots suele debatirse en torno a la máquina en la planta de producción o en el campo. Este conjunto sitúa la mayoría de las debilidades reportadas aguas arriba, en las herramientas que deciden qué aprende un robot y si se le considera seguro. Un entorno de pruebas comprometido es un problema particular porque puede dañar la evidencia en la que se apoya la aprobación de seguridad, sin que el propio robot muestre ningún fallo visible.
El conjunto también incluye proyectos de organizaciones grandes y de uso generalizado, lo que sugiere que la exposición no se limita a software poco conocido. Los equipos que se apoyan en herramientas abiertas compartidas heredan los fallos que estas arrastren, y puede que no las incluyan en su superficie de seguridad.
Varias cuestiones siguen sin probarse. Los 28 hallazgos son la validación inicial de la propia VicOne, publicada en un texto que también promociona los productos de la compañía, y ningún tercero independiente ha confirmado la cifra. La fuente no indica la gravedad de cada fallo, cuántos son explotables en un despliegue típico ni si alguno se ha usado en un ataque. Los escenarios son consecuencias potenciales, no demostradas.
La afirmación sobre la velocidad también carece de una referencia. Encontrar 28 posibles zero-days en menos de dos días es una cifra llamativa, pero la fuente no ofrece ninguna comparación con lo que tardaría una investigación manual convencional sobre el mismo software. Tampoco aclara qué parte del trabajo hizo la IA y cuál los investigadores. La cifra respalda la afirmación más modesta de que la investigación asistida por IA puede sacar a la luz muchos candidatos con rapidez. No demuestra que se mantenga el mismo ritmo con vulnerabilidades confirmadas, corregidas y divulgadas.
Lo próximo que conviene vigilar es el proceso de divulgación. A medida que los fabricantes revisen los hallazgos, el recuento final, las asignaciones de CVE y los parches mostrarán cuántas de estas vulnerabilidades zero-day en robótica se sostienen, y con qué rapidez los proyectos afectados pueden publicar correcciones que los equipos de robótica sean capaces de validar.
