OpenClaw: 4 vulnerabilidades críticas que afectan a 40K+ instancias

¿Qué son las vulnerabilidades Claw Chain en OpenClaw?

Cuatro vulnerabilidades críticas descubiertas por Cyera permiten a atacantes robar datos sensibles, escalar privilegios y establecer control persistente sobre hosts comprometidos a través del propio sandbox del agente. El conjunto de fallos, denominado "Claw Chain", afecta el backend de sandbox gestionado OpenShell y el runtime loopback MCP de OpenClaw.

La vulnerabilidad más documentada, CVE-2026-44118, tiene una puntuación CVSS de 7.8 y permite que un cliente loopback no propietario suplante al propietario para obtener privilegios de owner. Esto otorga control sobre configuración del gateway, programación de tareas y gestión del entorno de ejecución.

Las otras tres vulnerabilidades (CVE-2026-44112, CVE-2026-44113 y CVE-2026-44114) permiten respectivamente: plantar backdoors y establecer persistencia, leer archivos del sistema y credenciales, y ejecutar código remoto mediante override de variables críticas del runtime a través de workspace dotenv.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Cuántas instancias están expuestas?

Según análisis de seguridad independientes, existen más de 40.000 instancias de OpenClaw expuestas en internet para vulnerabilidades relacionadas. Algunos reportes secundarios elevan esta cifra a 135.000 instancias, con al menos 12.000 confirmadas como explotables vía RCE.

Es importante destacar que estas cifras se refieren al ecosistema OpenClaw en general, no exclusivamente a las cuatro vulnerabilidades Claw Chain. Sin embargo, ilustran la magnitud del despliegue y la superficie de ataque potencial.

¿Cómo funciona la cadena de explotación?

La peligrosidad de Claw Chain radica en cómo las vulnerabilidades se encadenan para maximizar el impacto:

Fase 1 - Foothold inicial: El atacante obtiene posición en la interfaz local o runtime loopback
Fase 2 - Escalada de privilegios: Mediante CVE-2026-44118, suplanta al owner y obtiene funciones privilegiadas
Fase 3 - Exfiltración: Con CVE-2026-44113, lee archivos del sistema, credenciales y artefactos internos
Fase 4 - Persistencia: Usando CVE-2026-44112, altera configuración y planta backdoors para reingreso posterior
Fase 5 - Ejecución remota: Si CVE-2026-44114 está presente, el override de variables puede derivar en RCE completa

Lo que hace especialmente peligroso este vector es que las acciones del agente parecen legítimas: lectura de archivos, ejecución de herramientas, consultas a APIs y conexiones locales. Esto complica significativamente la detección mediante controles de seguridad tradicionales.

¿Qué significa esto para tu startup?

Si tu startup utiliza agentes de IA, herramientas de automatización o cualquier sistema con acceso privilegiado a datos y recursos, este caso debe alertarte sobre tres riesgos críticos:

1. El sandbox no es suficiente si está mal configurado. Muchos equipos asumen que el aislamiento está garantizado por defecto, pero configuraciones como --no-sandbox o permisos excesivos anulan cualquier protección. Un fallo en la capa de agente puede traducirse directamente en acceso al host.

2. Los tokens y credenciales son el premio principal. Un agente con acceso a Gmail, Slack, GitHub, AWS o Stripe puede filtrar valor equivalente a meses de trabajo en minutos. La mayoría de startups no segmentan adecuadamente los permisos por rol o entorno.

3. El supply chain de plugins es un vector silencioso. Marketplaces de habilidades, extensiones o MCP servers pueden introducir código malicioso. En el ecosistema OpenClaw, Antiy CERT confirmó 1.184 habilidades maliciosas en ClawHub, y Trend Micro identificó 492 servidores MCP comprometidos.

Acciones concretas que debes implementar hoy

Como founder o líder técnico, estas son las medidas prioritarias:

1. Actualiza y audita inmediatamente

Verifica que todas las instancias de OpenClaw estén en versión 2026.4.22 o superior (donde se parcharon las 4 vulnerabilidades)
Si una instancia fue vulnerable, rota todos los tokens, API keys y credenciales que tuvo acceso el agente
Revisa logs de los últimos 30 días buscando: exportación masiva de archivos, cambios en configuración, nuevas conexiones WebSocket locales

2. Reduce privilegios del agente

No otorgues acceso global simultáneo a correo, drive, Git, cloud y shell
Segrega entornos: nunca uses un agente experimental con credenciales de producción
Implementa confirmación humana para acciones de alto riesgo (eliminaciones, transferencias, cambios de infraestructura)

3. Establece controles de supply chain

Crea una allowlist de plugins, skills y MCP servers aprobados
Revisa cambios en dependencias antes de cada despliegue
Documenta qué componentes de terceros tienen acceso a qué recursos

4. Implementa observabilidad específica para agentes IA

Registra todas las llamadas a herramientas y cambios de configuración
Configura alertas por comportamiento anómalo: lectura de archivos sensibles fuera de horario, conexiones salientes inusuales, ejecución de comandos no documentados
Establece un "kill switch" para desactivar el agente inmediatamente si se detecta compromiso

El contexto más amplio: seguridad en la era de los agentes IA

Este caso ilustra una tendencia que los founders deben incorporar en su estrategia de seguridad:

Los agentes de IA ya no son chatbots. Son sistemas privilegiados con acceso a datos, herramientas, navegador, cuentas y capacidad de actuar autónomamente. El perímetro de seguridad ahora incluye la cadena de suministro del agente: plugins, skills, MCP servers, conectores, integraciones y runtimes locales.

Para startups que operan con velocidad y recursos limitados, la presión por lanzar rápido puede llevar a compartir credenciales, exagerar permisos y aceptar componentes sin auditoría. El resultado es riesgo alto con capacidad limitada de contención.

La seguridad de agentes IA no puede tratarse como hardening opcional. Debe estar en el diseño del producto desde el día uno: least privilege, isolation by default, supply-chain review, token hygiene, observabilidad y policy engine.