Más de 135.000 instancias de OpenClaw están expuestas en Internet. Una vulnerabilidad crítica permite la ejecución remota de código con un solo clic desde cualquier navegador. Investigadores han encontrado más de 1.100 skills maliciosos que distribuyen Atomic Stealer en ClawHub. Microsoft publicó un artículo titulado «Running OpenClaw Safely» que comienza señalando que «para la mayoría de los entornos, la decisión apropiada puede ser no desplegarlo.» El centro nacional de ciberseguridad de Bélgica emitió un aviso gubernamental. Cisco calificó a los agentes de IA personales como OpenClaw de «una pesadilla de seguridad».

Esto no es alarmismo. Son hechos de investigadores de seguridad independientes, proveedores empresariales y agencias gubernamentales. Si usted ejecuta una instancia de OpenClaw, esto le afecta.

Qué salió mal

OpenClaw fue diseñado para localhost. Se instala en su máquina, se comunica a través de una interfaz web local y realiza tareas en su nombre. El modelo de seguridad asumía que la persona que accedía a la interfaz era la persona sentada frente al teclado.

Entonces OpenClaw pasó de 9.000 a más de 200.000 estrellas en GitHub en cuestión de semanas. La gente lo desplegó en servidores VPS, lo expuso a Internet y lo conectó a sus canales de mensajería. La suposición de localhost se rompió a gran escala. (Cubrimos el espectro completo de opciones de despliegue y sus compromisos de seguridad en una guía separada.)

CVE-2026-25253: ejecución remota de código con un clic

La vulnerabilidad más grave es CVE-2026-25253, con puntuación CVSS 8.8. OpenClaw no validaba los encabezados de origen de WebSocket. Así funciona el ataque:

  1. La víctima visita una página web maliciosa (o una página con un anuncio malicioso).
  2. El JavaScript de esa página abre una conexión WebSocket a localhost:18789, el puerto predeterminado de OpenClaw.
  3. Como el navegador está en la misma máquina, la conexión elude cualquier regla de firewall.
  4. El atacante exfiltra el token de autenticación del gateway a través del WebSocket.
  5. Con el token, el atacante tiene control total: acceso al shell, lectura/escritura de archivos y ejecución de comandos.

Vincular a localhost no ayuda. El ataque utiliza el propio navegador de la víctima como pivote. El análisis de SOCRadar recorre la cadena completa.

Skills maliciosos y ataques a la cadena de suministro

Investigadores encontraron 341 skills maliciosos en ClawHub a principios de febrero. Esa cifra ha crecido desde entonces a más de 1.100. La campaña ClawHavoc distribuye Atomic Stealer a través de skills que parecen legítimos pero contienen pasos ocultos de ejecución de comandos. Los skills son archivos Markdown. Una instrucción oculta que dice «ejecuta este comando de shell» es fácil de incrustar y difícil de detectar.

El 17 de febrero, el ataque a la cadena de suministro de Cline fue un paso más allá. Se utilizó un token npm comprometido para publicar una versión del CLI de Cline que instalaba silenciosamente OpenClaw en las máquinas de los desarrolladores. El ataque apuntó directamente al pipeline de compilación.

Los investigadores han revelado ahora seis vulnerabilidades adicionales en el núcleo de OpenClaw, incluyendo CVE-2026-27001. El OWASP Top 10 para Aplicaciones Agénticas ahora incluye muchos de estos patrones como riesgos principales. Como lo expresa el análisis de Conscia, se trata de una crisis de seguridad en toda regla.

Por qué un token de gateway no es suficiente

La autenticación integrada de OpenClaw es un token estático. Se configura una vez, y cada solicitud debe incluirlo. Es mejor que nada. Pero tiene limitaciones fundamentales.

Los tokens estáticos no expiran. Si un token se filtra (a través de CVE-2026-25253, a través de logs, a través de un skill malicioso que lee variables de entorno), el atacante tiene acceso permanente hasta que usted lo detecte y lo rote manualmente.

Los tokens estáticos no se pueden limitar en alcance. El token de gateway otorga acceso completo. No hay forma de dar acceso de solo lectura o limitar lo que una sesión autenticada puede hacer.

Los tokens estáticos no se pueden vincular a un usuario. Si tres personas comparten un token, no existe un registro de auditoría de quién hizo qué.

La mayoría de las guías de despliegue en VPS recomiendan colocar OpenClaw detrás de nginx con autenticación básica. Eso es mejor, pero sigue siendo una credencial estática. Si alguien la captura (sniffing de red en una conexión sin cifrar, una configuración de reverse proxy comprometida, un archivo .htpasswd filtrado), tiene acceso.

