Una falla de LeRobot expone servidores robóticos a RCE sin autenticación

El framework robótico de código abierto LeRobot, de Hugging Face, tiene una vulnerabilidad crítica de ejecución remota de código. Cualquiera que pueda alcanzar el puerto del servicio puede tomar la máquina sin usuario, contraseña ni certificado. La falla está identificada como CVE-2026-25874.

Dónde está el fallo

LeRobot suele ejecutar modelos de política ya entrenados en un servidor GPU, mientras el robot frontal llama a un PolicyServer por gRPC para recibir instrucciones de acción. Esa arquitectura no es el problema. El punto peligroso está en la capa de comunicación, que usa pickle.loads() de Python sobre datos entrantes.

Pickle no es un formato pasivo como JSON o protobuf. Durante la deserialización puede reconstruir objetos Python arbitrarios y ejecutar lógica, incluso hasta llegar a ejecución de comandos. Los handlers RPC afectados son SendPolicyInstructions() y SendObservations(). Ambos reciben bytes crudos y los pasan directamente a pickle sin validación de tipo.

Por eso, un payload preparado con una llamada a os.system() puede ejecutar comandos en cuanto el servidor lo deserializa. El riesgo aumenta porque PolicyServer usa add_insecure_port() por defecto: sin TLS y sin autenticación. Incluso dentro de una red privada, basta con que el puerto sea alcanzable.

Por qué en robótica pesa más

La versión confirmada como afectada es LeRobot v0.4.3 en PyPI. Versiones anteriores con la misma arquitectura de inferencia asíncrona probablemente también estén expuestas. LeRobot supera las 21.500 estrellas en GitHub y es uno de los proyectos de robótica de código abierto más visibles; al momento del artículo fuente, todavía no había una versión oficial corregida.

Comprometer un PolicyServer no es comprometer un servidor de aplicación cualquiera. Estos sistemas suelen correr con privilegios elevados en máquinas GPU, cerca de datasets y pesos de modelos, y conectados directamente a hardware robótico físico. En líneas de producción o robots médicos, una falla de software puede convertirse en un problema de seguridad física.

Qué deberían hacer los equipos

Los investigadores recomiendan sustituir pickle por JSON, campos nativos de protobuf o safetensors de Hugging Face; activar TLS con puertos gRPC seguros; limitar el servicio a interfaces privadas; cerrar el puerto con firewall; y dejar de exponer PolicyServer hasta que exista un parche real. Son mitigaciones, no la solución definitiva, que depende de una nueva versión de Hugging Face.

La lección recuerda a viejos problemas con archivos de modelo de PyTorch. La comunidad de machine learning usa pickle porque es rápido, cómodo y está muy integrado en el ecosistema. Cuando archivos de modelo, instrucciones de política o canales de observación aceptan entrada externa, esa comodidad se convierte en una superficie de ejecución de código.

Fuentes: CocoLoop, CVE-2026-25874: Hugging Face LeRobot Unauthenticated RCE via Pickle Deserialization (Resecurity); Critical CVE-2026-25874 Leaves Hugging Face LeRobot Open to Unauthenticated RCE (The Hacker News)