Cualquiera puede hackear remotamente un robot de IA de Hugging Face sin contraseña: cero parche disponible

Imagínate esto: tienes un robot de IA corriendo en tu red, entrenado con LeRobot de Hugging Face, haciendo tareas físicas reales. Y alguien en internet, sin usuario ni contraseña, sin nada, te manda un paquete por la red y de repente controla tu servidor completo. Tus API keys, tus modelos, tu robot. Todo.

Eso no es ciencia ficción. Es CVE-2026-25874, y todavía no tiene parche.

Qué pedo con LeRobot

LeRobot es la plataforma open source de Hugging Face para robótica con IA. Si no la conoces, imagínatela como el “GitHub de los robots”: modelos, datasets y herramientas para que investigadores y startups construyan robots que aprenden a hacer cosas en el mundo real. Tiene casi 24,000 estrellas en GitHub y se usa en proyectos serios de robótica, desde brazos manipuladores hasta sistemas de automatización industrial.

El problema es que toda esa popularidad lo convierte en un blanco grande. Y cuando encuentras un hoyo del tamaño de este, la cosa se pone fea.

El fallo: pickle en producción, sin TLS, sin auth

El corazón de la vulnerabilidad está en el componente PolicyServer del pipeline de inferencia async de LeRobot. Este servidor es el que recibe instrucciones y observaciones del robot cliente para tomar decisiones en tiempo real.

El problema es que usa pickle.loads() para deserializar datos recibidos por gRPC… sin TLS y sin ningún tipo de autenticación.

El código en cuestión, según el análisis técnico de Chocapikk, se ve así:

# SendPolicyInstructions (línea 127)
policy_specs = pickle.loads(request.data)  # nosec
if not isinstance(policy_specs, RemotePolicyConfig):
    raise TypeError(...)

Nótese el # nosec al final: los devs sabían que el linter les iba a gritar que pickle es peligroso, y en vez de arreglarlo, silenciaron la advertencia. Eso es parchar con cinta canela un tornillo que va derecho.

Y aquí viene la parte que pone a pensar: Hugging Face creó Safetensors, un formato de serialización que existe precisamente porque pickle es peligroso para modelos de ML. Se los expliqué en nuestro análisis de cómo las herramientas de IA están siendo usadas para encontrar zero-days. O sea, ellos mismos saben que pickle es un problema, y aun así lo metieron en su propio framework de robótica. Eso es una cagada de primer nivel, como dicen por ahí.

Cómo funciona el ataque

El investigador Valentin Lobstein de VulnCheck lo documentó bien. El ataque es brutal en su simplicidad:

1. El atacante crea un payload malicioso con el protocolo __reduce__ de Python para ejecutar comandos del sistema durante la deserialización
2. Se conecta vía gRPC al PolicyServer (sin TLS, sin credenciales, el servidor usa add_insecure_port())
3. Manda el payload serializado por cualquiera de estos endpoints: SendPolicyInstructions, SendObservations, o GetActions
4. El código se ejecuta antes de que cualquier validación de tipo pueda intervenir, porque pickle ejecuta código arbitrario durante el proceso de unpickling en sí

Un payload de prueba de concepto básico se ve así:

class RCE:
    def __reduce__(self):
        return (os.system, ("id > /tmp/pwned",))

Sencillo, devastador. CVSS 9.3. La documentación oficial incluso sugería bindear el servidor a 0.0.0.0 para servidores GPU remotos, lo que básicamente lo expone a internet abierta.

Qué puede hacer el atacante

Las consecuencias van más allá de robar datos. Con acceso completo al PolicyServer:

• RCE completo en el servidor host
• Robo de credenciales: API keys de Hugging Face, SSH credentials, tokens de acceso
• Movimiento lateral hacia otros sistemas en la red
• Sabotaje físico: si el servidor controla un robot real, el atacante puede mandar comandos de movimiento arbitrarios. Esto no es un riesgo abstracto, es un riesgo de seguridad física

El tech lead de LeRobot, Steven Palma, reconoció que la seguridad en deployment no había sido prioridad porque el proyecto nació como research. El problema es que ya dejó de ser solo research.

El estado actual: sin parche, desde diciembre

La línea de tiempo es lo que más duele. Un investigador identificado como “chenpinji” reportó el fallo en diciembre de 2025. El 7 de enero de 2026, el equipo de LeRobot reconoció el riesgo y dijo que “esa parte del codebase necesita casi ser refactorizada por completo”. La divulgación pública llegó hasta el 28 de abril de 2026.

Hoy, 26 de mayo de 2026, sigue sin parche. La corrección está prometida para v0.6.0, pero no hay fecha confirmada.

Si usas LeRobot v0.5.1 o anterior con el PolicyServer habilitado, estás expuesto.

Cómo mitigarlo HOY, mientras esperas el parche

El advisory de Resecurity da pasos concretos que puedes aplicar ahorita:

Nivel 1: Cambiar la serialización

• Migra PolicySetup a JSON puro o campos nativos de protobuf. Todos los campos son strings, ints o dicts, no necesitas pickle para eso
• Para datos de tensores en las observaciones, usa safetensors o serialización de numpy. Hugging Face ya tiene el formato listo, úsalo

Nivel 2: Asegurar el transporte

• Reemplaza add_insecure_port() con add_secure_port() más certificados TLS
• Agrega interceptores de autenticación gRPC: tokens API, mTLS, o validación JWT
• Si no usas el PolicyServer, desactívalo. No corra componentes que no necesitas

Nivel 3: Defensa en profundidad

• Segmentación de red: el servidor GPU no debe ser directamente accesible desde internet
• Corre el servidor con usuario sin privilegios, no como root
• Usa restricciones de contenedor (seccomp, AppArmor) para limitar qué puede hacer el proceso
• Monitorea procesos y tráfico saliente inusual

La combinación más efectiva hoy mismo es: deshabilita el PolicyServer si no lo necesitas, y si sí lo necesitas, ponle TLS y restricción de red de inmediato. No esperes el parche.

Por qué importa más allá del lab

Esto no es solo un CVE de investigación académica. La robótica industrial y de almacén ya usa plataformas como LeRobot como base. Una vulnerabilidad así en producción no es solo “te roban datos”: puede significar un brazo robótico que se mueve cuando no debe, una línea de manufactura que se detiene, o en el peor caso, un incidente de seguridad física.

La ironía sigue ahí, brillando: la misma organización que enseñó al mundo que no debes usar pickle para modelos de ML, se olvidó de seguir su propio consejo cuando diseñó su servidor de robótica. Así que ya sabes: no hagas como Hugging Face. Usa safetensors.

Y sobre el tema de confiarle seguridad a las IA: como hemos visto recientemente con Claude Mythos encontrando miles de zero-days en Windows y Chrome, la IA puede encontrar fallos como este automáticamente, lo que hace aun más urgente parchar antes de que alguien lo explote a escala.

¿Usas LeRobot en algún proyecto? ¿Ya le pusiste TLS o desactivaste el PolicyServer? Cuéntame en los comentarios, porque me queda la duda de cuántos sistemas están corriendo esto expuesto sin saberlo.

Fuentes

• The Hacker News: CVE-2026-25874 deja LeRobot expuesto a RCE no autenticado
• Chocapikk: Análisis técnico del exploit pickle en LeRobot
• Resecurity: CVE-2026-25874, RCE vía Pickle Deserialization
• CybersecurityNews: Análisis del impacto en sistemas robóticos
• Cloud Security Alliance: Research note sobre CVE-2026-25874
• GitHub: Repositorio oficial de LeRobot