El problema fundamental es más profundo: la autenticación ocurre dentro de la aplicación. Si la aplicación tiene una vulnerabilidad, la autenticación puede ser eludida. CVE-2026-25253 lo demostró exactamente. El token de gateway existía. La vulnerabilidad lo extrajo antes de que la aplicación tuviera la oportunidad de verificarlo.

Por eso construimos OpenClaw.rocks con autenticación a nivel de proxy. Las secciones siguientes explican la arquitectura en detalle. Si simplemente desea una instancia segura sin construir todo esto usted mismo, vea nuestros planes.

Cómo aseguramos el gateway

En OpenClaw.rocks, la autenticación ocurre en la capa del proxy, antes de que la solicitud llegue al pod de OpenClaw. Esta es una diferencia estructural, no solo una diferencia de configuración.

Esta es la arquitectura de tres capas.

Capa 1: Cookies de gateway firmados (HMAC-SHA256)

Cuando accede a su instancia de OpenClaw a través del panel de OpenClaw.rocks, el servidor genera una cookie firmada. El formato es:

{expiry}.{userId}.{instanceId}.{hmac_base64url}

La cookie tiene un TTL de 4 horas y se renueva automáticamente cada 45 minutos. Está limitada a la ruta /gw/{instanceId}, por lo que una cookie no puede usarse para acceder a una instancia diferente. Es HttpOnly (JavaScript no puede leerla), Secure (solo se envía por HTTPS) y SameSite=Lax (no se envía en solicitudes cross-origin). El HMAC se verifica mediante comparación de tiempo constante para prevenir ataques de temporización.

Incluso si alguien intercepta el valor de la cookie, no puede crear una nueva sin el secreto de firma. Y la cookie en sí no contiene credenciales que otorguen acceso directo a OpenClaw.

Capa 2: Traefik ForwardAuth

Cada solicitud a una instancia de OpenClaw pasa por Traefik, nuestro reverse proxy. Antes de reenviar la solicitud, Traefik llama a un endpoint auth-gate que verifica la cookie firmada.

Es verificación HMAC pura. Cero llamadas a la base de datos. Cero solicitudes de red a Supabase ni a ningún otro servicio. La decisión se toma en microsegundos.

Si la cookie es inválida, ha expirado o no está presente, la solicitud se rechaza en la capa del proxy. La solicitud nunca llega a OpenClaw. Esta es la diferencia clave. En una configuración típica, es OpenClaw quien debe decidir si permite o rechaza una solicitud. Si OpenClaw tiene una vulnerabilidad en su lógica de autenticación, un atacante puede colarse. En nuestra configuración, OpenClaw nunca ve tráfico no autenticado.

Capa 3: Inyección del token de gateway

Cada instancia de OpenClaw tiene un token de gateway integrado. Es el mismo token que usted configuraría si alojara su propia instancia. La diferencia está en cómo llega al pod.

En una configuración de autoalojamiento típica, usted pega el token en un archivo de configuración, quizás lo almacena en una variable de entorno, y espera que nunca se filtre. Su navegador necesita enviarlo en cada solicitud, que es exactamente el mecanismo que CVE-2026-25253 utilizó para exfiltrarlo.

En nuestra configuración, se genera un token criptográficamente aleatorio de 32 bytes en la creación de la instancia y se almacena como un Kubernetes Secret. Traefik lo inyecta como encabezado Authorization en cada solicitud reenviada. El navegador nunca lo ve. Nunca aparece en un archivo de configuración que pueda hacer commit accidentalmente. Nunca viaja por un WebSocket que una página maliciosa pueda secuestrar. El token existe, pero vive enteramente dentro del clúster, moviéndose solo entre Traefik y el pod.

Por qué esta arquitectura bloquea CVE-2026-25253

La cadena de ataque de CVE-2026-25253 exfiltra el token de gateway vía WebSocket. Veamos qué sucede cuando este ataque apunta a una instancia de OpenClaw.rocks:

  1. El JavaScript del atacante intenta abrir un WebSocket hacia el pod de OpenClaw.
  2. La conexión llega primero a Traefik. Traefik verifica la cookie firmada.
  3. La página maliciosa está en un origen diferente. La cookie SameSite=Lax no se envía en conexiones WebSocket cross-origin. La solicitud es rechazada.
  4. Incluso si la cookie se adjuntara de alguna manera, la página del atacante no puede leerla (HttpOnly). No hay nada que exfiltrar.
  5. Incluso si la cookie se filtrara, no contiene el token bearer. El token bearer lo inyecta Traefik, nunca se expone al navegador. El atacante no puede reconstruirlo.

No hay nada que robar porque el navegador nunca posee las credenciales reales. La superficie de ataque que explota CVE-2026-25253 simplemente no existe.

Lista de verificación de seguridad de OpenClaw para quienes alojan su propia instancia

No todos quieren hosting gestionado, y eso está bien. Si ejecuta su propia instancia de OpenClaw, aquí tiene una lista de verificación práctica para 2026.

