OpenClaw: la vulnerabilidad que demuestra por qué los agentes de IA son una pesadilla de seguridad
Llevamos meses escuchando lo mismo en los foros de seguridad: los agentes de IA autónomos son una bomba de relojería. No porque la tecnología sea mala en sí misma, sino porque el modelo sobre el que se construyen —acceso amplio, acción autónoma, mínima supervisión humana— es exactamente lo que cualquier atacante querría tener en su propio beneficio. OpenClaw acaba de demostrarlo de manera bastante contundente.
Qué es OpenClaw y por qué importa tanto
OpenClaw llegó en noviembre de 2025 y en pocos meses se convirtió en uno de los proyectos más estrellados de GitHub, literalmente: más de 347.000 estrellas en el repositorio. La idea es atractiva: un agente de IA que toma el control de tu ordenador, interactúa con tus aplicaciones, gestiona archivos, hace búsquedas, compra online y, en general, actúa como si fueras tú pero sin que tengas que estar delante de la pantalla.
Para hacer eso, necesita acceso. Mucho acceso. Telegram, Discord, Slack, sesiones abiertas, archivos locales y en red, credenciales almacenadas… OpenClaw, por diseño, opera con los mismos permisos que el usuario que lo ha instalado. Lo que suena a comodidad, desde el punto de vista de la seguridad, es un radio de daño enorme si algo sale mal.
Y algo ha salido mal.
La vulnerabilidad: de permiso mínimo a control total
A principios de esta semana, el equipo de OpenClaw publicó parches para 3 vulnerabilidades de severidad alta. La que se lleva el protagonismo es CVE-2026-33579, con una puntuación que oscila entre 8,1 y 9,8 sobre 10 según la métrica utilizada. No es un número arbitrario: refleja el impacto real.
Cómo funciona el ataque
El fallo está en el proceso de emparejamiento de dispositivos (device pairing). En OpenClaw, el nivel de permiso más bajo es el de operator.pairing. Cualquier atacante que tenga ese privilegio —que es el mínimo, el punto de entrada— puede, gracias a este fallo, aprobar solicitudes de emparejamiento que piden permisos de administrador (operator.admin). Y una vez que un dispositivo obtiene ese nivel, tiene control total sobre la instancia.
Los investigadores de Blink, una empresa de desarrollo de aplicaciones con IA, lo explicaron sin rodeos: no hace falta un segundo exploit, no hace falta que el usuario haga nada más allá del paso inicial de emparejamiento. El atacante entra con el nivel más bajo y sale con las llaves del reino.
El impacto real en organizaciones
Si OpenClaw se usa como plataforma de agente IA a nivel corporativo —algo que ocurre más de lo que parece— las consecuencias de un operator.admin comprometido son serias:
- Lectura de todas las fuentes de datos conectadas.
- Exfiltración de credenciales almacenadas en el entorno del agente.
- Ejecución de llamadas arbitrarias a herramientas y servicios.
- Movimiento lateral hacia otros servicios conectados.
Llamarlo «escalada de privilegios» se queda corto. Es una toma de control completa de la instancia, y con ella de todo lo que el agente pueda tocar.
El problema de fondo: el 63% de las instancias, sin autenticación
Aquí está la parte que debería preocupar especialmente. Blink realizó un escaneo de instancias de OpenClaw expuestas a internet y encontró aproximadamente 135.000. De ellas, el 63% funcionaba sin ningún tipo de autenticación.
Eso significa que, en esas instalaciones, no hacía falta ni usuario ni contraseña para obtener el permiso de operator.pairing. Cualquier visitante de red podía solicitarlo. Y con CVE-2026-33579 activa, ese mínimo permiso era suficiente para escalar hasta el control total.
La capa de autenticación que teóricamente debería frenar este tipo de ataques no existía. La vulnerabilidad no encontraba ni la primera línea de defensa.
El fallo técnico concreto
El problema reside en la función central de aprobación de emparejamiento, ubicada en src/infra/device-pairing.ts. Esta función no comprobaba los permisos del dispositivo que estaba aprobando la solicitud. Si la solicitud estaba bien formada, se aprobaba. Sin verificar si quien aprueba tiene autoridad para hacerlo.
Es un error que, dicho así, parece increíble. Pero ocurre más de lo que uno esperaría, especialmente en proyectos que crecen muy rápido y donde la funcionalidad avanza más deprisa que las revisiones de seguridad.
El margen de 48 horas que los atacantes tuvieron
Los parches se publicaron el domingo. La asignación formal del CVE llegó el martes. Eso son 2 días de ventana en los que los atacantes más atentos podían explotar el fallo antes de que la mayoría de usuarios supiera que había algo que parchear. El sistema de divulgación de vulnerabilidades tiene sus tiempos, y los atacantes lo saben perfectamente.
La probabilidad de que haya habido explotación activa durante ese período no es despreciable, teniendo en cuenta la exposición masiva de instancias sin autenticación.
El debate que OpenClaw ha reabierto
No es la primera vez que se avisa de esto. Desde que OpenClaw se popularizó, los profesionales de seguridad han estado señalando el riesgo estructural de dar a un modelo de lenguaje —un LLM que, por su propia naturaleza, comete errores impredecibles— acceso autónomo a recursos sensibles.
Un directivo de Meta llegó a decir públicamente que había ordenado a su equipo que mantuviera OpenClaw fuera de sus portátiles de trabajo, bajo amenaza de ser despedidos. El argumento: la imprevisibilidad del agente podía generar brechas en entornos que de otra manera serían seguros. No es una postura aislada.
Y aquí es donde está el debate real. OpenClaw ofrece una ganancia de eficiencia genuina: delegar tareas repetitivas, automatizar flujos de trabajo, ahorrar tiempo. Pero esa eficiencia tiene un coste en superficie de ataque que, como demuestra este caso, puede ser devastador si no se gestiona bien.
Yo, la verdad, no me lo creo del todo cuando alguien dice que «el balance merece la pena» sin haber pensado en serio en qué ocurre cuando el agente tiene acceso a tus sesiones de Slack, tus archivos compartidos y tus credenciales almacenadas, y alguien lo compromete. Las ganancias en productividad pueden borrarse en minutos.
Qué deberías hacer ahora si usas OpenClaw
Si tienes una instancia activa de OpenClaw, hay algunas acciones que no deberían esperar:
- Aplicar los parches de inmediato si no lo has hecho ya. CVE-2026-33579 y las otras 2 vulnerabilidades corregidas esta semana no son opcionales.
- Revisar los logs de actividad del último mes, específicamente todos los eventos
/pair approval. Cualquier emparejamiento que no reconozcas debería tratarse como una señal de alerta. - Verificar la configuración de autenticación. Si tu instancia está accesible desde internet sin credenciales, eso tiene que cambiar hoy.
- Reevaluar el modelo de acceso del agente. ¿Necesita realmente acceso a todo? Reducir los permisos al mínimo necesario para operar es una práctica básica que, en el caso de OpenClaw, muchos han ignorado.
Y más allá de lo técnico: vale la pena plantearse si el modelo de un agente IA con acceso amplio y acción autónoma es compatible con los requisitos de seguridad de tu entorno. No en abstracto, sino con nombres concretos: ¿qué recursos tiene acceso? ¿Qué ocurre si esos recursos caen en manos equivocadas?
OpenClaw no es el último agente IA que va a tener este tipo de problemas. Es el primero con suficiente adopción masiva para que el impacto sea visible. Pero el patrón —herramienta potente, acceso amplio, seguridad que va por detrás— se va a repetir. Y conviene estar preparado para cuando llegue el siguiente.
