OpenClaw ha pasado de "interesante proyecto de agente de inteligencia artificial" a "objetivo de seguridad activo" en un tiempo récord. Los últimos informes describen múltiples amenazas que se aprovechan de los despliegues de OpenClaw para robar claves de API y distribuir cargas maliciosas, mientras que investigaciones y avisos paralelos muestran un patrón más amplio: no se trata de un fallo, sino de un problema de seguridad a nivel de ecosistema que abarca planos de control expuestos, suposiciones de privilegios locales, confianza en extensiones inseguras y flujos de trabajo de agentes que desdibujan la frontera entre datos e instrucciones. (Noticias sobre ciberseguridad)
Si eres ingeniero de seguridad, lo más importante no es sólo el titular. Es el modelo repetible que subyace a los incidentes:
- Un agente local con privilegios elevados acumula secretos
- Expone interfaces (web, WebSocket, chat, skills, logs)
- Los usuarios instalan funciones de terceros
- Los atacantes encadenan ingeniería social + fallos de diseño + valores por defecto débiles
- Los defensores parchean un problema pero se pierden la exposición operativa
Por eso OpenClaw se ha convertido en un caso de estudio tan útil para la seguridad de los agentes de IA en 2026. Las páginas de avisos de GitHub y los listados de avisos del repositorio de OpenClaw también muestran un flujo rápido de nuevas correcciones de seguridad publicadas, que es exactamente lo que se espera de un proyecto que crece más rápido que la madurez de su modelo de amenazas. (GitHub)
Este artículo desglosa la reciente oleada de exploits, las vulnerabilidades y avisos más relevantes, el problema del malware en el mercado de habilidades y los controles prácticos que los equipos deberían desplegar de inmediato. También incluye lógica de detección defensiva, listas de comprobación de validación y patrones de automatización de ejemplo que los equipos de seguridad pueden adaptar sin convertir nada en un arma.
Qué ha ocurrido en la última oleada de exploits de OpenClaw
Un informe reciente describe explotación generalizada de OpenClaw (antes MoltBot / Clawdbot) por múltiples grupos de hackers para desplegar cargas maliciosas y robar claves API de instancias expuestas o débilmente protegidas. El informe enmarca esto como una tendencia de campaña activa en lugar de un riesgo puramente teórico, lo que coincide con la trayectoria más amplia observada en la cobertura reciente de OpenClaw. (Noticias sobre ciberseguridad)
Al mismo tiempo, informes y análisis independientes han documentado:
- Implantaciones a escala de OpenClaw expuestas a Internetincluyendo de miles a decenas de miles de instancias alcanzables dependiendo de la metodología de escaneo/ventana temporal. Hunt.iopor ejemplo, informó de más de 17.500 instancias expuestas en un análisis centrado en la caza de la exposición CVE-2026-25253. (hunt.io)
- Habilidades maliciosas en ClawHub / el ecosistema de extensiones OpenClawLa cobertura de la corriente principal citó hallazgos de muchos complementos/habilidades maliciosos que apuntaban a credenciales y criptoactivos mediante ingeniería social y comportamiento de extensión de ejecutables. (The Verge)
- Múltiples avisos de seguridad y CVE que afectan a comportamientos básicos como la fuga de tokens, la aplicación de configuraciones no seguras y las rutas de registro que se vuelven relevantes para la seguridad cuando se introducen en flujos de trabajo asistidos por IA. (NVD)
En otras palabras, el problema actual de OpenClaw se entiende mejor como un superficie de ataque compuesta:
- Riesgo de exposición (planos de control orientados a Internet)
- Riesgo de vulnerabilidad (CVEs / avisos conocidos)
- Riesgo en la cadena de suministro (competencias / ampliaciones)
- Riesgo del flujo de trabajo (registros, avisos, depuración asistida por IA)
- Riesgo operativo (usuarios que parchean código pero no rotan secretos ni reducen privilegios)
Por eso no basta con "parchear".
Por qué OpenClaw se convirtió tan rápidamente en un objetivo de gran valor
OpenClaw es atractivo para los atacantes por la misma razón que lo es para los usuarios: concentra capacidades.
La cobertura principal describe a OpenClaw como un agente de IA local que puede realizar tareas en nombre del usuario y al que se le puede conceder un amplio acceso a archivos locales, scripts, comandos de shell y servicios conectados. Esa combinación convierte el compromiso de un agente en un robo de credenciales problema y, en muchos entornos movimiento lateral problema. (The Verge)
Esto cambia la economía del ataque:
- Un compromiso satisfactorio puede dar lugar a varias claves API (proveedores de LLM, herramientas en la nube, plataformas de mensajería).
- El agente puede actuar como diputado de confianza.
- Los ecosistemas de competencias crean canal de distribución por lógica maliciosa.
- La población de usuarios incluye desarrolladores y usuarios avanzados con entornos privilegiados.
Los atacantes no necesitan siempre un exploit perfecto. Pueden ganar mediante una combinación de despliegue deficiente, integraciones con exceso de permisos e ingeniería social.
El cambio de modelo de la amenaza principal: De la "vulnerabilidad de la aplicación" al "abuso del plano de control del agente"
Las categorías de seguridad tradicionales de las aplicaciones web siguen siendo importantes (RCE, omisión de autenticación, inyección de comandos, cruce de rutas, SSRF, etc.), pero OpenClaw añade un problema nuevo y más sutil: el propio agente es un orquestador de ejecución.
Esto crea tres límites de seguridad que los defensores deben modelar explícitamente:
1) Límite de confianza entre humanos y agentes
Los usuarios confían en el asistente para ejecutar la intención de forma segura. Los atacantes abusan de esto a través de enlaces maliciosos, habilidades maliciosas, instrucciones de configuración falsas o manipulación a nivel de prompt.
2) Límite de confianza entre agente y sistema
El agente puede tener acceso a la ejecución del shell, archivos locales, tokens y recursos de red. Una vez manipulado el agente, éste se convierte en una superficie de ejecución privilegiada.
3) Límite entre datos e instrucciones
Los registros, markdown, comentarios y "texto útil" pueden ser consumidos posteriormente por flujos de trabajo LLM. GHSA-g27f-9qjv-22pm de GitHub es un claro ejemplo de cómo incluso una ruta de registro puede convertirse en relevante para la seguridad cuando los registros son leídos por sistemas de depuración asistidos por IA. (GitHub)
Esta es la razón por la que muchos equipos subestiman el riesgo de OpenClaw al principio: defienden la ruta de código que reconocen, pero no la ruta de flujo de trabajo que crearon.
Las vulnerabilidades y avisos más importantes de OpenClaw en este momento
A continuación se exponen las cuestiones más importantes que hay que comprender al analizar el panorama actual de la explotación de OpenClaw. No son los únicos, pero resultan muy instructivos porque corresponden a modos de fallo comunes en el mundo real.
CVE-2026-25253: Cadena de exposición de URL de puerta de enlace / token
NVD describe CVE-2026-25253 como un problema en OpenClaw (aka Clawdbot / Moltbot) antes de 2026.1.29 donde un gatewayUrl puede obtenerse a partir de una cadena de consulta y OpenClaw establece automáticamente una conexión WebSocket sin preguntar, enviando un valor de token. NVD enumera el vector CVSS v3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H y CWE-669. (NVD)
Esta vulnerabilidad es notable porque demuestra un antipatrón recurrente de seguridad de agentes:
- La entrada controlada por el usuario influye en el enrutamiento del plano de control
- El comportamiento de conexión automática se produce sin una fuerte validación/pregunta
- Los tokens sensibles se transmiten como parte del estado del flujo de trabajo
También está en consonancia con los informes públicos sobre los escenarios de ataque con un solo clic y los riesgos de robo de tokens en los ecosistemas OpenClaw. (depthfirst.com)
CVE-2026-25593: Inyección local de comandos de escritura de configuración de WebSocket
NVD describe CVE-2026-25593 como una vulnerabilidad en la que, antes de 2026.1.20, un cliente local no autenticado podía utilizar la API WebSocket de Gateway para escribir config a través de config.aplicar y establecer inseguro cliPath utilizados posteriormente para el descubrimiento de comandos, permitiendo la inyección de comandos como usuario de puerta de enlace. NVD toma nota de la corrección en 2026.1.20. (NVD)
Esto es importante desde el punto de vista operativo porque muchos equipos consideran que la exposición "sólo local" es de bajo riesgo. En los entornos de desarrollo, esa suposición suele ser errónea debido a:
- patrones de acceso localhost asistido por navegador
- malware local ya presente
- reenvío de puertos / proxy inverso
- confianza insegura en "misma máquina == máquina segura"
GHSA-g27f-9qjv-22pm: Envenenamiento de registros a través de cabeceras WebSocket (riesgo de inyección indirecta)
La base de datos de avisos de GitHub indica que en versiones anteriores a la 2026.2.13, OpenClaw registraba determinadas cabeceras de petición WebSocket (entre ellas Origen y Usuario-Agente) sin neutralización o límites de longitud en una ruta "cerrada antes de conectar". GitHub señala explícitamente que si un cliente no autenticado puede llegar a la pasarela y enviar valores de cabecera manipulados, esos valores pueden ser escritos en los registros, y si los registros son posteriormente leídos/interpretados por un LLM, esto puede aumentar el riesgo de inyección indirecta (envenenamiento de registros). La versión parcheada es la 2026.2.13. (GitHub)
Este es uno de los ejemplos más claros de una lección moderna de seguridad IA-agente:
Un problema de "baja gravedad" en un modelo de aplicación clásico puede llegar a ser materialmente importante en un flujo de trabajo asistido por IA.
GitHub califica el aviso de gravedad baja (CVSS 3.1) y señala que el impacto es limitado si no se introducen los registros en un LLM u otro sistema automatizado. Esa condicionalidad es exactamente lo que los defensores maduros necesitan preservar en su modelo de amenazas en lugar de aplanar todo en "crítico" o "nada". (GitHub)
Un panorama consultivo más amplio
La página de avisos de seguridad de OpenClaw en GitHub muestra un flujo considerable y activo de problemas publicados, incluidos varios moderados/altos a finales de febrero de 2026. La lista exacta evoluciona rápidamente, pero lo más importante es que la superficie de ataque de OpenClaw es amplia y se está reforzando activamente bajo una presión real. (GitHub)
Para los defensores, esto significa que la cadencia del parche debe ir acompañada de priorización basada en el riesgo y verificación del entornono sólo "actualizar cuando convenga".
El problema del ecosistema Skills: cuando las "extensiones" se convierten en distribuidores de malware
El ecosistema de habilidades de OpenClaw (incluidas las referencias a ClawHub en la cobertura) es donde muchos equipos se ven sorprendidos. Varios medios informaron de habilidades maliciosas que se hacían pasar por herramientas útiles (especialmente temas de criptografía/comercio) y distribuían malware de robo de información mediante ingeniería social y comportamientos ejecutables. La cobertura también destaca que las habilidades no son metadatos inofensivos: pueden interactuar con archivos y redes locales una vez instaladas y activadas. (The Verge)
The Verge informó de los hallazgos de OpenSourceMalware y describió el malware en cientos de habilidades enviadas por los usuarios, incluyendo comportamientos diseñados para robar criptoactivos, credenciales API, credenciales SSH y contraseñas de navegador. También señala el crecimiento de la popularidad de OpenClaw y los amplios poderes locales que algunos usuarios le otorgan. (The Verge)
De forma similar, Tom's Hardware informó sobre habilidades maliciosas subidas a ClawHub, destacando que las habilidades son carpetas de código ejecutable (no scripts en sandbox), y documentó patrones de ingeniería social que instruían a los usuarios a pegar comandos de terminal ofuscados que obtenían cargas útiles remotas. (Ferretería Tom)
Esta no es solo una historia de "malware en un mercado". Es una amplificación de los privilegios de los agentes historia:
- El código de extensión hereda la confianza del usuario y, a menudo, privilegios de agente
- Los flujos de documentación/configuración pueden convertirse en armas
- Los pasos de ejecución manual de comandos evitan algunas exploraciones convencionales
- Los usuarios pueden evaluar las competencias por su utilidad, no por la calidad de la revisión del código
Por qué es diferente del riesgo tradicional del registro de paquetes
Los ecosistemas de paquetes (npm, PyPI, etc.) ya presentan riesgos en la cadena de suministro, pero las competencias al estilo OpenClaw añaden un patrón distintivo:
- El "instalador" puede ser efectivamente instrucciones en markdown/docs
- El agente está diseñado para ejecutar acciones
- Los usuarios están condicionados a seguir pasos de configuración orientados a la automatización
- La carga útil puede mezclar peticiones de inteligencia artificial + ejecución de secuencias de comandos + búsquedas externas
Este modelo híbrido implica que los defensores deben inspeccionar no sólo las firmas de código y los hashes, sino también intención de comportamientoinstrucciones de configuración y patrones de comunicación entre dominios.
La reciente historia de explotación es más grande que una campaña
El titular "varios grupos de piratas informáticos explotan las instancias de OpenClaw" es importante porque señala una transición del oportunismo aislado al explotación del ecosistema. Una vez que varios conjuntos de actores convergen en la misma plataforma, suelen observarse tres desarrollos paralelos:
- Campañas de imitación utilizando informes públicos y PdC
- Mercantilización de las herramientas (scripts/exploradores para instancias expuestas)
- Especialización posterior a la explotación (robo de fichas, cargadores, infostealers, persistencia)
Esto es coherente con el patrón más amplio de las operaciones de ciberdelincuencia: una vez que una plataforma se convierte en común, expuesta y rica en credenciales, es absorbida por el malware existente y los conductos de robo de credenciales.
En el caso concreto de OpenClaw, la propuesta de valor para los atacantes es inusualmente fuerte porque una sola víctima puede exponer:
- Claves API del proveedor LLM
- fichas de plataforma de mensajería
- credenciales de automatización
- artefactos de navegador/sesión
- datos del sistema de archivos
- vías de ejecución del shell
Cómo pensar en el robo de claves API en los incidentes de OpenClaw
El titular hace hincapié en el robo de claves API, y ahí es exactamente donde muchas organizaciones subestiman el impacto.
Por qué las claves AI/API robadas no son "sólo un riesgo de facturación"
Los equipos de seguridad a veces tratan el robo de claves API como un problema financiero ("alguien ha utilizado nuestra cuota"). En contextos OpenClaw, claves robadas pueden apoyar:
- Exfiltración de datos
- Abuso de los servicios integrados
- Suplantación operativa
- Reconocimiento de los flujos de trabajo internos
- Persistencia mediante la reautomatización
Si el agente tuviera acceso a varios proveedores, los atacantes podrían utilizar selectivamente la clave más valiosa (por ejemplo, cuotas más altas, derechos empresariales, menor madurez de supervisión).
Qué deben hacer los defensores tras el robo de llaves (más allá de la rotación)
Una respuesta madura incluye:
- Girar teclas
- Auditoría sobre el uso de llaves
- Identificar los datos/flujos de trabajo accesibles
- Revisar los avisos/tareas/registros del agente en busca de ejecuciones sospechosas.
- Volver a basar el host
- Reevaluar los privilegios y ampliar la confianza
Simplemente rotar la llave pero dejar el mismo agente expuesto/sobreprivilegiado en su lugar es un fallo recurrente.
Un modelo práctico de cadena de ataques que pueden utilizar los equipos de seguridad
A continuación se muestra una abstracción defensiva, no armada, de cómo los compromisos recientes de OpenClaw tienden a encadenar factores de riesgo.
Tabla: Etapas representativas de la cadena de ataque de OpenClaw
| Escenario | Atacante Gol | Mecanismo común | Defender Punto ciego | Prioridad defensiva |
|---|---|---|---|---|
| Descubrimiento inicial | Encontrar objetivos | Exploración de Internet, referencias públicas | "Está en un puerto raro, nadie lo encontrará" | Eliminar la exposición, restringir la entrada |
| Acceso inicial | Pasarela de alcance/plano de control | Interfaz de usuario/WebSocket expuesto, suposiciones de confianza local, instalación de habilidades maliciosas | Supuestos "sólo locales" / autenticación débil | Parche + autenticación + controles de red |
| Acceso con credenciales | Robar claves/tokens API | Exportación de endpoints, robo de configuraciones, cargas útiles infostealer | Claves almacenadas ampliamente y reutilizadas | Rotación secreta + alcance |
| Ejecución | Ejecutar malware / comandos | Herramientas del agente, rutas del shell, código de extensión, comandos de pegado del usuario | El agente es considerado un "ayudante", no un ejecutor | Mínimo privilegio + listas de permisos |
| Persistencia / Reutilización | Mantener la posición o monetizar | Nuevas habilidades, fichas robadas, tareas programadas | Control deficiente de las acciones de los agentes | Detección y revisión de conductas |
| Defensa Evasión | Evitar la notificación | Actividad combinada de agentes legítimos | Registros no normalizados / sin líneas de base | Registros de auditoría + reglas de anomalías |
Esta tabla es intencionadamente general porque los mecanismos exactos varían según la versión, el despliegue y el comportamiento del usuario. La cuestión es asegurarse de que sus controles cubren la cadenano sólo el primer fallo de la cadena.
Ideas de detección y caza para SOC y equipos de ingeniería de seguridad
La seguridad de OpenClaw no es sólo un problema de gestión de parches. También es un problema de telemetría.
Qué recoger
Como mínimo, recopilar y conservar:
- registros de acceso al proxy inverso (si es frontal)
- Registros de la pasarela OpenClaw
- registros de creación de procesos de host
- telemetría de red saliente
- telemetría de creación/ejecución de ficheros en los directorios de trabajo de los agentes
- eventos de instalación de extensiones/habilidades (o equivalentes)
- eventos de rotación de claves / acceso a secretos en su gestor de secretos (si está integrado)
Qué buscar
Centrarse en grupos de comportamientos en lugar de en indicadores individuales:
- Actividad WebSocket inesperada a pasarelas de agentes desde fuentes no fiables
- Anomalías en las cabeceras (valores largos/codificados) en las vías de acceso a los agentes
- Procesos infantiles inusuales generados por los servicios relacionados con los agentes
- Llamadas salientes a dominios recién vistos poco después de instalar la habilidad
- Ejecución de comandos de terminal tras la configuración de la extensión solicita
- Secuencia rápida de utilización de claves de las nuevas PI tras sospecha de compromiso
Ejemplo de concepto de detección de tipo SIEM (Pseudo-KQL)
// Concepto de caza defensiva: actividad sospechosa en torno a los procesos host de OpenClaw
let OpenClawProcs = dynamic(["openclaw", "moltbot", "clawdbot"]);
DeviceProcessEvents
| where InitiatingProcessFileName has_any (OpenClawProcs)
| summarize ChildCount = count(), Children = make_set(FileName, 20) by DeviceName, bin(Timestamp, 15m)
| join kind=leftouter (
DeviceNetworkEvents
| where InitiatingProcessFileName has_any (OpenClawProcs)
| summarize RemoteIPs = make_set(RemoteIP, 50), Domains = make_set(RemoteUrl, 50) by DeviceName, bin(Timestamp, 15m)
) en DeviceName, Timestamp
| where ChildCount > 5 or array_length(Domains) > 10
| Project Timestamp, DeviceName, ChildCount, Children, RemoteIPs, Domains
Esta no es una firma para "la" campaña de malware OpenClaw. Es una forma de encontrar ráfagas de comportamiento dirigidas por agentes que merecen una revisión.
Ejemplo de heurística similar a YARA para scripts sospechosos de instalación de habilidades (conceptual)
regla patrón_de_instrucción_de_habilidad_de_garra_abierta_sospechosa
{
meta:
description = "Señala docs/scripts sospechosos de habilidades OpenClaw que introducen patrones de fetch-exec de terminal ofuscados"
author = "Patrón de investigación defensiva"
caution = "Sólo heurístico; espere falsos positivos"
strings:
$a = /curl\\s+.*\|\\s*(bash|sh)/ nocase
$b = /python+-c\\\s+["'].*base64/i
$c = /osascript.*do shell script/i
$d = /powershell(\\\.exe)?\\\s+-enc/i
$e = "copia y pega este comando" nocase
$f = "desactiva tu antivirus" nocase
condición:
2 de ($a,$b,$c,$d,$e,$f)
}
Utilícelo como ayuda de triaje para las revisiones de competencias, no como sustituto del análisis real.
Endurecimiento de las implantaciones de OpenClaw: Lo que realmente reduce el riesgo
Los equipos de seguridad piden a menudo una "lista de comprobación de buenas prácticas". La respuesta útil es un orden de prioridades, no una lista gigante.
Prioridad 1: Eliminar la exposición a Internet de las interfaces de control
Si la interfaz de control o la puerta de enlace de OpenClaw son accesibles desde la Internet pública, arréglalo primero. Múltiples informes y estudios de exposición muestran que este es uno de los facilitadores más consistentes de compromiso y robo de tokens. (hunt.io)
Controles de referencia:
- enlazar con localhost cuando sea posible
- requieren acceso VPN / Zero Trust para la administración remota
- aplicar la autenticación en el proxy inverso
- IP-allowlist acceso admin
- límite de velocidad y límite de tamaño de cabecera para puntos finales orientados a agentes
El aviso de GitHub para GHSA-g27f-9qjv-22pm menciona específicamente la restricción de la exposición a la red de la puerta de enlace y la aplicación de límites de proxy inverso en el tamaño de la cabecera como soluciones/medidas de endurecimiento. (GitHub)
Prioridad 2: Parchear rápido, pero verificar la versión y el comportamiento
Para las vulnerabilidades comentadas anteriormente, las versiones de los parches son importantes:
- CVE-2026-25253afectados antes de 2026.1.29 (según NVD) (NVD)
- CVE-2026-25593fijo en 2026.1.20 (por NVD) (NVD)
- GHSA-g27f-9qjv-22pmparcheado en 2026.2.13 (según el aviso de GitHub) (GitHub)
Pero no basta con comprobar las versiones. Los equipos deben verificar:
- el servicio se reinició realmente
- el punto final expuesto ya no es accesible
- se giraron las fichas si pudo haber exposición
- los flujos de trabajo logs/LLM no ingieren contenidos no fiables de forma insegura
Prioridad 3: Reducir los privilegios de los agentes y el alcance de los tokens
El riesgo de OpenClaw aumenta con los privilegios. Si un agente tiene amplio acceso al sistema de archivos, ejecución de shell y tokens OAuth/API de alto valor, el impacto del compromiso aumenta bruscamente.
Cambios recomendados:
- identidades/cuentas separadas para uso de agentes
- privilegio mínimo en los ámbitos de las API
- credenciales efímeras siempre que sea posible
- no hay tokens de nube a nivel de administrador
- no guardar secretos de producción en dispositivos personales
- aislar el tiempo de ejecución del agente de los secretos de la estación de trabajo del desarrollador
Las recomendaciones de Eye Security en torno a la actualización, el mínimo privilegio y evitar conexiones API altamente confidenciales a menos que sea necesario se alinean con esta dirección. (Investigación ocular)
Prioridad 4: Tratar las competencias como dependencias ejecutables (porque lo son)
La cobertura dominante subraya que las habilidades de OpenClaw pueden actuar con un acceso significativo y no son metadatos inofensivos. (The Verge)
Adoptar un proceso formal:
- aptitudes aprobadas por allowlist
- exigir la revisión del código de las nuevas competencias
- reflejar las competencias verificadas internamente
- bloquear las instalaciones directas desde registros públicos en terminales de empresa
- inspeccionar las instrucciones de instalación y la documentación, no sólo los archivos de código
- supervisar el comportamiento del proceso/red tras la instalación
Prioridad 5: Tratar los registros como entradas no fiables en los flujos de trabajo de IA
El aviso de GitHub es explícito: si los registros son leídos/interpretados posteriormente por un LLM, los valores manipulados en los registros pueden aumentar el riesgo de inyección indirecta. Las soluciones incluyen sanear/escapar y no auto-ejecutar instrucciones derivadas de los registros. (GitHub)
Esto se aplica más allá de OpenClaw. Cualquier proceso de depuración asistido por IA debería:
- limpiar el contenido del registro
- preservar las etiquetas de procedencia (no fiables o generadas por el sistema)
- impedir la ejecución de acciones directas a partir de sugerencias de modelos
- exigir la aprobación humana de las órdenes
- evitar la introducción de registros sin procesar en automatizaciones privilegiadas
La verificación importa más que las notas de parche
Uno de los mayores errores operativos de la actual oleada de OpenClaw es tratar la corrección como un ejercicio de documentación ("hemos actualizado") en lugar de como un ejercicio de verificación ("hemos demostrado que el comportamiento de riesgo ha cesado").
Los equipos de seguridad deben validar la corrección en cuatro capas:
1) Validación de versiones
Confirme la versión en tiempo de ejecución, no sólo la salida del gestor de paquetes.
2) Validación de la red
Compruebe que el plano de control no es accesible desde el exterior.
3) Validación del comportamiento
Probar si los flujos previamente arriesgados (por ejemplo, comportamiento de registro de encabezados, escrituras de configuración, alcanzabilidad de puntos finales) están realmente mitigados.
4) Validación de la higiene de los secretos
Se han rotado las claves de confirmación y las credenciales antiguas ya no funcionan.
Ejemplo de script de validación defensiva (no exploit, sólo comprobaciones de sanidad)
#!/usr/bin/env python3
"""
Ayudante de validación defensiva OpenClaw (sólo comprobaciones seguras)
- Verifica las suposiciones de alcanzabilidad de la puerta de enlace local
- Comprueba las cabeceras de respuesta y la exposición básica del endpoint
- NO explota vulnerabilidades
"""
importar socket
import requests
from urllib.parse import urljoin
TARJETAS = [
("127.0.0.1", 18789),
("localhost", 18789),
]
def is_port_open(host, port, timeout=1.0):
s = socket.socket()
s.settimeout(timeout)
prueba:
s.connect((host, port))
return True
excepto Excepción:
return False
finalmente:
s.close()
def comprobar_http(url_base):
resultados = []
for ruta in ["/", "/salud", "/api/versión"]:
url = urljoin(url_base, ruta)
probar:
r = requests.get(url, timeout=2)
results.append((ruta, r.código_estado, dict(r.cabeceras)))
excepto Exception como e:
results.append((ruta, "ERR", str(e)))
devolver resultados
def main():
print("=== OpenClaw Defensive Validation (safe) ===")
para host, port en TARJETAS:
open_ = is_port_open(host, port)
print(f"[+] {host}:{port} open={open_}")
si open_:
base = f "http://{host}:{port}"
for item in comprobar_http(base):
print(" ", item)
if __name__ == "__main__":
main()
Este tipo de script no le dirá todo. Sin embargo, ayudará a los equipos a evitar el error común de asumir que se aplicó un parche cuando el servicio vulnerable todavía se está ejecutando en un proceso antiguo, contenedor o enlace de puerto alternativo.
Lo que los equipos de seguridad de las empresas deben hacer esta semana
Si OpenClaw está presente en su entorno (incluyendo TI en la sombra / dispositivos personales conectados a servicios corporativos), la respuesta correcta no es el pánico. La respuesta adecuada no es el pánico, sino una estrategia de contención y refuerzo basada en pruebas.
Tabla: Plan de respuesta de seguridad de 7 días de OpenClaw
| Día | Objetivo | Acciones | Pruebas que reunir |
|---|---|---|---|
| 1 | Descubrir el uso | Inspección de activos, búsqueda de EDR, escaneado de redes en busca de puertos o nombres de procesos comunes. | Lista de anfitriones, lista de propietarios |
| 2 | Reducir la exposición | Eliminar el acceso a Internet, acceso de administración sólo VPN, controles proxy | Pruebas de accesibilidad antes/después |
| 3 | Parche | Actualizar a versiones fijas, reiniciar servicios | Prueba de versión de tiempo de ejecución, registros de despliegue |
| 4 | Secretos | Rotación de claves/tokens API, revocación de credenciales antiguas | Marcas de tiempo de rotación, registros de uso |
| 5 | Habilidades | Realice un inventario de las competencias/extensiones instaladas y elimine las que no sean de confianza. | Inventario de competencias diff |
| 6 | Supervisión | Añadir detecciones para procesos hijo de agente/ráfagas de salida | Alertas SIEM, líneas de base |
| 7 | Política | Definir el uso aprobado, el modelo de privilegios y el proceso de revisión de competencias | Documento normativo + excepciones |
Este tipo de plan de respuesta se adapta mejor que intentar perseguir cada titular de forma individual.
Cómo se conecta esto con la seguridad más amplia de los agentes de IA en 2026
OpenClaw no es la última plataforma de agentes que se enfrenta a este tipo de crisis de seguridad. Simplemente es la primera lo suficientemente grande y rápida como para hacer visible el patrón.
La lección más importante es que Los agentes de IA colapsan dominios de confianza antes separados:
- intención del usuario
- automatización ejecutable
- almacenamiento secreto
- plugins/habilidades externas
- registros y depuración de canalizaciones
- superficies de control controladas por chat
Cuando esos dominios convergen en un proceso, las viejas suposiciones fracasan:
- "es sólo una aplicación local"
- "es sólo una herramienta de navegación"
- "es sólo un mensaje de registro"
- "es sólo una habilidad de marcado"
- "es sólo una clave API"
Los recientes avisos de OpenClaw y los informes de incidentes hacen esto visible de una manera que los ejemplos estándar de aplicaciones web no lo hacen. (GitHub)
Si su equipo está evaluando cómo hacer operativas las defensas en torno a agentes de IA, OpenClaw es un buen caso de uso para verificación continua en lugar de cheques únicos.
Una plataforma como Penligente puede ser útil cuando los equipos tienen dificultades:
- probar repetidamente la exposición al plano de control de agentes
- validación de la eficacia de los parches tras las actualizaciones
- comprobación de configuraciones arriesgadas en muchos hosts
- automatización de la recogida de pruebas para la verificación de las medidas correctoras
- mantener flujos de trabajo de pruebas seguros y repetibles sin guiones ad hoc
Esto es especialmente relevante cuando el riesgo no es un único CVE, sino una cadena de condiciones (exposición + privilegio + extensión insegura + supervisión deficiente). El valor reside menos en "encontrar un fallo" y más en probar si el entorno sigue siendo vulnerable tras los cambios operativos.
Penligent también ha publicado varios análisis relacionados con OpenClaw que pueden utilizarse como contexto para los equipos de seguridad que elaboran directrices internas y formación sobre patrones de riesgo de los agentes, incluido el envenenamiento de registros/inyección indirecta de avisos y el envenenamiento del ecosistema de habilidades. (Penligente)
Conclusión
Los recientes informes de múltiples grupos de piratas informáticos que explotan instancias de OpenClaw para robar claves de API y desplegar malware no son una anomalía aislada. Son el resultado esperado de una clase de plataforma que combina altos privilegios, rápida adopción, ecosistemas de extensión y límites de seguridad en evolución. (Noticias sobre ciberseguridad)
La respuesta correcta no es declarar a los agentes de IA "intrínsecamente inseguros", ni descartar los incidentes como errores del usuario. La respuesta correcta es madurar el modelo operativo:
- reducir la exposición
- parchear rápidamente
- verificar el comportamiento
- minimizar los privilegios
- tratar las competencias como código ejecutable
- tratar los registros como datos no fiables
- supervisar las acciones de los agentes como señal de seguridad de primera clase
OpenClaw está obligando a la industria a aprender pronto estas lecciones. Los equipos que las aprendan ahora estarán mucho mejor preparados para la próxima generación de herramientas agénticas, se llamen OpenClaw o de otro modo.
Referencias
- NVD: CVE-2026-25253 (problema de pasarela relacionado con tokens de OpenClaw / Clawdbot / Moltbot) (NVD)
- NVD: CVE-2026-25593 (escritura local de WebSocket config → inyección de comandos como usuario de puerta de enlace) (NVD)
- Base de datos de avisos de GitHub: GHSA-g27f-9qjv-22pm (envenenamiento de registros de OpenClaw / inyección indirecta a través de cabeceras WebSocket) (GitHub)
- GitHub OpenClaw Security Advisories (flujo continuo de avisos) (GitHub)
- Investigación de Eye Security sobre el envenenamiento de registros de OpenClaw y el contexto de los parches (Investigación ocular)
- Hunt.io análisis de exposición para instancias OpenClaw orientadas a Internet y contexto CVE-2026-25253 (hunt.io)
- Noticias de ciberseguridad: varios grupos de piratas informáticos aprovechan las instancias de OpenClaw para robar claves de API y desplegar programas maliciosos (Noticias sobre ciberseguridad)
- The Verge: OpenClaw skills ecosystem malware risks and attack-surface implications (The Verge)
- Tom's Hardware: habilidades maliciosas de ClawHub, comportamiento de extensión de ejecutables y flujos de configuración de ingeniería social (Ferretería Tom)
- OpenClaw log poisoning / artículo de inyección indirecta de prompt (corregido en 2026.2.13) (Penligente)
- OpenClaw envenenamiento de habilidades / "SKILL.md se convierte en un instalador" análisis (Penligente)
- Manifiesto de seguridad de OpenClaw / guía de refuerzo arquitectónico (Penligente)
- OpenClaw zero-click RCE and indirect injection walkthrough (contexto histórico / formación interna) (Penligente)
Spanish 
English 
German 
French 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew