Escáneres de skills evadidos: los límites del análisis estático
Trail of Bits coló cuatro skills maliciosas ante ClawHub, el escáner de Cisco y skills.sh en menos de una hora cada una. La lección: un escáner estático no puede ser la frontera de confianza.
¿Qué es esto?
El 3 de junio de 2026, los investigadores de Trail of Bits Samuel Judson y Tjaden Hess publicaron un estudio que muestra cómo evadieron todos los principales escáneres de skills que probaron: el detector ClawHub de OpenClaw (respaldado por VirusTotal y un modelo guardián GPT-5.5), el skill-scanner de código abierto de Cisco, y los tres escáneres integrados en skills.sh de Vercel (Gen, Socket y Snyk).
Una skill de agente es un paquete que reúne instrucciones en lenguaje natural (un prompt SKILL.md), código y recursos, que un agente como Claude Code, Codex u OpenClaw carga para ampliar su comportamiento. A medida que los mercados públicos se llenaban de skills que roban credenciales y secuestran agentes, surgió una nueva categoría de productos para verificar una skill antes de instalarla. La conclusión es tajante: estos escáneres no funcionan. Tres de las cuatro skills maliciosas de demostración se construyeron en menos de una hora, y todas son públicas en trailofbits/overtly-malicious-skills.
Cómo funciona
El estudio documenta cuatro evasiones estructurales, cada una explotando un punto ciego distinto en lugar de un simple fallo de producto.
Truncamiento por relleno. Anteponer unos 100 000 saltos de línea entre texto inofensivo y el contenido malicioso empuja la carga útil más allá del punto donde el modelo guardián de ClawHub trunca su entrada. El archivo se declara «limpio» porque el escáner nunca lee la parte peligrosa; el modelo de VirusTotal queda igualmente confundido, y en la interfaz web el largo desplazamiento pasa fácilmente inadvertido.
Indirección por empaquetado. Un SKILL.md indica al agente que extraiga sus instrucciones «reales» de un .docx incluido — que no es más que un ZIP de XML que transporta un script oculto. Los motores de coincidencia de patrones ven una utilidad de formato, no la carga útil que viaja con el archivo.
Discrepancia fuente/artefacto. Un archivo fuente Python inofensivo convive con un .pyc precompilado cuyo bytecode contiene comportamiento adicional — lectura de variables de entorno para su posterior exfiltración. Los escáneres que solo leen la fuente, o que tratan los binarios como opacos, nunca lo ven. Es el patrón clásico de xz-utils: el artefacto entregado difiere de la fuente revisada.
Distracción por inyección de prompt. Una skill que reconfigura npm y yarn hacia un registro controlado por el atacante, vestida con el lenguaje de un «espejo corporativo» tras una VPN y una «allowlist auditada por AppSec», convenció a los analizadores LLM de que el cambio era rutinario. Con Claude Sonnet 4.6, la herramienta de Cisco marcó el registro alternativo solo como LOW y aun así declaró segura la skill.
La debilidad común: un escáner estático es un blanco fijo. El atacante juega en segundo lugar, ajustando su ataque en un bucle cerrado hasta que algo pasa. Trail of Bits subraya el problema inverso con un ejemplo honesto — las skills Office oficiales de Anthropic usan legítimamente LD_PRELOAD para inyectar una biblioteca compilada que sortea un bloqueo de socket en el entorno aislado, un comportamiento que un escáner no puede distinguir de un ataque.
Por qué importa
Las skills son una nueva dependencia de cadena de suministro, junto a los gestores de paquetes, pero con una superficie de ataque más amplia: mezclan código, binarios, recursos e instrucciones en lenguaje natural capaces de ejecutar o exfiltrar. Una sola instalación con un clic desde un mercado público puede entregar al atacante tanto el agente como su máquina anfitriona. Como la inferencia es cara, los escáneres se apoyan en modelos más débiles y contexto truncado — precisamente las costuras que explotan estas evasiones. Y como una instrucción puede ser benigna en un entorno y maliciosa en otro, ningún veredicto estático puede ser fiable. Una marca verde fabrica una falsa confianza posiblemente peor que la ausencia de control.
Defensas
No delegue la confianza en un escáner. Trate los repositorios públicos de skills como código no confiable, sobre todo para agentes que operan en contextos sensibles. Un análisis «aprobado» no garantiza nada.
Cure y fije. Prefiera colecciones verificadas y curadas (por ejemplo anthropics/skills o trailofbits/skills-curated), fije a commits concretos y controle quién puede introducir o actualizar una skill — la disciplina que aplica a cualquier dependencia.
Restrinja el formato del paquete. Prohíba artefactos no analizables: sin binarios, sin bytecode precompilado, una allowlist explícita de tipos de archivo y validación contra la especificación de skills. La PR de Trail of Bits para el escáner de Cisco añade un modo de validación estricta del formato que rechaza exactamente el vector de bytecode anterior.
Haga cumplir en tiempo de ejecución, no solo en la entrada. El análisis estático no ve el comportamiento. Combínelo con mínimo privilegio, control del tráfico de salida y aislamiento (sandboxing) para que el radio de impacto de una skill maliciosa siga siendo pequeño aunque se cuele.
Mantenga la superficie pequeña y con revisión humana. Menos skills, de fuentes conocidas, revisadas por personas en lugar de por el veredicto de un escáner: es el modelo duradero mientras el ecosistema madura.
Estado
| Elemento | Detalle |
|---|---|
| Escáneres evadidos | ClawHub (OpenClaw + VirusTotal), skill-scanner de Cisco, skills.sh (Gen, Socket, Snyk) |
| Técnicas | Truncamiento por saltos de línea, indirección .docx, discrepancia de bytecode .pyc, distracción por inyección de prompt |
| Esfuerzo | 3 de 4 skills construidas en menos de una hora |
| Divulgación | Trail of Bits (S. Judson, T. Hess), 3 de junio de 2026 |
| Endurecimiento | PR #25 de ToB: validación estricta del formato en el escáner de Cisco |
| CVE | Ninguno — hallazgo de diseño estructural |