ClawJacked: cualquier sitio web podría atacar por fuerza bruta a un agente local de OpenClaw

ClawJacked, una vulnerabilidad que Oasis Security reveló el 26 de febrero de 2026 en OpenClaw, el agente de IA de código abierto, permitía que cualquier sitio web que visitara un desarrollador abriera una conexión con el agente que se ejecutaba en su propia máquina y probara contraseñas hasta que este le entregara el control. No hacía falta ningún clic, ni complemento, ni aviso alguno. El premio era la pasarela que orquesta el agente: un intruso que lograra entrar podía hablar directamente con el agente, volcar su configuración, enumerar todos los dispositivos emparejados y leer sus registros. Oasis, un proveedor de software de gestión de accesos para agentes, demostró la cadena de principio a fin en su propio laboratorio y lo notificó de forma privada, y OpenClaw publicó una corrección en menos de 24 horas. Ninguna fuente citada en este artículo registra que el ataque se haya utilizado contra un usuario real. El archivo clasifica el episodio como un incidente de infraestructura de alta gravedad, con una fecha de precisión diaria del 25 de febrero de 2026 y sin daños reales registrados, junto con el resto de sus entradas de OpenClaw en el Orca AI Incident Archive.

Tres valores predeterminados, una cadena

OpenClaw es un agente personal autoalojado que sus usuarios controlan desde un panel web o una terminal, y que se conecta a aplicaciones de mensajería, calendarios y herramientas para desarrolladores, y actúa dentro de ellas. En su centro hay una puerta de enlace, un servidor WebSocket local que Oasis describe como «el cerebro de la operación»: gestiona la autenticación, almacena la configuración, administra sesiones de chat y envía comandos a nodos como una aplicación complementaria para macOS o un iPhone. La autenticación se realiza mediante token o contraseña, y la puerta de enlace se vincula a localhost de forma predeterminada, bajo el supuesto explícito de que el acceso local es inherentemente confiable (Oasis Security, 26 de febrero de 2026).

Tres consecuencias de esa suposición, encadenadas entre sí. Primero, los navegadores no aplican las reglas de origen cruzado a las conexiones WebSocket de la misma forma en que lo hacen a las solicitudes HTTP normales, por lo que JavaScript en cualquier página que visite el usuario puede abrir un socket al puerto de la puerta de enlace local sin que nada sea visible en pantalla. Segundo, el limitador de velocidad de la puerta de enlace eximía por completo las conexiones de loopback, por lo que los intentos fallidos de contraseña desde 127.0.0.1 no se contabilizaban, limitaban ni registraban. Tercero, la puerta de enlace aprobaba automáticamente los emparejamientos de dispositivos que llegaban desde localhost, por lo que un script autenticado podía registrarse como un dispositivo de confianza sin el aviso de confirmación que desencadenaría un dispositivo remoto.

Oasis midió la tasa de intentos de adivinar contraseñas en su propio laboratorio y la comunicó en la divulgación: «En nuestras pruebas de laboratorio, logramos una tasa sostenida de cientos de intentos de adivinar contraseñas por segundo solo con JavaScript del navegador. A esa velocidad, una lista de contraseñas comunes se agota en menos de un segundo, y un diccionario grande solo tardaría minutos. Una contraseña elegida por una persona no tiene ninguna posibilidad». BleepingComputer, que cubrió la divulgación el 1 de marzo de 2026, describe los mismos tres pasos y el mismo orden.

Lo que obtiene un atacante, y lo que Oasis realmente mostró

Una vez autenticado, el script mantenía una sesión de operador con permisos de nivel de administrador. Oasis enumera cuatro cosas que puede hacer directamente a continuación: enviar mensajes al agente de IA y leer sus respuestas, volcar la configuración de la puerta de enlace, que revela los proveedores de IA, los modelos y los canales de mensajería en uso, enumerar cada nodo conectado con su plataforma y dirección IP, y leer los registros de la aplicación. A partir de ahí, Oasis describe, en lugar de demostrar, la escalada: indicar al agente que busque claves de API en el historial de Slack del desarrollador, leer mensajes privados, exfiltrar archivos de dispositivos emparejados o ejecutar comandos de shell arbitrarios en cualquier nodo emparejado. El resumen de la empresa sobre el resultado es que, para un desarrollador con integraciones típicas de OpenClaw, esto equivale a un «compromiso total de la estación de trabajo, iniciado desde una pestaña del navegador».

La demostración que Oasis publicó, con una prueba de concepto en vídeo, es más limitada que esa descripción: un navegador en un sitio no relacionado adivinó la contraseña de la puerta de enlace, se conectó con permisos completos e interactuó con éxito con el agente del usuario, sin mostrar ninguna indicación al usuario. La exfiltración de archivos y la ejecución de shell se describen como lo que el acceso hace posible, no como pasos que la prueba de concepto llevara a cabo. Esa distinción importa cuando el registro se lee como un incidente consumado en lugar de uno demostrado.

