Amenazas en OpenClaw: evaluación de los riesgos y cómo manejar la IA en la sombra

Es probable que todos hayan oído hablar de OpenClaw, anteriormente conocido como “Clawdbot” o “Moltbot”, el asistente de IA de código abierto que se puede implementar en una máquina localmente. Se conecta a plataformas de chat populares como WhatsApp, Telegram, Signal, Discord y Slack, lo que le permite aceptar comandos de su propietario y actuar en el sistema de archivos local. Tiene acceso al calendario, el correo electrónico y el navegador del propietario, e incluso puede ejecutar comandos del sistema operativo a través del shell.

Desde una perspectiva de seguridad, esa descripción por sí sola debería ser suficiente para poner nervioso a cualquiera. Pero cuando las personas comienzan a intentar usarlo para trabajar dentro de un entorno corporativo, la ansiedad se convierte rápidamente en la convicción de un caos inminente. Algunos expertos ya han calificado a OpenClaw como la mayor amenaza interna de 2026. Los problemas con OpenClaw abarcan todo el espectro de riesgos destacados en el reciente Top 10 de OWASP para aplicaciones agénticas.

OpenClaw permite conectar cualquier LLM local o basado en la nube, y el uso de una amplia variedad de integraciones con servicios adicionales. En esencia, se trata de una puerta de enlace que acepta comandos a través de aplicaciones de chat o una interfaz de usuario web, y los envía a los agentes de IA adecuados. La primera versión, denominada Clawdbot, salió al mercado en noviembre de 2025; en enero de 2026, se había vuelto viral y trajo consigo un montón de problemas de seguridad. En una sola semana, se revelaron varias vulnerabilidades críticas, surgieron habilidades maliciosas en el directorio de habilidades y se filtraron secretos de Moltbook (esencialmente “Reddit para bots”). Para colmo, Anthropic presentó una demanda por infracción de marca registrada para cambiar el nombre del proyecto y evitar infringir los derechos de “Claude”, y el nombre de la cuenta X del proyecto fue secuestrado para promocionar estafas con criptomonedas.

Problemas conocidos de OpenClaw

Aunque el desarrollador del proyecto parece reconocer que la seguridad es importante, al tratarse de un proyecto aficionado, no se dedican recursos específicos a la gestión de vulnerabilidades ni a otros aspectos esenciales de la seguridad del producto.

Vulnerabilidades de OpenClaw

Entre las vulnerabilidades conocidas en OpenClaw, la más peligrosa es CVE-2026-25253 (CVSS 8.8). Su aprovechamiento conduce a una vulneración total de la puerta de enlace, lo que les permite a los atacantes ejecutar comandos arbitrarios. Para empeorar las cosas, es muy fácil de llevar a cabo: si el agente visita el sitio web de un atacante o el usuario hace clic en un enlace malicioso, se filtra el token de autenticación principal. Con ese token en su poder, el atacante tiene control administrativo total sobre la puerta de enlace. Esta vulnerabilidad se corrigió en la versión 2026.1.29.

Además, se descubrieron dos vulnerabilidades de inyección de comandos peligrosas (CVE-2026-24763 y CVE-2026-25157).

Valores predeterminados y funciones inseguros

Una variedad de configuraciones predeterminadas y peculiaridades de implementación hacen que atacar la puerta de enlace sea muy sencillo.

• La autenticación está desactivada de manera predeterminada, por lo que se puede acceder a la puerta de enlace desde Internet.
• El servidor acepta conexiones WebSocket sin verificar su origen.
• Las conexiones localhost se consideran implícitamente fiables, lo que puede suponer un desastre anunciado si el host ejecuta un proxy inverso.
• En el modo Invitado se puede acceder a varias herramientas, algunas de ellas peligrosas.
• Los parámetros de configuración críticos se filtran a través de la red local mediante mensajes de difusión mDNS.

Secretos en texto sin formato

La configuración, la “memoria” y los registros de chat de OpenClaw almacenan claves API, contraseñas y otras credenciales para LLM y servicios de integración en texto sin formato. Se trata de una amenaza crítica, hasta tal punto que ya se han detectado versiones de los infostealers RedLine y Lumma con rutas de archivos OpenClaw añadidas a sus listas de archivos que deben robar. Además, el infostealer Vidar fue sorprendido robando secretos de OpenClaw.

Habilidades maliciosas

La funcionalidad de OpenClaw se puede ampliar con las “habilidades” disponibles en el repositorio de ClawHub. Dado que cualquiera puede cargar una habilidad, los actores maliciosos no tardaron en empezar a “incluir” el infostealer AMOS para macOS en sus cargas. En poco tiempo, la cantidad de habilidades maliciosas llegó a cientos. Esto llevó a los desarrolladores a firmar rápidamente un acuerdo con VirusTotal para garantizar que todas las habilidades cargadas no solo se verifiquen con las bases de datos de malware, sino que también se sometan a análisis de código y contenido a través de LLM. Dicho esto, los autores son muy claros: no es una fórmula mágica.

