Prompt injection a través de skills de Claude Code: cómo revisar un plugin antes de instalarlo

En julio de 2026, un desarrollador publicó en Habr una guía práctica sobre la seguridad de los skills de código abierto para herramientas de IA. Explica por qué un skill malicioso es más peligroso que el prompt injection convencional: se ejecuta con los permisos del usuario y sin ningún tipo de aislamiento.

¿Por qué un skill es más que un simple prompt?

Una idea muy extendida y errónea: un skill para Claude Code o una herramienta de IA similar sería un archivo de configuración de texto, seguro por definición. Abres SKILL.md, lees las instrucciones y das por hecho que todo está bajo control.

En la práctica, la frontera entre «configuración» y «código ejecutable» está difuminada desde hace tiempo. Los skills actuales incluyen:

• Scripts de Python o Bash ejecutados mediante `tool_call`
• Instrucciones para trabajar con el sistema de archivos local y las variables de entorno
• Llamadas a API externas y endpoints de webhook
• Pipelines de agentes de varios pasos con permisos de acceso ampliados

Todo esto se ejecuta con los permisos del usuario actual, sin aislamiento de sandbox por defecto. Un skill malicioso accede a archivos, tokens de API, claves SSH e historial de chats: nada abstracto, sino lo que hay en tu disco ahora mismo.

Eso hace que el vector de ataque a través de un skill sea radicalmente distinto, por ejemplo, de una vulnerabilidad del navegador: el skill no esquiva la protección, usa los permisos que se le han concedido. Para el sistema, son acciones totalmente legítimas.

Cómo usa un atacante un skill como vector de ataque

En el prompt injection clásico, las instrucciones maliciosas se esconden en los datos que procesa el modelo: el texto de una página web, un documento o un correo. El agente «lee» el contenido y ejecuta los comandos ocultos. Con skills que incluyen código ejecutable, el ataque funciona de otra manera y es más difícil de detectar.

Cadena de ataque típica a través de un skill de código abierto:

• El atacante publica un skill con una función realmente útil: un editor, un conversor, un buscador
• Los primeros commits están limpios, y el skill suma estrellas y usuarios
• Tras varias actualizaciones se añade lógica maliciosa que recopila archivos `.env`, tokens de API e historial de chats
• El usuario actualiza el skill sin revisar el diff y los datos salen hacia un servidor externo

«Un skill no es una configuración ni solo un prompt en SKILL.md.

Literalmente puede ser código ejecutable con tus permisos»

A diferencia de una vulnerabilidad en un paquete de npm, que detecta `npm audit`, un skill malicioso no deja ningún registro CVE: nadie los escanea de forma automática.

Qué revisar antes de instalar un skill

Lista mínima antes de añadir un skill ajeno:

• Lee todo el código, no solo SKILL.md: los archivos de Python, Bash y PowerShell del directorio del skill requieren revisión manual
• Busca peticiones externas: `curl`, `fetch` o `requests.get` hacia URL desconocidas sin una necesidad clara son señal de alarma
• Comprueba el acceso a rutas sensibles: `~/.ssh/`, `~/.env` y `.credentials` son inadmisibles sin permiso explícito del usuario
• Estudia el historial de commits: el código malicioso suele aparecer varias semanas después de una versión limpia
• Busca ofuscación: cadenas en base64, `eval()` dinámico, nombres de variables extraños
• Audita las dependencias: la lógica maliciosa puede estar en una biblioteca auxiliar y no en el propio SKILL.md

Conviene probar los skills desconocidos en un entorno aislado: un perfil aparte sin claves de API reales y sin acceso a archivos de trabajo. Lo ideal es una cuenta de pruebas dedicada, sin tokens de producción.

Qué significa

El ecosistema de skills de código abierto para asistentes de IA repite el camino que siguió npm hace diez años: crecimiento rápido, verificación centralizada débil y costumbre de instalar sin auditar. La diferencia es de fondo: un skill no se ejecuta en un entorno Node aislado, sino directamente en el entorno de trabajo del usuario y con sus permisos. Auditar los skills antes de instalarlos no es paranoia, sino la misma higiene de seguridad que ejecutar `npm audit` antes de desplegar.