El parche llegó en 2026.2.25, no en 2026.2.26

Oasis dijo a los lectores que actualizaran a la versión 2026.2.25 o posterior, y el propio aviso de OpenClaw coincide. El aviso de GitHub, GHSA-jmmg-jqc7-5qf4, enumera las versiones afectadas como 2026.2.24 y anteriores, las versiones parcheadas como 2026.2.25 y posteriores, y atribuye el informe a @luz-oasis, el líder de investigación de Oasis, Elad Luz. La marca de tiempo del registro npm para 2026.2.25 es 04:16 UTC del 26 de febrero de 2026, y las notas de la versión del proyecto para esa versión describen la corrección en términos que se corresponden uno a uno con los tres valores predeterminados: "Autenticación de WebSocket de Security/Gateway: aplicar comprobaciones de origen para clientes WebSocket directos del navegador más allá de Control UI/Webchat, aplicar limitación de intentos fallidos de autenticación por contraseña a los intentos de loopback con origen en el navegador (incluido localhost) y bloquear el emparejamiento automático silencioso para clientes de navegador que no sean de Control UI".

Dos de los informes de noticias mencionan un número diferente. BleepingComputer afirma que la corrección se «publicó en la versión 2026.2.26 el 26 de febrero», y SecurityAffairs repite que 2026.2.26 fue la versión que solucionó el problema, mientras que su propio párrafo de recomendaciones indica a los lectores que actualicen a 2026.2.25 o posterior. Infosecurity Magazine, que cubrió la divulgación el 2 de marzo de 2026, cita la 2026.2.25. La versión 2026.2.26 sí existe, pero npm la registra a las 23:59 UTC del 26 de febrero, aproximadamente veinte horas después de la 2026.2.25, y sus notas son un lote aparte de endurecimiento. La corrección que un lector debe buscar es la de la 2026.2.25.

El identificador llegó más tarde. El aviso de GitHub se publicó el 3 de marzo de 2026 bajo CVE-2026-32025, y el registro de NVD para este se publicó el 19 de marzo de 2026 con una puntuación base CVSS 3.1 de 7,5, calificada como alta por NVD como evaluador principal y por VulnCheck como evaluador secundario. El propio aviso es más prudente que la puntuación: su propio campo de gravedad indica moderada, y su texto califica el fallo como «grave, pero condicional», detallando cuatro condiciones previas: que la puerta de enlace sea accesible en loopback, que se use autenticación por contraseña, que la víctima abra contenido web controlado por el atacante y que la contraseña sea adivinable dentro de intentos factibles. También indica claramente lo que el fallo no es: «No se trata, por sí solo, de un problema de la clase RCE no autenticado expuesto a internet; es una brecha local de endurecimiento de la autenticación con origen en el navegador y con impacto significativo en las condiciones anteriores».

De dónde viene el 42.665 y por qué no es una cifra de ClawJacked

El resumen del archivo registra que 42.665 instancias quedaron expuestas en el momento de la divulgación, y señala que SecurityScorecard ofrece una cifra diferente: 40.214, de las cuales el 35,4 % eran vulnerables. Ninguna de las tres fuentes citadas para este registro contiene ninguno de los dos números; Oasis, BleepingComputer y SecurityAffairs describen la vulnerabilidad sin adjuntar un recuento de la base instalada. Ambas cifras provienen de otro lugar y ambas se publicaron antes de que ClawJacked existiera.

El 42.665 es un escaneo independiente. Maor Dayan, un investigador de seguridad que publicó sus hallazgos en Medium, creó un escáner llamado ClawdHunter v3.0 y lo ejecutó sobre datos de Shodan y Censys recopilados entre el 28 y el 31 de enero de 2026, e informó de «al menos 42.665 instancias» de OpenClaw expuestas públicamente en internet, de las cuales 5.194 se verificaron activamente como vulnerables y el 93,4 % de esas verificadas mostraban un bypass de autenticación. El 40.214 es el equipo STRIKE de SecurityScorecard, que en una investigación publicada el 9 de febrero de 2026 contabilizó instancias de OpenClaw expuestas a internet y señaló 15,2 K como vulnerables a ejecución remota de código, con «el 35,4 % de las implementaciones observadas marcadas como vulnerables». Los propios puntos de resumen de SecurityScorecard dan 42,9 K direcciones IP únicas que alojan paneles de control expuestos, junto con las 40.214 instancias confirmadas en el cuerpo del texto: dos mediciones distintas dentro de un mismo informe.