Defectos estructurales en el agente de IA de OpenClaw

Las vulnerabilidades se pueden parchear y la configuración se puede reforzar, pero algunos de los problemas de OpenClaw son fundamentales para su diseño. El producto combina varias funciones críticas que, cuando se combinan, son francamente peligrosas:

• OpenClaw tiene acceso privilegiado a datos confidenciales en la máquina host y en las cuentas personales del propietario.
• El asistente está totalmente expuesto a datos no fiables: el agente recibe mensajes a través de aplicaciones de chat y correo electrónico, navega de forma autónoma por páginas web, etc.
• Sufre de la incapacidad inherente de los LLM para separar de manera confiable los comandos de los datos, lo que hace posible la inyección de comandos.
• El agente guarda los puntos clave y los artefactos de sus tareas para informar sobre acciones futuras. Esto significa que una sola inyección exitosa puede contaminar la memoria del agente, lo que influye en su comportamiento a largo plazo.
• OpenClaw tiene la capacidad de comunicarse con el mundo exterior: enviar correos electrónicos, realizar llamadas API y utilizar otros métodos para extraer datos internos.

Cabe señalar que, aunque OpenClaw es un ejemplo especialmente extremo, la lista de los “Cinco terroríficos” es en realidad característica de casi todos los agentes de IA polivalentes.

Riesgos de OpenClaw para las organizaciones

Si un empleado instala un agente como este en un dispositivo corporativo y lo conecta incluso a un conjunto básico de servicios (como Slack y SharePoint), la combinación de ejecución autónoma de comandos, amplio acceso al sistema de archivos y permisos OAuth excesivos crea un terreno fértil para una vulneración profunda de la red. De hecho, la costumbre del bot de acumular secretos y tokens sin cifrar en un solo lugar es un desastre anunciado, incluso si el agente de IA en sí nunca se ve vulnerado.

Además, estas configuraciones infringen los requisitos normativos de múltiples países y sectores, lo que puede dar lugar a posibles multas y fallos en las auditorías. Los requisitos reglamentarios actuales, como los de la Ley de IA de la UE o el Marco de gestión de riesgos de IA del NIST, exigen explícitamente un control de acceso estricto para los agentes de IA. El enfoque de configuración de OpenClaw claramente no cumple con esos estándares.

Pero lo más sorprendente es que, aunque se les prohíba a los empleados instalar este software en los equipos del trabajo, OpenClaw puede acabar instalándose en sus dispositivos personales. Esto también genera riesgos específicos para la organización en su conjunto:

• Los dispositivos personales suelen almacenar el acceso a sistemas de trabajo, como configuraciones VPN corporativas o tokens de navegador para el correo electrónico y herramientas internas. Estos datos pueden secuestrarse para obtener un punto de apoyo en la infraestructura de la empresa.
• Controlar al agente a través de aplicaciones de chat significa que no solo el empleado se convierte en blanco de ingeniería social, sino también su agente de IA, lo que hace que la apropiación de cuentas de IA o la suplantación de identidad del usuario en chats con compañeros de trabajo (entre otras estafas) se conviertan en una realidad. Aunque solo se hable del trabajo de vez en cuando en las charlas personales, la información que contienen está lista para ser aprovechada.
• Si un agente de IA en un dispositivo personal está conectado a cualquier servicio corporativo (correo electrónico, mensajería, almacenamiento de archivos), los atacantes pueden manipular el agente para extraer datos, y esta actividad sería extremadamente difícil de detectar para los sistemas de supervisión corporativos.

Cómo detectar OpenClaw

Dependiendo de las capacidades de supervisión y respuesta del equipo del SOC, pueden rastrear los intentos de conexión de la puerta de enlace de OpenClaw en dispositivos personales o en la nube. Además, una combinación específica de banderas rojas puede indicar la presencia de OpenClaw en un dispositivo corporativo:

• Busca los directorios ~/.openclaw/, ~/clawd/ o ~/.clawdbot en las máquinas host.
• Analiza la red con herramientas internas o públicas, como Shodan, para identificar las huellas digitales HTML de los paneles de control de Clawdbot.
• Supervisa el tráfico de WebSocket en los puertos 3000 y 18789.
• Presta atención a los mensajes de difusión mDNS en el puerto 5353 (concretamente openclaw-gw.tcp).
• Vigila los intentos de autenticación inusuales en los servicios corporativos, como nuevos registros de ID de aplicaciones, eventos de consentimiento OAuth o cadenas de agente de usuario típicas de Node.js y otros agentes de usuario no estándar.
• Busca patrones de acceso típicos de la recolección automatizada de datos: lectura de grandes cantidades de datos (extracción de todos los archivos o todos los correos electrónicos) o análisis de directorios a intervalos fijos fuera del horario laboral.