¿Está activado su token de autenticación de gateway? Ejecute openclaw doctor para verificarlo. Si la autenticación de gateway está desactivada, cualquiera que pueda alcanzar el puerto 18789 controla su agente y todo a lo que tiene acceso.

¿Está su instancia detrás de un reverse proxy con TLS? HTTP sin cifrar significa que cualquiera en la ruta de red puede leer su token de gateway en tránsito. Use nginx, Caddy o Traefik con un certificado TLS válido. Let’s Encrypt es gratuito.

¿Está en la última versión? CVE-2026-25253 fue parcheado en v2026.1.29. CVE-2026-27001 fue parcheado en v2026.2.15. Si está ejecutando una versión anterior, actualice ahora. La guía de endurecimiento de Adversa AI cubre pasos adicionales.

¿Ha auditado sus skills instalados? La campaña ClawHavoc apuntó específicamente a ClawHub. Verifique cada skill que haya instalado. Si no lo instaló usted mismo, elimínelo y verifique la fuente.

¿Su reverse proxy valida los orígenes WebSocket? Este es el vector específico que explotó CVE-2026-25253. Su reverse proxy debería rechazar las solicitudes de upgrade WebSocket de orígenes inesperados. La documentación de seguridad de OpenClaw tiene ejemplos de configuración.

¿Su autenticación ocurre antes o después de que la solicitud llegue a OpenClaw? Esta es la pregunta más importante. Si OpenClaw maneja su propia autenticación, una vulnerabilidad en OpenClaw puede eludirla. Si su reverse proxy maneja la autenticación, la solicitud nunca llega a OpenClaw a menos que ya esté verificada.

Lo que no resolvemos

La honestidad importa aquí. La autenticación a nivel de proxy resuelve la seguridad del gateway. No lo resuelve todo.

La inyección de prompts es un problema a nivel de aplicación. Un mensaje hábilmente elaborado puede potencialmente engañar al agente para que realice acciones no deseadas. Este es un área activa de investigación en toda la industria de IA, y ningún proveedor de hosting puede prevenirlo completamente hoy en día.

El comportamiento malicioso de los skills se ejecuta dentro del contexto del agente. Si instala un skill que exfiltra datos a través de tráfico HTTPS saliente permitido, la autenticación proxy no puede detenerlo. Lo que nuestra infraestructura hace es contener el radio de explosión: cada instancia se ejecuta en su propio pod de Kubernetes con aislamiento de red, capabilities reducidas, seccomp y un sistema de archivos raíz de solo lectura. Un agente comprometido no puede alcanzar otros agentes ni el sistema host. El operador de Kubernetes aplica estos valores predeterminados para cada instancia.

La confianza en el proveedor de LLM depende de su plan. Si usa sus propias claves API (plan Light), sus conversaciones pasan por el proveedor que configure, y aplica su política de privacidad. En el plan Pro, enrutamos el tráfico a través de nuestro propio gateway de IA con proveedores preconfigurados. No necesita entregar sus claves API a una instancia de OpenClaw ni confiar en que una clave de terceros se almacene de forma segura. El gateway gestiona las credenciales de los proveedores en su nombre, y usted nunca las ve ni las maneja directamente.

La seguridad funciona por capas. Nosotros manejamos las capas de infraestructura. Los desafíos a nivel de aplicación son reales y vale la pena comprenderlos.

La seguridad es una decisión de arquitectura

La crisis de seguridad de OpenClaw no se trata de un CVE ni de un lote de skills maliciosos. Se trata de una herramienta diseñada para localhost siendo desplegada en Internet por cientos de miles de personas, con autenticación que ocurre dentro de la aplicación que se supone debe proteger.

Mover la autenticación a la capa del proxy no es una característica. Es una decisión de arquitectura. Significa que cuando aparezca el próximo CVE de OpenClaw (y aparecerá), las solicitudes autenticadas seguirán siendo verificadas antes de tocar la aplicación. La superficie de ataque es estructuralmente más pequeña.

Tomamos esa decisión desde el primer día. Cada instancia de OpenClaw.rocks se ejecuta detrás de cookies firmados, verificación ForwardAuth y tokens bearer por instancia. Sin tokens de gateway en el navegador. Sin credenciales estáticas que exfiltrar. Sin lógica de autenticación dentro de la aplicación vulnerable.

Si desea leer más sobre cómo desplegamos OpenClaw en Kubernetes con endurecimiento de seguridad completo, la guía de despliegue lo cubre en detalle.

Si simplemente quiere un agente en funcionamiento que se mantenga seguro sin pensar en nada de esto, eso es lo que construimos.

Comience en OpenClaw.rocks o explore el operador de Kubernetes de código abierto si prefiere administrar su propia infraestructura.