Ninguna de las dos cifras mide el alcance de ClawJacked, porque ambas cuentan instancias que responden en una interfaz pública. La precondición de ClawJacked es la configuración opuesta: una puerta de enlace vinculada a loopback, en modo contraseña, en una máquina cuyo usuario navega a una página hostil. Un servidor contado en un escaneo de alcance internet puede estar detrás de su propia autenticación y no verse afectado por este error, mientras que el portátil que nunca aparece en dicho escaneo es exactamente el objetivo que describió Oasis. La propia formulación del archivo, "en el momento de la divulgación", asocia por tanto un recuento de población de enero con una vulnerabilidad de febrero. Los recuentos son mediciones reales de cuánto estuvo expuesto OpenClaw; no son un recuento de las máquinas que ClawJacked podría haber tomado. Este artículo no está dirimiendo una disputa —el registro no está marcado como disputado—, pero la procedencia de las dos cifras es verificable y no respalda el encuadre de "en el momento de la divulgación".

¿Qué está establecido y qué no?

Establecido: que Oasis Security encontró la cadena y la demostró en un laboratorio; que el propio aviso y las notas de la versión de OpenClaw confirman los tres comportamientos —falta de aplicación de la política de origen para clientes WebSocket del navegador, ausencia de limitación de intentos de contraseña en loopback, emparejamiento automático silencioso— y que 2026.2.25 cambió cada uno de ellos; que la corrección se publicó dentro del día siguiente al informe; y que tres medios externos al blog del propio descubridor lo cubrieron. La calificación de confianza A del archivo es coherente con ese registro, y nada de esto es disputado por las partes involucradas.

No se ha establecido: que alguien lo haya usado. Aquí no se cita ninguna fuente, y ninguna de las encontradas en la cobertura en torno a la divulgación informa de un compromiso en el mundo real, una víctima o datos sustraídos. La de Oasis es una demostración de laboratorio y el informe describe la capacidad del atacante en lugar de un ataque observado. Eso es coherente con que el archivo no registre ningún daño real, y es la salvedad más importante de la historia: esto es un registro de vulnerabilidad, no un informe de brecha.

Dos etiquetas en circulación son incorrectas, y ambas son fáciles de heredar. Varios artículos secundarios asocian CVE-2026-25253 con ClawJacked. El registro de NVD para ese identificador describe un error diferente en el mismo producto: OpenClaw anterior a 2026.1.29 tomando un gatewayUrl de una cadena de consulta y conectándose a él sin pedir confirmación mientras envía un token, un robo de token con un solo clic con una puntuación CVSS de 8,8; se publicó el 1 de febrero de 2026 y se corrigió el 29 de enero. Esa es la vulnerabilidad de enero, con un mecanismo diferente y un parche diferente. El identificador de ClawJacked es CVE-2026-32025. Infosecurity Magazine, por su parte, describió ClawJacked como una inyección indirecta de prompts; la cadena que documentó Oasis no implica ningún prompt ni ninguna decisión del modelo en absoluto: es un bypass de autenticación que termina en una sesión de operador.

¿Qué cambió después?

OpenClaw lo parcheó, publicó el aviso y acreditó al informante, y el CVE se asignó en el plazo de una semana desde el artículo público. Las recomendaciones de Oasis para las organizaciones van más allá del parche: inventariar qué agentes y asistentes se ejecutan en las máquinas de los desarrolladores, actualizar cada instancia, auditar qué credenciales y capacidades tiene cada uno y revocar lo que no esté en uso, y gobernar a los agentes como identidades no humanas con comprobaciones de intención, aplicación de políticas, acceso justo a tiempo y un registro de auditoría de humano a agente a acción. La empresa vende software en esa última categoría, lo cual conviene saber al sopesar la última recomendación frente a las tres primeras.

El contexto más amplio es que ClawJacked era solo un aviso dentro de una avalancha. La base de datos de avisos de GitHub contiene un gran lote de avisos de OpenClaw con fecha del 3 de marzo de 2026 —el mismo día en que se publicó el de ClawJacked—, que abarcan distintos errores de autenticación, emparejamiento, recorrido de rutas y escape del sandbox en las versiones 2026.2.19 a 2026.2.26. El patrón que conserva el registro de ClawJacked es más estrecho que «los agentes de IA son inseguros» y más útil: la puerta de enlace trataba el loopback como un límite de confianza, y el navegador hizo que esa suposición fuera falsa. Cualquier servicio local que exima a 127.0.0.1 de la limitación de frecuencia, y cualquier flujo de emparejamiento de dispositivos que apruebe automáticamente a los solicitantes locales, hereda la misma forma, tanto si hay un modelo de IA detrás como si no. En este caso, el modelo nunca fue el componente vulnerable: lo era la capa de autenticación que lo rodeaba.