Vulnerabilidad en OpenClaw permitía escalar privilegios silenciosamente a administrador en instancias expuestas

Una Vulnerabilidad en OpenClaw Permitía Escalonamiento Silencioso de Derechos de Administrador en Instancias Expuestas

Una nueva vulnerabilidad en OpenClaw ha demostrado por qué los agentes AI autohospedados generan tanta preocupación: una vez que has otorgado a una herramienta acceso a archivos, chats, tokens y sesiones de trabajo, un error en el mecanismo de control de acceso rápidamente se transforma de un bug local en una toma de control completa del entorno. En el caso de CVE-2026-33579, un atacante podría escalar sus privilegios a administrador y actuar en nombre del agente casi tan libremente como su propietario. OpenClaw es una plataforma viral para flujos de trabajo con agentes que se ejecuta en la máquina de un usuario o en su propia infraestructura y puede trabajar independientemente con aplicaciones, archivos, navegadores y servicios externos.

Por conveniencia, típicamente se le otorga un amplio conjunto de permisos: acceso a carpetas locales, chats, herramientas corporativas, claves de API y sesiones ya autenticadas. A principios de abril de 2026, el proyecto había acumulado aproximadamente 347 mil estrellas en GitHub, y esta escala hace que cualquier fallo en el modelo de seguridad básico sea particularmente doloroso. La vulnerabilidad, identificada como CVE-2026-33579, afectaba versiones de OpenClaw hasta 2026.

3.28. Según las descripciones del NVD y GitHub Advisory, en la cadena de comando /pair approve, el sistema no retransmitía las restricciones de permisos de quien estaba aprobando la conexión del nuevo dispositivo.

En la práctica, esto significaba que un participante con derechos mínimos operator.pairing podría aprobar una solicitud para un conjunto más amplio de permisos, incluyendo operator.admin, y silenciosamente convertir su dispositivo en uno administrativo.

La corrección se incluyó en la versión 2026.3.28, publicada el 29 de marzo de 2026.

La calificación de criticidad para esta vulnerabilidad llegó a 9,4–9,8 puntos dependiendo de la metodología, lo que para esta categoría de software efectivamente significa compromiso completo de la instancia. El aspecto más perturbador de esta historia no es solo el bug en sí, sino las condiciones reales de explotación. Investigadores de Blink reportaron que al escanear 135 mil instancias de OpenClaw accesibles desde internet, aproximadamente el 63 por ciento—aproximadamente 85 mil instalaciones—respondieron a solicitudes del mecanismo de aprobación de pair sin autenticación.

En otras palabras, el requisito formal de poseer al menos derechos básicos de pairing en muchos casos no funcionaba como barrera en absoluto: el acceso de red ya era un punto de partida suficiente. Riesgo adicional fue creado por la ventana entre el lanzamiento del parche el 29 de marzo y el registro formal de CVE el 1 de abril de 2026. Durante esos dos días, los atacantes podrían entender la gravedad del bug más rápidamente que muchos administradores podrían entender qué necesitaba actualización urgente.

Las consecuencias de tal compromiso para OpenClaw son especialmente graves debido a la naturaleza del producto. Si el agente está conectado a Slack, Telegram, Discord, recursos compartidos de archivos, cuentas en la nube o sistemas internos, entonces el acceso de administrador a la instancia proporciona no solo control sobre la interfaz, sino la capacidad de leer datos, extraer credenciales almacenadas, ejecutar llamadas de tool arbitrarias y moverse lateralmente a través de servicios vinculados. Es precisamente por esto que Microsoft, el 19 de febrero de 2026, recomendó tratar OpenClaw como código ejecutable no confiable con credenciales persistentes y no ejecutarlo en computadoras de trabajo o personales comunes.

Según Microsoft, el escenario mínimamente seguro es una máquina virtual aislada separada, datos que no son de producción y cuentas dedicadas con privilegios mínimos. Para aquellos que ya están usando OpenClaw, la conclusión ahora es intensamente práctica: una actualización no es suficiente. Necesitas verificar los registros de actividad para eventos de aprobación de pair y dispositivos desconocidos, revisar la lista de tokens administrativos y conexiones, revocar y reexpedir secretos a los que el agente tenía acceso, y en casos dudosos reconstruir la instancia en un entorno limpio.

Esta historia importa no solo para usuarios de OpenClaw. Demuestra que para herramientas AI con agentes, el problema principal no radica en la calidad de las respuestas del modelo, sino en la zona confiable en la que se inician: cuantos más permisos e integraciones recibe un agente, mayor es el costo de cualquier error de control de acceso.