Moltbot (antes conocido como Clawdbot) se ha convertido en uno de los proyectos de IA de código abierto de crecimiento más rápido en 2026, acumulando más de 93 000 estrellas en GitHub en pocas semanas. Su propuesta —un asistente de IA personal que se integra con WhatsApp, Telegram, Slack, Discord y otros servicios— también lo ha situado en el centro del debate sobre seguridad de agentes de IA.
Moltbot como agente de IA de alto privilegio: qué acceso obtiene
A diferencia de un chatbot clásico, Moltbot funciona como un agente proactivo: planifica tareas a partir del calendario, envía recordatorios, mantiene memoria a largo plazo en archivos Markdown y SQLite, y puede gestionar navegador, correo electrónico y ficheros locales en segundo plano. En la práctica, se le delegan conversaciones de trabajo, accesos a servicios en la nube e incluso credenciales sensibles.
Para operar con este nivel de autonomía, Moltbot requiere claves de API de modelos de lenguaje comerciales (como Claude Opus 4.5), acceso a mensajería y email, tokens OAuth y cuentas de terceros. En algunas instalaciones llega a disponer de permisos para ejecutar comandos de shell. Esta combinación convierte al asistente en un claro ejemplo de “una sola brecha, acceso completo”.
Extensión maliciosa de VS Code que se hacía pasar por Moltbot
ClawdBot Agent y uso abusivo de herramientas de acceso remoto
La empresa de seguridad Aikido detectó en el Marketplace de Visual Studio Code una extensión maliciosa denominada “ClawdBot Agent — AI Coding Assistant”, que se presentaba como complemento oficial de Moltbot, pese a que el proyecto no dispone de ningún plugin legítimo para VS Code. La extensión se ejecutaba automáticamente al abrir la IDE, descargaba un fichero config.json remoto y lanzaba un binario Code.exe.
Ese ejecutable instalaba ScreenConnect, una solución de acceso remoto legítima pero utilizada en este caso para establecer un control remoto persistente sobre el equipo del desarrollador. El malware incorporaba mecanismos de contingencia: si el servidor principal de mando y control no respondía, recuperaba DLL desde Dropbox u otros dominios alternativos. Microsoft retiró la extensión, pero se desconoce cuántos desarrolladores la instalaron confiando en la marca Moltbot, ilustrando el riesgo de ataques a la cadena de suministro dirigidos a ecosistemas de desarrolladores.
Instancias de Moltbot expuestas y fuga de secretos por mala configuración
Reverse proxy mal configurado y paneles abiertos en Internet
El investigador Jamison O’Reilly (Dvuln) identificó cientos de instancias de Moltbot accesibles sin autenticación desde Internet. El origen era un patrón frecuente de mala práctica: un reverse proxy configurado para confiar de forma implícita en supuestos orígenes “locales”, de forma que todo el tráfico externo era tratado como de confianza.
A través de estas consolas abiertas se podían visualizar y extraer API keys y tokens OAuth, leer historiales de conversación, ejecutar comandos y robar credenciales. O’Reilly verificó manualmente varias decenas de sistemas y halló al menos ocho instalaciones totalmente desprotegidas, incluida una con integración de Signal que exponía tanto el historial de mensajes como URI y códigos QR válidos para vincular nuevos dispositivos.
Riesgos en MoltHub y ataques a la cadena de suministro de skills
Paralelamente, el mismo investigador demostró un ataque de prueba de concepto contra MoltHub, el repositorio de skills o módulos de capacidades de Moltbot. Publicó un paquete inocuo con una simple carga útil de “ping”, infló artificialmente su contador de descargas por encima de las 4 000 y comprobó que desarrolladores de al menos siete países lo estaban usando. En un escenario real, un módulo de este tipo podría extraer discretamente claves SSH, credenciales de AWS y código fuente, reproduciendo patrones ya conocidos en ataques a dependencias de npm o PyPI.
Secretos en texto claro y conversión del asistente en puerta trasera
Un análisis de Hudson Rock reveló que Moltbot almacena parte de sus secretos en texto claro en archivos Markdown y JSON en el equipo local. Esto facilita el trabajo a familias de malware especializadas en robo de información (infostealers) como Redline, Lumma o Vidar, que pueden obtener sin esfuerzo tokens, claves y el histórico de interacciones con el asistente.
Los investigadores apuntan además que distintas variantes de malware ya están adaptando sus rutinas para reconocer la estructura de directorios de Moltbot. Con permisos de escritura, un atacante puede modificar ficheros de configuración y transformar el agente en un bastidor de acceso remoto encubierto, que confíe en fuentes maliciosas, exfiltre datos de forma automática o ejecute órdenes arbitrarias recibidas por canales que parecen legítimos.
Rebranding, secuestro de marca y estafa con el token $CLAWD
El cambio de nombre de Clawdbot a Moltbot, solicitado por Anthropic para evitar confusión con Claude, abrió otro frente de abuso. Durante la transición de la organización en GitHub y el alias en X (Twitter), actores maliciosos aprovecharon para tomar el control temporal de los identificadores antiguos y promocionar un token fraudulento llamado $CLAWD. La capitalización de este criptoactivo llegó a rondar los 16 millones de dólares antes de desplomarse a cero. El desarrollador Peter Steinberger ha reiterado que cualquier proyecto cripto asociado a su nombre es un fraude, poniendo de relieve la facilidad con la que los atacantes explotan el interés en proyectos de IA populares para campañas de phishing y rug pulls.
Agentes de IA frente a la seguridad tradicional: qué lecciones deja Moltbot
Firmas como Salt Security e Intruder subrayan la brecha entre el entusiasmo por los agentes de IA y la madurez real en su despliegue seguro. Moltbot prioriza la sencillez de instalación frente al enfoque “secure by default”: no impone cortafuegos estrictos, controles de acceso granulares ni aislamiento robusto de plugins. Sin embargo, el modelo de amenaza de un asistente de este tipo es comparable al de una cuenta de administrador o un servidor crítico.
Por diseño, estos agentes requieren amplios privilegios sobre archivos, secretos, ejecución de comandos y acceso a servicios externos. Cuando son comprometidos —ya sea mediante una instancia expuesta, una extensión maliciosa o un skill manipulado— el atacante hereda automáticamente ese nivel de acceso, anulando capas de defensa tradicionales como la segmentación de red o el principio de mínimo privilegio. Algunas organizaciones tratan de mitigar el riesgo ejecutando Moltbot en hardware dedicado (por ejemplo, un Mac Mini aislado) con identidades y buzones de correo exclusivos, lo que reduce el impacto potencial, pero no elimina el problema de fondo: la concentración de riesgo en un único agente de IA de alto privilegio.
El caso Moltbot demuestra que los asistentes de IA de código abierto pueden convertirse rápidamente en un imán para atacantes: desde extensiones falsas y fugas de API keys hasta abusos de marca y ataques a la cadena de suministro de plugins. Organizaciones y usuarios que evalúen desplegar agentes de IA con acceso a información sensible deberían tratarlos como infraestructura crítica: alojarlos en sistemas aislados, aplicar el principio de mínimos privilegios, reforzar la configuración de reverse proxies, usar gestores de secretos en lugar de archivos en texto claro, limitar y auditar extensiones y skills, activar monitorización y registro detallado, y revisar periódicamente permisos y tokens. Invertir en arquitectura segura desde el inicio suele ser mucho menos costoso que responder a una intrusión en un agente de IA que concentra todas las llaves del entorno digital.
