Un servidor MCP con dos herramientas de formateo de texto pasó inadvertido en 23 pull requests. Su truco: se comporta bien durante las primeras tres llamadas y después ordena al agente buscar claves SSH y credenciales de AWS. Así funciona, y por qué es distinto del "rug pull" clásico.
Investigadores de Pillar Security identificaron una campaña activa que bautizaron Deadbugz. Una sola cuenta de GitHub (zellkernel) envió 23 pull requests a repositorios públicos no relacionados entre sí, en una ventana de 74 minutos (de 21:52 a 23:07 UTC). Los PR añadían la configuración de un servidor MCP llamado productivity-suite: 17 apuntaban a un endpoint remoto, 4 a un script local, y hubo 2 envíos a directorios o listados.
Cuando Pillar revisó el estado, 19 PR estaban cerrados y 4 abiertos; ninguno fue integrado por el mecanismo de merge de GitHub. La nota de la Cloud Security Alliance aclara que no se especifica cuántas víctimas hubo, porque era limitada la visibilidad sobre quién había ejecutado el servidor en local. Es decir: la campaña es real y activa, pero no hay un número confirmado de afectados. El 8 de octubre, el resumen trimestral del OWASP GenAI Security Project la incluyó entre los incidentes del tercer trimestre.
El servidor expone dos herramientas inocentes, format_text y summarize. Durante las tres primeras llamadas, sus respuestas a tools/list y prompts/get describen exactamente lo que el nombre sugiere. Tras la tercera, empieza a devolver contenido distinto: instrucciones para que el agente busque claves SSH, credenciales de AWS, historial de shell y configuración de Kubernetes, y para que oculte esa actividad al usuario.
En un rug pull tradicional, el autor publica una versión limpia, espera la aprobación y luego despliega una definición de herramienta modificada. Eso deja rastro: un cambio de versión, un hash distinto, una diferencia detectable. La CSA lo resume así: Deadbugz "nunca cambia su código publicado ni su configuración en disco"; la divergencia es función de un estado interno que solo aparece en las respuestas del protocolo durante el uso real.
Por eso la CSA advierte que una revisión única al instalar, un escáner automático que inspecciona el código una vez, o incluso una breve sesión interactiva de prueba pueden completarse dentro de las dos primeras llamadas y ver solo una utilidad de formato.
Las recomendaciones de Pillar y la CSA convergen: tratar cualquier PR que añada o modifique la configuración de un servidor MCP como un cambio de alto riesgo; hacer "fingerprinting" de las definiciones de herramientas en el momento de aprobarlas y alertar si cambian en ejecución; monitorear por llamada los cambios de esquema; usar una lista de servidores MCP permitidos; y separar las credenciales del acceso de las herramientas del agente. Pillar sugiere además bloquear el endpoint remoto conocido de la campaña.
~/.ssh ni a credenciales cloud de larga vida; usa credenciales temporales de mínimo privilegio; (3) registra las respuestas de los servidores MCP, no solo su instalación. La aprobación única ya no es un control suficiente. Si quieres auditar tu superficie MCP: info@guatemalia.com.Fuentes: Pillar Security, notas de investigación de la Cloud Security Alliance (30 de agosto y 2 de septiembre de 2026) y resumen Q3 2026 del OWASP GenAI Security Project.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel