Una vulnerabilidad en OpenClaw permitía obtener en silencio permisos de administrador en instancias expuestas

La nueva vulnerabilidad de OpenClaw muestra por qué los agentes de IA autoalojados generan tanta inquietud: si a la herramienta ya se le ha dado acceso a archivos, chats, tokens y sesiones de trabajo, un fallo en su mecanismo de control deja de ser un error local y pasa a ser la toma de control de todo el entorno. Con CVE-2026-33579, un atacante podía elevar sus privilegios a administrador y actuar en nombre del agente casi con la misma libertad que su propietario.

OpenClaw es una plataforma de escenarios agénticos que se hizo viral. Se ejecuta en el equipo del usuario o en su propia infraestructura y puede trabajar por sí sola con aplicaciones, archivos, el navegador y servicios externos. Por comodidad, suele recibir un amplio conjunto de permisos: acceso a carpetas locales, chats, herramientas corporativas, claves de API y sesiones ya autorizadas. A principios de abril de 2026, el proyecto acumulaba unas 347.000 estrellas en GitHub, y esa escala hace que cualquier brecha en su modelo básico de seguridad sea especialmente dolorosa.

El problema, identificado como CVE-2026-33579, afectaba a las versiones de OpenClaw anteriores a 2026.3.28.

Según la descripción de NVD y GitHub Advisory, en la cadena del comando `/pair approve` el sistema no transmitía las restricciones de permisos de quien confirmaba la conexión de un nuevo dispositivo. En la práctica, un participante con solo los permisos mínimos de `operator.pairing` podía aprobar una solicitud con un conjunto más amplio de permisos, incluido `operator.

admin`, y convertir en silencio su dispositivo en uno de administrador. La corrección llegó en la versión 2026.3.

28, publicada el 29 de marzo de 2026. La puntuación de gravedad llegó a 9,4–9,8 según la metodología, lo que en esta categoría de software equivale a la toma completa de la instancia.

Lo más grave no es solo el error, sino las condiciones reales de explotación. Los investigadores de Blink informaron de que, al escanear 135.000 instancias de OpenClaw accesibles desde internet, alrededor del 63 por ciento, es decir, unas 85.000 instalaciones, respondía sin autenticación a las solicitudes del mecanismo de pair approval. En otras palabras, el requisito formal de tener al menos permisos básicos de pairing no funcionaba en muchos casos como barrera: el acceso de red ya era un punto de partida suficiente.

La ventana entre el parche del 29 de marzo y el registro formal del CVE el 1 de abril de 2026 añadió riesgo. En esos dos días, los atacantes podían entender la gravedad del fallo más rápido que muchos administradores saber qué debían actualizar con urgencia.

Las consecuencias de un compromiso así son especialmente graves por la propia naturaleza del producto. Si el agente está conectado a Slack, Telegram, Discord, recursos compartidos de archivos, cuentas en la nube o sistemas internos, el acceso de administrador a la instancia da no solo control de la interfaz, sino la capacidad de leer datos, extraer credenciales guardadas, ejecutar tool calls arbitrarias y avanzar hacia los servicios conectados. Por eso Microsoft recomendó ya el 19 de febrero de 2026 tratar OpenClaw como código ejecutable no confiable con credenciales persistentes y no ejecutarlo en equipos de trabajo ni personales habituales.

El escenario mínimo seguro, según Microsoft, es una máquina virtual aislada y separada, datos que no sean de producción y cuentas dedicadas con privilegios mínimos.

Para quienes ya usan OpenClaw, la conclusión es muy práctica: actualizar no basta. Hay que revisar los registros de actividad en busca de eventos de pair approval y de dispositivos desconocidos, repasar la lista de tokens de administrador y conexiones, revocar y reemitir los secretos a los que el agente tenía acceso y, en casos dudosos, reconstruir la instancia en un entorno limpio.

Esta historia importa más allá de los usuarios de OpenClaw. Muestra que, en las herramientas de IA agénticas, el problema principal no está en la calidad de las respuestas del modelo, sino en la zona de confianza en la que se despliegan: cuantos más permisos e integraciones recibe un agente, más caro resulta cualquier error en el control de acceso.