TL; DR
SilverfortEl equipo de investigación de seguridad de identificó una vulnerabilidad crítica en ClawHub que permite a cualquier atacante posicionar su habilidad como la número 1 en ClawHub. Al hacerlo, un atacante puede inyectar código malicioso dentro de lo que parece ser una habilidad legítima y confiable, creando la base para un ataque a gran escala a la cadena de suministro. Como resultado, un gran número de usuarios y agentes de OpenClaw podrían descargar la habilidad comprometida y ejecutar código malicioso en sus máquinas, potencialmente con privilegios elevados. En nuestra prueba de concepto, nuestra habilidad saltó a la posición número 1 de descargas en su categoría, lo que resultó en 3,900 ejecuciones de habilidades within 6 días En más de 50 ciudades diferentes de todo el mundo, incluidas varias empresas que cotizan en bolsa.
Este problema fue comunicado de manera responsable al equipo de ClawHub el 16 de marzo de 2026 y desde entonces ha sido solucionado satisfactoriamente.
Para reducir el riesgo de tales cadenas de ataque, nuestro equipo desarrolló ClawNet: Un complemento de seguridad para OpenClaw que analiza las habilidades en busca de patrones maliciosos durante la instalación utilizando el LLM del agente, luego informa al usuario y bloquea las instalaciones sospechosas.
¿Qué es ClawHub?
ClawHub es el registro público de habilidades de OpenClaw, donde cualquiera puede publicar un paquete de habilidades para que otros lo instalen. Una habilidad podría, por ejemplo, permitir que su agente de OpenClaw se integre con Google Calendar o realice búsquedas web optimizadas en su nombre. Es el npm del ecosistema de agentes de OpenClaw. La plataforma ClawHub ha estado creciendo rápidamente, con muchas habilidades que ya alcanzan cifras masivas de descargas (¿Quieres una introducción a OpenClaw? Puedes leer más aquí.).
A medida que crece la popularidad de ClawHub, también aumenta su atractivo para los atacantes. La posibilidad de publicar habilidades en un mercado que los usuarios consultan e instalan activamente crea una gran oportunidad para la cadena de suministro.
Un método de ataque clásico consistiría en publicar una habilidad maliciosa y esperar a que los usuarios la instalen. Sin embargo, inyectar código malicioso en una habilidad aparentemente inofensiva no es suficiente: para que se instale de forma generalizada, la habilidad debe parecer confiable. En ClawHub, al igual que en muchos registros públicos como npm o el Marketplace de VS Code, la confianza suele inferirse de su popularidad.
El código de ClawHub es casi completamente codificado por vibracionesSi bien este enfoque tiene sus ventajas, también puede generar problemas de seguridad críticos. Al analizar la implementación de la acción de descarga en ClawHub, identificamos una vulnerabilidad que permite transformar las señales de confianza basadas en descargas en una cadena de ataque escalable.
Encontrar una habilidad en ClawHub
Supongamos que desea instalar una habilidad que permita a su agente de OpenClaw programar reuniones en Google Calendar. Para ello, deberá acceder a ClawHub (ya sea a través de la interfaz web o la línea de comandos) y buscar el paquete de habilidades correspondiente. Una vez que reciba los resultados de la búsqueda, lo primero que notará es el número de descargas de la habilidad. Cuantas más descargas tenga una habilidad, más arriba aparecerá en los resultados de búsqueda.
Cada paquete de habilidades incluye un SKILL.MD Este archivo le indica al agente el propósito de la habilidad, las dependencias que requiere y cuándo y cómo debe usarse. Algunas habilidades pueden incluir scripts que el agente puede ejecutar bajo ciertas circunstancias.
Profundizando en la investigación
Analizando la API de descarga
El código de ClawHub está abierto al público (por suerte para nosotros). Durante nuestra investigación, descubrimos que expone una API de descarga de habilidades a través de una downloadZip función. En resumen, antes de que se contabilice una descarga, la solicitud debe pasar por varias comprobaciones de validación:
- Límite de velocidad: Demasiadas solicitudes desde la misma IP o usuario y se bloqueará su acceso.
- Deduplicación: incluso si superas el límite de velocidad, la misma IP o usuario que acceda a la misma habilidad dentro de la misma hora no se volverá a contabilizar.
A primera vista, parece un diseño defensivo sólido, hasta que se profundiza un poco más en su implementación.
Omitir el punto final de la API de frontend
ClawHub utiliza Convexo como su marco de trabajo de backend. Al examinar el código fuente de ClawHub, se encontraron dos puntos finales interesantes accesibles públicamente:
- La URL del sitio Convex: sirve como interfaz de usuario para la API HTTP. Acciones como la descarga de habilidades, la lista de usuarios y la búsqueda de habilidades se ejecutan detrás de ella.
- La URL de despliegue de Convex es un poco diferente. Este habla directamente al Capa RPC de backend convexa—Sin middleware de acción HTTP, sin manejo de solicitudes personalizado. Solo llamadas a funciones directas al backend.
Un vistazo más de cerca a la biblioteca Convex
Convex es un framework de backend basado en un modelo RPC (Llamada a Procedimiento Remoto) tipado. En un modelo RPC, en lugar de enviar solicitudes HTTP a puntos finales REST o GraphQL, se llaman funciones de backend directamente desde el cliente. Cada función que definas se registra y se puede invocar automáticamente; considérala como un punto final independiente.
Convex establece una clara distinción entre funciones invocables públicas y privadas:
- Funciones internas:
internalQuery / internalMutation / internalAction
Privado por diseño. Solo puede ser invocado por otras funciones de Convex del lado del servidor, completamente invisible para el mundo exterior. - Funciones publicas:
query / mutation / action
Se expone a través de la URL de despliegue de Convex y puede ser llamada por cualquiera que conozca o adivine el nombre de la función. Según la documentación de Convex, si una función se define como pública, cualquiera puede llamarla mediante una solicitud HTTP de la siguiente manera:
Estas funciones deben utilizarse, por supuesto. muy Con cuidado. Deben validar la entrada del cliente y verificar los permisos para usar la función antes de realizar cualquier cambio en la base de datos del servidor.
Descubriendo la función vulnerable
Dentro de downloads.ts hay una función llamada increment. Mientras que el flujo de descarga legítimo pasa por un sistema fuertemente protegido mutación interna que impone límites de velocidad, deduplicación y comprobaciones de permisos, Esta función omite todo eso por completo.:
Sin autenticación. Sin límite de velocidad. Sin deduplicación. Sin comprobaciones de permisos de ningún tipo.
Claramente estaba destinado a ser un función interna pero fue definido como un público mutation en lugar de internalMutationEse único error lo expone como un punto final RPC invocable en la URL de implementación, público para todo el mundo.
Un atacante puede llamar a downloads:increment con una sola solicitud curl con cualquier skillId válido, eludiendo todas las protecciones en el flujo de descarga y ¡Inflar el contador de descargas de cualquier habilidad sin límite!
Así es como se ve:
Obtener el ID de despliegue y el ID de habilidad es trivial, ya que ambos están expuestos en el tráfico de red del cliente y se pueden observar inspeccionando las respuestas del servidor ClawHub.
Formando la cadena de ataque
Paso 1: Crear la habilidad maliciosa
El ataque comienza creando y publicando una habilidad que parece completamente legítima. Para esta demostración, creamos una Integración de Outlook Graph skill: una utilidad que permite a un agente de OpenClaw programar reuniones, gestionar los correos electrónicos de un usuario y mucho más.
Oculto en el script de la habilidad se encuentra un sencillo código malicioso para la extracción de datos. Cuando OpenClaw invoca la habilidad, esta recopila el nombre de usuario y el nombre de dominio completo (FQDN) del cliente y los envía a un servidor que controlamos. Para los fines de esta investigación, el código malicioso tiene un impacto mínimo y no es destructivo.
La carga útil estaba incrustada dentro de una función "send_telemetry" aparentemente legítima y, como resultado, la habilidad no fue identificada como maliciosa.
Por supuesto, un atacante real Esto haría que esta carga útil fuera mucho más sofisticada; podrían recopilar variables de entorno, rutas de archivos locales, tokens almacenados en la memoria o cualquier otra cosa accesible dentro del contexto de ejecución de la habilidad.
Paso 2: Aumentar el contador de descargas
Aquí es donde el ataque se vuelve particularmente interesante desde la perspectiva de la cadena de suministro. Ya tenemos una habilidad maliciosa en ClawHub, pero una habilidad con cero descargas no va a llegar a nadie. ¿Quién querría instalar una habilidad que nadie ha probado? Necesitábamos que pareciera confiable.
Así que creamos una herramienta sencilla para lograr precisamente eso. Aprovechando la vulnerabilidad que encontramos en el código fuente, pudimos saturar la base de datos de estadísticas con solicitudes para insertar un evento estadístico, incrementando el contador de descargas de nuestra habilidad maliciosa. ¿Cuántas descargas? ¡Todas las que quisiéramos! Sin límites de velocidad, sin validación, sin nada que nos detuviera.
En cuestión de minutos, el contador de descargas de nuestra habilidad aumentó significativamente.suficiente para impulsar la habilidad a la cima de los resultados de búsqueda en su categoría..
Paso 3: Observar cómo aterriza
Después de la inflación de descargas, los usuarios comenzaron a descubrir e instalar la habilidad. El resultado: Acerca de 3,900 ejecuciones de habilidades within 6 días Más de 50 ciudades diferentes en todo el mundo, incluidas varias empresas públicas.
Todas estas ejecuciones desencadenaron una solicitud HTTP a nuestro servidor que incluía el nombre de dominio y el nombre de usuario como parte de la ejecución legítima de la habilidad.
Esto demuestra lo poderosas que pueden ser estas cadenas de ataque. La habilidad se ejecuta en nombre del usuario con altos privilegios que opera el agente OpenClaw. En este caso, solo recopilamos el nombre de usuario y el dominio, pero un atacante real podría aprovechar esta información para realizar acciones mucho más dañinas.
OpenClaw cae en la misma trampa.
Si los usuarios humanos pueden caer en la trampa de las descargas, ¿qué sucede cuando delegamos la decisión a nuestro agente de OpenClaw?
Cuando se le pide que encuentre la mejor habilidad para un requisito determinado, el agente realiza una búsqueda en ClawHub a través de la CLI de ClawHub y selecciona una habilidad de los resultados según su nombre, slug, resumen y puntuación. Si bien la decisión final sobre qué habilidad instalar la toma el LLM, la puntuación de la habilidad —que influye en esa decisión según el código— se ve afectada por la semántica del contenido y, bueno… el número de descargas.
Así pues, le pedimos a nuestro agente de OpenClaw que eligiera una habilidad para gestionar el correo electrónico y las tareas del calendario, y, como era de esperar, seleccionó la habilidad maliciosa que habíamos publicado. En su explicación, indicó que eligió esa habilidad porque tenía la puntuación más alta (resultado del elevado número de descargas).
Protegiendo su agente OpenClaw de habilidades maliciosas
Dado que OpenClaw permite la instalación y ejecución autónoma de habilidades, es fundamental garantizar que las habilidades que instale sean seguras y fiables, como ya hemos visto.
Para ayudar a reducir el riesgo, recomendamos instalar nuestro Complemento de seguridad ClawNet para OpenClawClawNet utiliza el bucle del agente OpenClaw para interceptar las llamadas a las herramientas implicadas en la instalación de habilidades. Antes de instalar una habilidad, ClawNet solicita al LLM del agente que revise su contenido e identifique patrones potencialmente maliciosos. A continuación, entrega los resultados al usuario y decide si se debe bloquear o permitir la instalación.
Nuestra decisión de implementar esto como un plugin preferible a habilidad Se trata de una decisión de seguridad. El LLM puede omitir o ignorar una habilidad, ya sea por una inferencia incorrecta o porque el modelo no es fiable a la hora de seguir el flujo de gestión de habilidades previsto. Un complemento, por otro lado, se integra directamente en el bucle del agente OpenClaw e intercepta los intentos de instalación de habilidades en tiempo de ejecución, garantizando que la comprobación se ejecute independientemente del comportamiento del LLM.
¿Qué podemos aprender de esto?
La codificación Vibe no es una estrategia de seguridad.
La programación basada en la intuición permite un desarrollo rápido, pero no sustituye las prácticas de seguridad estructuradas. Si bien la IA puede crear sistemas extraordinarios, sigue siendo propensa a errores. La supervisión humana sigue siendo esencial durante el desarrollo, ya que pequeños detalles de implementación pueden tener importantes implicaciones para la seguridad.
El número de descargas no puede ser su único indicador de confianza.
Si bien puede resultar tentador confiar en algo simplemente porque otros lo hacen, la popularidad no es una garantía de seguridad. El número de descargas no dice nada sobre la integridad del código, los procesos de revisión ni el comportamiento seguro. Cuando estas señales se utilizan como datos de entrada para la toma de decisiones, especialmente por sistemas automatizados, pueden convertirse en un vector de manipulación. En cambio, los usuarios/agentes deberían verificar el origen de cualquier habilidad y utilizar un escáner de habilidades especializado como el nuestro. Complemento ClawNet para OpenClawpara garantizar que los archivos no contengan patrones sospechosos antes de la instalación.
El desarrollo de RPC requiere límites de seguridad explícitos.
A diferencia de las API REST (donde las rutas, el middleware y las capas de validación suelen estar separadas por diseño), los marcos basados en RPC, como Convexo Permite a los desarrolladores exponer funciones invocables directamente desde el código del backend. Esto puede aumentar el riesgo de comprobaciones de autorización o validación de entrada insuficientes. Las mejores prácticas de Convex enfatizar explícitamente este punto, recomendando “Utilice algún tipo de control de acceso para todas las funciones públicas”.Si bien las arquitecturas RPC no son inseguras por defecto, requieren un control de acceso estricto, una validación cuidadosa y el cumplimiento de las mejores prácticas documentadas.
Tu agente de OpenClaw puede convertirse en un riesgo para la seguridad.
El poder de OpenClaw reside en su autonomía: su capacidad para buscar, evaluar e instalar habilidades sin intervención humana. Sin embargo, esa misma autonomía conlleva riesgos. Sin mecanismos de verificación e inspección rigurosos, la toma de decisiones autónoma de nuestro agente puede, involuntariamente, ampliar la superficie de ataque.
Los agentes de IA constituyen su propia clase de identidad.
Los agentes de IA son su propia clase de identidad que requiere el mismo nivel de descubrimiento, control en tiempo real y endurecimiento de la postura como usuarios humanos tradicionales e identidades no humanas. Cada agente debe estar vinculado a un propietario humano, y las políticas de acceso deben estar definidas y asignadas. El resultado es que los agentes solo pueden hacer aquello para lo que tienen permiso explícito. Sin privilegios permanentes. Sin excepciones.
Divulgación y solución
La vulnerabilidad fue reportada al equipo de seguridad de OpenClaw, incluyendo su impacto y detalles técnicos. El equipo respondió rápidamente y fue altamente colaborativo durante todo el proceso, resolviendo el problema en menos de 24 horas y desplegar la solución en producción (ver commit de Peter Steinberger, el desarrollador principal de OpenClaw, aquí).