Control de la IA en la sombra

Un conjunto de prácticas de higiene de seguridad puede reducir de manera eficaz la huella tanto de la TI en la sombra como de la IA en la sombra, lo que dificulta mucho más la implementación de OpenClaw en una organización:

• Usa la lista de admitidos a nivel de host para garantizar que solo se instalen las aplicaciones e integraciones en la nube aprobadas. Para los productos que admiten extensibilidad (como las extensiones de Chrome, los complementos de VS Code o las habilidades de OpenClaw), implementa una lista cerrada de complementos verificados.
• Realiza una evaluación de seguridad completa de cualquier producto o servicio, incluidos los agentes de IA, antes de permitirles conectarse a los recursos corporativos.
• Trata a los agentes de IA con los mismos requisitos de seguridad rigurosos que se aplican a los servidores públicos que procesan datos corporativos confidenciales.
• Implementa el principio de privilegios mínimos para todos los usuarios y otras identidades.
• No otorgues privilegios administrativos sin una necesidad comercial crítica. Exígeles a todos los usuarios con permisos ampliados que los utilicen solo cuando realicen tareas específicas, en lugar de trabajar desde cuentas con privilegios todo el tiempo.
• Configura los servicios corporativos para que las integraciones técnicas (como las aplicaciones que solicitan acceso OAuth) reciban solo los permisos mínimos.
• Audita periódicamente las integraciones, los tokens de OAuth y los permisos concedidos a aplicaciones de terceros. Revisa la necesidad de estos permisos con los propietarios de la empresa, revoca proactivamente los permisos excesivos y elimina las integraciones obsoletas.

Implementación segura de IA basada en agentes

Si una organización permite el uso de agentes de IA con fines experimentales, por ejemplo, para pruebas de desarrollo o proyectos piloto de eficacia, o si se han autorizado casos de uso específicos de IA para el personal en general, se deben implementar medidas sólidas de supervisión, registro y control de acceso:

• Implementa agentes en una subred aislada con reglas de entrada y salida estrictas, a fin de limitar la comunicación solo a los hosts de confianza requeridos para la tarea.
• Utiliza tokens de acceso de corta duración con un alcance de privilegios estrictamente limitado. Nunca entregues a un agente tokens que otorguen acceso a los servidores o servicios centrales de la empresa. Idealmente, crea cuentas de servicio dedicadas para cada prueba individual.
• Protege al agente de herramientas peligrosas y conjuntos de datos que no son relevantes para su trabajo específico. Para implementaciones experimentales, se recomienda probar el agente con datos puramente sintéticos que imiten la estructura de los datos de producción reales.
• Configura el registro detallado de las acciones del agente. Debe incluir registros de eventos, parámetros de línea de comandos y artefactos de la cadena de pensamiento asociados con cada comando que ejecuta.
• Configura SIEM para marcar la actividad anormal del agente. Las mismas técnicas y reglas que se utilizan para detectar ataques LotL son aplicables aquí, aunque se requieren esfuerzos adicionales para definir cuál es la actividad normal de un agente específico.
• Si se utilizan servidores MCP y habilidades de agente adicionales, analízalos con las herramientas de seguridad emergentes para estas tareas, como skill-scanner, mcp-scanner o mcp-scan. Específicamente para las pruebas de OpenClaw, varias empresas ya han lanzado herramientas de código abierto para auditar la seguridad de sus configuraciones.

Directivas corporativas y formación de los empleados

La prohibición total de todas las herramientas de IA es un camino sencillo, pero raramente productivo. Los empleados suelen encontrar formas de sortear las restricciones, lo que hace que el problema pase a un segundo plano y sea aún más difícil de controlar. En cambio, es mejor encontrar un equilibrio sensato entre productividad y seguridad.

Implementa directivas transparentes sobre el uso de IA activa. Define qué categorías de datos pueden procesar los servicios externos de IA y cuáles están estrictamente prohibidas. Los empleados deben comprender por qué algo está prohibido. Una directiva de “sí, pero con restricciones” siempre se recibe mejor que un “no” rotundo.

Utiliza ejemplos del mundo real en las formaciones. Las advertencias abstractas sobre los “riesgos de fugas” tienden a ser inútiles. Es mejor demostrar cómo un agente con acceso al correo electrónico puede reenviar mensajes confidenciales solo porque un correo electrónico entrante aleatorio lo solicita. Cuando la amenaza se siente real, la motivación para seguir las reglas también aumenta. Lo ideal sería que los empleados completaran un [KASAP placeholder] breve curso intensivo sobre seguridad en materia de IA [/placeholder].

Ofrece alternativas seguras. Si los empleados necesitan un asistente de IA, proporciona una herramienta aprobada que presente administración centralizada, registro y control de acceso OAuth.