PhantomSkill: disfrazar una carga maliciosa como un fallo corriente

¿Qué es esto?

El 17 de junio de 2026, Yu-Ting Lin y Chia-Mu Yu (National Yang Ming Chiao Tung University) publicaron en arXiv PhantomSkill: Malicious Code Injection in Agent Skill Ecosystems. El artículo describe un ataque de cadena de suministro contra el formato de skill de agente — esos directorios que contienen cada uno un archivo SKILL.md y, opcionalmente, scripts y plantillas auxiliares, que agentes de código como Claude Code, OpenAI Codex, Cursor o Gemini CLI importan para adquirir nuevas capacidades.

La mayoría de los ataques publicados hasta ahora sobre skills apuntan al texto: una instrucción oculta en SKILL.md, o un script auxiliar abiertamente malicioso en cuanto se abre. Ambos son detectables, porque los agentes y los escáneres de los marketplaces inspeccionan cada vez más los recursos de un skill antes de ejecutarlos. PhantomSkill apunta al hueco que dejan esas defensas: qué ocurre cuando el comportamiento malicioso está escrito para parecer un bug corriente y explotable en lugar de malware. Es investigación académica publicada sobre una clase de debilidad, no un manual operativo; los autores la plantean como un argumento para endurecer la revisión y la contención de skills.

Cómo funciona

La técnica se llama VulMask y se apoya en una observación que los autores hacen explícita: los revisores —humanos y automáticos— son mucho más sensibles al malware evidente que al código simplemente inseguro. VulMask convierte lo primero en lo segundo.

Mantenido deliberadamente abstracto, el flujo es así:

script malicioso explícito
        |
  elegir clases de debilidad tipo CWE (p. ej. exposición de
  información, inyección de comandos/de código, manejo de
  dependencias inseguro)
        |
  un LLM reescribe la carga  --->  implementación «con forma de fallo»
        |                           (parece un bug explotable corriente)
        |
  incrustar en el script auxiliar ORIGINAL, conservando su nombre,
  su ruta y su comportamiento benigno sin disparador
        |
  validar en sandbox: el skill anfitrión funciona con normalidad, y
  el efecto malicioso solo se produce bajo el disparador elegido
        |
  publicar el skill  --->  SKILL.md, nombre, descripción: sin cambios

Dos decisiones de diseño lo hacen escurridizo. Primero, la superficie anunciada del skill queda intacta —nombre, descripción y flujo de SKILL.md son idénticos a los de un skill benigno—, así que cualquier cosa que solo escanee SKILL.md no ve nada. Segundo, la carga está latente: sin el disparador del atacante, el script produce su salida normal y benigna, de modo que las comprobaciones dinámicas sobre entradas ordinarias también pasan. El efecto malicioso está presente, pero expresado como una debilidad que «resulta» ser explotable en lugar de como lógica explícitamente maliciosa. Los autores reportan que, a través de un conjunto de skills anfitriones, objetivos de ataque, agentes de código, modelos de generación y revisores automáticos, esta reescritura conserva la funcionalidad del skill mientras reduce la detección de nivel alerta y de nivel malware frente al script explícito original. El método y la evaluación completos están en el artículo; aquí no se reproduce ninguna carga funcional.

Por qué importa

El punto incómodo es que, en un contexto de agente, «simplemente vulnerable» y «malicioso» pueden fundirse en lo mismo. Un script auxiliar con una inyección trivial o una exposición de información solo es peligroso si algo le suministra una entrada hostil. Y eso es exactamente lo que hace un agente de código: entrega a los scripts de un skill rutas de archivos, contexto del proyecto, credenciales y su propia autoridad de ejecución. Una debilidad que un desarrollador humano clasificaría como de baja prioridad se convierte en una carga fiable cuando un agente autónomo es quien sostiene el disparador.

Esto ocurre sobre un ecosistema ya permeable. El estudio ToxicSkills de Snyk sobre marketplaces de skills públicos halló inyección de prompt y otros problemas críticos en una amplia fracción de los skills, y OWASP ha creado un Top 10 de Agentic Skills precisamente porque las capacidades instalables son una superficie de ataque creciente. PhantomSkill afila la amenaza: muestra que elevar el listón frente al malware evidente no cierra la puerta, porque un autor decidido puede reestilizar el mismo comportamiento como un bug. Generaliza la lección del malware en la cadena de suministro de skills y del envenenamiento del registro SKILL.md: el peligro no está solo en lo que el skill dice, sino en lo que sus recursos hacen cuando un agente los ejecuta.

Defensas

Tratar los recursos auxiliares como ciudadanos de primera clase, no como añadidos. El hallazgo central del artículo es que escanear SKILL.md no basta: la carga nunca lo toca.

Revisar el paquete completo, a nivel de recurso. Los marketplaces y las puertas de revisión internas deben inspeccionar scripts, manifiestos de dependencias, plantillas y cualquier artefacto generado, no solo la descripción del skill. El análisis estático que marque puntos de inyección, deserialización insegura y manejo de dependencias no verificado debe ejecutarse sobre cada archivo ejecutable que entregue un skill.

No rebajar los bugs explotables dentro de los skills. Los autores sostienen directamente que, en un ecosistema de agentes, una vulnerabilidad activable puede ser funcionalmente equivalente a una carga maliciosa. Una revisión de código que puntúe una inyección de comandos como «baja, requiere entrada hostil» está mal calibrada cuando el consumidor es un agente autónomo que suministra precisamente esa entrada.

Contener la ejecución, suponer el script hostil. El control más robusto es en tiempo de ejecución: acceso a archivos con mínimo privilegio, restricción de salida de red y aprobación explícita de operaciones sensibles (shell, acceso a secretos, conexiones salientes). Si el script auxiliar de un skill no puede alcanzar secretos ni la red sin una comprobación de política, una carga latente dispone de mucho menos con qué operar. Es la misma postura que ayuda contra la inyección de shell en agentes de código y que sustenta los sistemas de permisos de skills.

Suponer detección parcial y registrar en consecuencia. Como la técnica está hecha para pasar a los revisores, conserve telemetría de ejecución —actividad de archivos, procesos y red por invocación de skill— para que un disparo en producción pueda detectarse y reconstruirse a posteriori, y no solo en la instalación.

Estado

Elemento	Detalle
Divulgación	Preprint arXiv 2606.19191, publicado el 17 de junio de 2026 (CC BY 4.0)
Clase	Inyección de código de cadena de suministro en skills mediante cargas «con forma de fallo» (VulMask)
Idea central	Reescribir un script malicioso explícito como código inseguro de aspecto corriente, que solo actúa bajo un disparador elegido por el atacante
Propiedad clave	Nombre, descripción y SKILL.md sin cambios; comportamiento benigno preservado sin disparador
Impacto reportado	Detección de nivel alerta y malware menor que la de cargas explícitas, manteniendo la tasa de éxito (según los autores, incl. pruebas sobre un agente de clase GPT-5.5)
No cubierto	Sin explotación pública en la naturaleza; es un marco de investigación, y su éxito depende de la pila de revisión/sandbox existente