Skills maliciosos de Claude: lo que reveló ejecutar 1.672

Skills maliciosos de Claude: lo que reveló ejecutar 1.672

Tras ejecutar 1.672 skills de Claude, el riesgo real no es el malware

Cuando se trata de herramientas para desarrolladores como los skills de Claude, el miedo a la seguridad se traduce en una búsqueda de malware clásico: ladrones de credenciales ocultos, comandos de shell ofuscados y otras cargas útiles encubiertas. Ese miedo está bien fundado. La auditoría ToxicSkills de Snyk analizó 3.984 skills de ClawHub y skills.sh al 5 de febrero de 2026 y encontró patrones de inyección de prompts en el 36% del ecosistema, 534 skills con problemas críticos de seguridad y 76 cargas útiles maliciosas confirmadas por revisión humana, de las cuales 8 seguían activas en clawhub.ai al momento de la publicación. En el incidente paralelo de ClawHavoc, se retiraron 341 skills maliciosos del registro de ClawHub. Los skills de agentes maliciosos no son hipotéticos.

Por lo tanto, vale la pena ser precisos sobre lo que encontramos y sobre lo que nuestro número significa y no significa. En SkillProof instalamos y ejecutamos cada skill que listamos, y luego publicamos el resultado, ya sea que pase o falle. Al momento de escribir esto, hemos probado 1.672 skills: 1045 pasan (una tasa de aprobación del 63%), 560 necesitan configuración manual y 67 obtuvieron una puntuación inferior a la de Claude sin ningún skill instalado. No conocemos otro directorio que publique sus veredictos de fallo junto con los de aprobación.

En esas 1.672 pruebas ejecutadas, encontramos cero instancias de malware encubierto. Ese resultado viene con un gran asterisco: nuestro catálogo no es una muestra aleatoria de un registro público. Los candidatos son preseleccionados por su calidad antes de llegar a una ranura de prueba, los repositorios de baja calidad y de spam se mantienen en una lista de bloqueo, y los skills que sobreviven hasta un veredicto publicado son los que ya tienen probabilidades de ser legítimos. Snyk muestreó el registro; nosotros muestreamos la parte que vale la pena instalar. Ambas cifras son ciertas y responden a preguntas diferentes.

Para lo que sirve nuestra muestra es para la pregunta que nadie más está respondiendo: una vez que has filtrado el malware obvio, ¿de qué queda preocuparse? La respuesta, de forma reproducible, es el radio de impacto de los permisos y capacidades de skills legítimos y útiles. Ese riesgo es más difícil de detectar, porque la mayor parte reside en lo que un skill te pide que apruebes en el momento de la instalación y en el de la ejecución.

Lo que no encontramos: la ausencia de cargas útiles encubiertas

Seamos directos. En más de mil seiscientas ejecuciones únicas de skills, encontramos:

  • Cero instancias de exfiltración encubierta de credenciales a un servidor desconocido.
  • Cero instancias de una carga útil curl | sh oculta dentro de los propios archivos de un skill. Varios skills sí que incluyen un instalador curl | bash en el README de su repositorio, y en un caso la instalación de la CLI de terceros no se menciona en absoluto en el SKILL.md. Esos son pasos de instalación revelados que puedes leer antes de ejecutar, no cargas útiles ocultas, pero vale la pena tenerlos en cuenta.
  • Cero instancias de cargas útiles ofuscadas con base64 u otras técnicas de ofuscación clásicas diseñadas para ocultar la intención.
  • Cero instrucciones ocultas dentro de un archivo SKILL.md que difirieran del propósito público del skill.

La búsqueda de ejemplos concretos de malware en nuestro conjunto de pruebas resulta vacía. Lo que eso no significa es que el escaneo sea inútil. Significa que los escáneres que la mayoría de la gente utiliza están ajustados para las firmas incorrectas. Una herramienta que busca patrones de código malicioso no devuelve nada en nuestra muestra; una herramienta ajustada para patrones de permisos y capacidades capturaría la mayor parte de lo que registramos, porque esos patrones están ahí mismo en el texto del archivo. La brecha está en lo que buscas, no en si la búsqueda funciona. La ejecución aún captura lo que ninguno de los dos encuentra: qué permisos solicita realmente un skill cuando lo ejecutas y qué escribe en tu configuración una vez que dices que sí. Para una mirada más profunda a nuestro proceso, consulta cómo probamos los skills de Claude.

La amenaza real: el radio de impacto de los permisos en skills legítimos

Los problemas de seguridad más significativos que encontramos estaban en skills que, por lo demás, son funcionales y valiosos. Dos de los cinco skills a continuación pasan nuestras pruebas de funcionalidad directamente; los otros tres están condicionados a una configuración previa. Ninguno de ellos es malicioso. El peligro que introducen no es de malicia, sino de capacidad excesiva. Su 'radio de impacto' —el alcance de lo que pueden hacer con los permisos que se les otorgan— es innecesariamente grande. Estos no son necesariamente skills de Claude peligrosos que deban evitarse por completo, pero requieren un manejo cuidadoso y una comprensión de los permisos que estás otorgando.

Acceso excesivamente amplio al sistema de archivos

Un patrón común es solicitar permisos del sistema de archivos mucho más allá de lo que el skill necesita para operar. Un excelente ejemplo es UCTM Init, un inicializador de proyectos para el pipeline de plugins de uc-taskmanager. Durante la configuración, presenta un aviso genérico para aplicar "ajustes recomendados", lo que incluye escribir permisos amplios de Read/Edit/Write(/**) en el archivo de configuración local .claude/settings.local.json. En nuestra ejecución en un proyecto desde cero, esa única aprobación hizo dos cosas distintas: escribió las entradas comodín de lectura/edición/escritura, que son el verdadero radio de impacto en el sistema de archivos, y fusionó 34 permisos de Bash con nombre en la configuración del proyecto. Las entradas de Bash con nombre son una lista de comandos permitidos enumerada y son la mitad más defendible; el comodín es la parte que hay que leer antes de hacer clic en 'sí'. El skill funciona y pasa nuestras pruebas, pero el alcance que estás aprobando es mucho más amplio que la tarea que tienes entre manos.

Tokens de API perpetuos y sin alcance definido

Otro problema recurrente es el manejo de las claves de API. El skill Add Vercel, que conecta las credenciales de despliegue de Vercel en los contenedores de agentes de NanoClaw, instruye al usuario para que cree un token de API de Vercel con alcance de "Full Account" y sin fecha de caducidad. Luego asigna este poderoso token a cada agente. Un agente comprometido o con errores podría, en teoría, usar este token para leer, modificar o eliminar cualquier proyecto, equipo o configuración dentro de toda la cuenta de Vercel. La solución es simple —crear un token con un alcance limitado y rotarlo— pero el camino por defecto crea un riesgo significativo.

El 'footgun' de --dangerously-skip-permissions

Claude Code incluye un flag, --dangerously-skip-permissions, que omite las solicitudes de confirmación interactivas para una ejecución; la propia documentación de Anthropic aconseja restringirlo a un contenedor o una VM. Es una característica conocida para usuarios avanzados, pero encontramos varios skills que normalizan su uso, incorporándolo en comandos predeterminados o configuraciones persistentes. Una sesión interactiva muestra un diálogo de aceptación único la primera vez que se entra en ese modo, que es precisamente lo que una configuración persistente elude. El resultado convierte una anulación deliberada y por ejecución en un estado invisible y permanente de seguridad reducida.

Skill Contexto del uso del flag Riesgo
OMA Image Comando predeterminado de la CLI del subagente Un proceso hijo se ejecuta sin verificaciones de permisos.
Agentic OS Obsidian Configuraciones persistentes de dashboard/terminal Disparadores desatendidos se activan sin confirmación por ejecución.
Agy CLI Patrón recomendado para ejecuciones delegadas Normaliza la desactivación de una característica de seguridad central para uso rutinario.

En el caso de OMA Image, el comando canónico para su subagente incluye el flag por defecto. Para Agentic OS Obsidian, el flag está incorporado en configuraciones persistentes para botones de dashboard y perfiles de terminal, lo que significa que las acciones pueden activarse sin más avisos de seguridad. Agy CLI lo recomienda como un patrón estándar para ejecuciones delegadas. Aunque la documentación del skill señala el riesgo, su patrón de uso común desactiva eficazmente un mecanismo de seguridad crítico. Nuevamente, estas son herramientas útiles, pero sus configuraciones predeterminadas intercambian seguridad por conveniencia de una manera que merece precaución.

Riesgos secundarios: manejo de datos y abstracciones con fugas

Más allá de las concesiones explícitas de permisos, también observamos malas prácticas de seguridad que aumentan la superficie de ataque de un sistema o filtran información sensible, incluso si no constituyen malware activo.

Un ejemplo es AI Search Hub. Su script contenedor funciona copiando todo el directorio de datos de usuario del navegador del usuario —incluyendo cookies y sesiones activas— a una carpeta de perfil local ignorada por git (chrome_debug_profile_skill). También expone el Chrome DevTools Protocol en el puerto 9222 en la máquina local. Esto no es exfiltración; los datos no salen de la máquina local. Sin embargo, crea una copia local de datos de sesión sensibles y abre un potente puerto de depuración, expandiendo el radio de impacto para cualquier otro proceso local que pudiera estar comprometido.

Otro ejemplo es Google Ad Scraper. Este skill pasa su token de API como un parámetro de consulta en la URL (?token=...) en lugar de en un encabezado Authorization. Las cadenas de consulta son el peor lugar para poner un secreto: terminan en el historial del shell, en los registros de acceso del servidor y en cualquier proxy en la ruta. El mismo skill también envía ese token a un endpoint de terceros, api.gooseworks.ai, cuando se establece una clave correspondiente. Estos no son actos maliciosos, pero son un fallo en seguir la práctica estándar y crean una exposición que no solicitaste. Para más información sobre este tema, consulta nuestro resumen sobre la seguridad de los skills de Claude.

El lado constructivo: skills que mejoran la seguridad

El ecosistema de skills no es solo una fuente de riesgo potencial; también es una fuente de herramientas potentes para mitigarlo. El mismo framework que permite a un skill interactuar con tu sistema de archivos también permite a un skill auditarlo en busca de vulnerabilidades. Hemos probado varios skills diseñados específicamente para revisiones de seguridad.

Skill Security Auditor es un caso destacado. Lo probamos contra un archivo de 13 líneas que contenía inyección SQL flagrante, inyección de comandos y una clave de API hardcodeada. Sus scripts de análisis identificaron con éxito las tres vulnerabilidades. Como extra, también marcó la falta de un archivo .gitignore, un problema que un revisor humano había pasado por alto.

De manera similar, ejecutamos Code Health Check contra la API de Express deliberadamente defectuosa que el skill incluye en su propio repositorio. Encontró los ocho problemas plantados, que incluían inyección SQL, un analizador de configuración basado en eval(), dos secretos hardcodeados, un error suprimido y una función muerta. Proporcionó niveles de severidad correctos y citas precisas de archivo y número de línea para cada uno.

Estas herramientas demuestran la otra cara de las capacidades de los skills. Al otorgar a un skill de auditoría de confianza acceso controlado a tu código, puedes automatizar partes de tu proceso de revisión de seguridad. Puedes encontrar más herramientas como estas en nuestra guía de skills de Claude para revisión de seguridad.

Cómo protegerse: un modelo de amenaza práctico

Dado que la amenaza principal es el exceso de permisos en lugar del malware, la estrategia defensiva cambia. Se trata menos de antivirus y más de disciplina operativa.

  1. Asume buena intención, verifica el alcance: El desarrollador del skill que estás instalando probablemente no está tratando de hackearte. Pero puede haber sido descuidado o haber priorizado la conveniencia sobre la seguridad. Cuando un skill pida permisos, lee el aviso. Si pide acceso de escritura a todo tu directorio personal para añadir una línea a un único archivo de configuración, deniégalo.

  2. Prefiere skills con un radio de impacto pequeño: Busca skills que sean autocontenidos y sigan el principio de mínimo privilegio. Un gran ejemplo de esto es Workthreads. Es un skill autocontenido con cero dependencias. Solo llama a git a través de execFileSync con argumentos de array fijos para prevenir la inyección de comandos, y viene con redacción de secretos determinista e integrada para AWS, GitHub, Slack, OpenAI, Anthropic, JWTs, y tokens 'bearer' antes de imprimir cualquier salida. Claramente fue construido con un radio de impacto pequeño y controlado en mente.

  3. Ejecuta en un sandbox: No ejecutes un skill nuevo y desconocido en tu código base de producción principal o desde tu directorio personal. Crea un directorio dedicado y desechable para las pruebas. Usa Docker u otras tecnologías de contenedorización para una barrera aún más fuerte.

  4. Confía en la ejecución, no solo en el código: La única manera de estar seguro de lo que hace un skill es ejecutarlo y observar su comportamiento. Este es el principio fundamental de la metodología de SkillProof. Publicamos nuestras notas de prueba, incluyendo advertencias de seguridad como las cinco de este artículo, para cada skill que ejecutamos.

Lectura relacionada: la continuación práctica de este artículo es cómo la declaración de herramientas permitidas de un skill realmente limita lo que puede tocar, que es el mecanismo al que se reducen la mayoría de los problemas anteriores. Para ver cómo el ecosistema de directorios más amplio se describe a sí mismo frente a lo que verifica, consulta nuestro análisis de la realidad de los directorios.

Cada advertencia de seguridad citada aquí es pública en la propia página de catálogo del skill, junto con su veredicto y puntuación, para que puedas leer la evidencia antes de instalar nada. Si prefieres empezar con un conjunto que ya ha pasado por esto, nuestro Paquete de Seguridad y Revisión de Código recopila diez skills probados para revisión de código, depuración y pruebas de contrato.

★ 9.6/10 × 3

El pack de inicio gratis

Los 3 skills con nuestras mejores puntuaciones de test más la checklist de instalación: el setup que pondríamos en una máquina recién estrenada. Gratis, por email.

Un email con el pack + un breve resumen semanal con nuevos resultados de test. Date de baja cuando quieras.