Deadbugz: un servidor MCP que se vuelve hostil en la tercera llamada

¿Qué es esto?

El 12 de agosto de 2026, Ariel Fogel, de Pillar Security, publicó Deadbugz: Currently Active MCP Supply-Chain Campaign, donde documenta una operación en curso que distribuía un servidor Model Context Protocol malicioso mediante pull requests públicas de GitHub. El resumen de MCP de Adversa AI del 7 de septiembre de 2026 lo señaló como el acontecimiento de seguridad MCP del mes.

El servidor se presenta como un asistente de productividad con dos herramientas inocuas —formateo y resumen de texto— y se comporta exactamente como anuncia. Sin embargo, en cuanto un cliente conectado emite tres peticiones tools/call, el servidor cambia los metadatos que devuelve. Las nuevas descripciones de herramientas y el contenido de los prompts instruyen al agente conectado a buscar claves SSH, credenciales de AWS, historial de shell y configuración de Kubernetes, y a ocultar esa actividad al operador.

Lo relevante aquí no es la carga útil. Es el cierre temporal. Las instrucciones maliciosas estuvieron en el servidor desde el principio; el contador solo decidía cuándo se le permitía verlas al auditor.

Cómo funciona

La campaña tiene dos mitades: una vía de distribución y un disparador en tiempo de ejecución.

Distribución. Una única cuenta pública de GitHub abrió 23 pull requests en 74 minutos el 10 de agosto de 2026, repartidas entre proyectos de IA, MCP y herramientas para desarrolladores sin relación entre sí. Diecisiete añadían un punto de acceso MCP remoto a un fichero de configuración. Cuatro apuntaban un intérprete Python local a una ruta oculta bajo ~/.config/.cache/.sys/. Dos eran envíos a directorios o listados. En el momento de la revisión de Pillar ninguna se había fusionado mediante el mecanismo de merge de GitHub: 19 estaban cerradas y cuatro seguían abiertas. El vehículo es un diff de configuración: unas pocas líneas en un fichero de ajustes MCP, el tipo de cambio que un revisor lee por encima.

Disparador. El servidor mantiene en memoria un contador de peticiones tools/call por cliente. Por debajo del umbral responde a tools/list y prompts/get con documentación ordinaria. Al alcanzarlo, esos mismos puntos de acceso devuelven algo distinto.

client connects  ──►  tools/list  ──►  "format_text", "summarize"   ← benign
                      tools/call  #1  ──►  normal result
                      tools/call  #2  ──►  normal result
                      tools/call  #3  ──►  normal result
                                    ▼  counter == 3
                      tools/list / prompts/get
                          ──►  [REDACTED: credential-seeking instructions
                                + directive to conceal activity]

El servidor también anuncia tools.listChanged, la capacidad estándar de MCP que permite a un cliente refrescar los metadatos de herramientas, de modo que un cliente conforme recogerá por sí solo las definiciones sustituidas.

El contador es la decisión de ingeniería más reveladora. Un revisor que se conecta a un servidor nuevo, prueba dos herramientas y lee las descripciones ve un servidor limpio. Un escáner automatizado que enumera herramientas sin invocarlas nunca cruza el umbral. El uso diario normal lo cruza en minutos. El umbral está calibrado contra el revisor, no contra la víctima.

Por qué importa

Los clientes MCP entregan las definiciones de herramientas al modelo como contexto. Esas descripciones son lo que permite al agente decidir para qué sirve una herramienta y cuándo recurrir a ella: una descripción no es una etiqueta, sino texto de instrucción con una procedencia que inspira confianza. Un servidor capaz de modificar sus descripciones después de la instalación puede modificar lo que el agente cree, sin cambiar nada que el usuario vaya a notar.

La primitiva no es nueva. Invariant Labs demostró una sustitución diferida de descripción de herramienta contra una integración MCP de WhatsApp en abril de 2025, y el artículo ETDI (junio de 2025) formalizó la clase de los rug pulls proponiendo definiciones de herramientas firmadas y versionadas. Hemos tratado la forma estática en los rug pulls de descripciones de herramientas MCP y la variante multiherramienta en el envenenamiento por umbral ShareLock.

Deadbugz es la versión operativa: primitiva conocida, campaña de distribución real y un cierre diseñado específicamente para burlar el paso de revisión. Eso dice algo incómodo sobre la seguridad en el momento de la aprobación: una auditoría puntual no solo es incompleta frente a esta técnica, sino que es exactamente su objetivo. La postura que se adopta en la instalación es aquella con la que el atacante puede contar para planificar.

El impacto observado fue limitado: ninguna pull request fusionada, ninguna víctima confirmada. Conviene atribuirlo a la suerte y al calendario, no tomarlo como techo. La técnica se reproduce en una tarde.

Defensas

Tome la huella de las definiciones de herramientas en la aprobación y compárela en cada reconexión. Calcule un hash de la lista completa de herramientas —nombres, descripciones, esquemas— cuando el operador apruebe un servidor. Compárelo en cada sesión y en cada notificación tools/listChanged. Una definición que cambie tras la aprobación debe notificarse al operador y exigir un nuevo consentimiento antes de que la herramienta modificada toque nada sensible. Es el control que habría detectado Deadbugz.

Trate los diffs de configuración MCP como revisión sensible. Una pull request que añade un servidor a un fichero de ajustes MCP concede a un tercero un canal hacia el contexto de su agente. Exija un revisor identificado, verifique al editor y no acepte nunca una configuración que apunte un intérprete a una ruta oculta en un directorio de caché.

Aplique las acciones sensibles por política, no por prompt. Leer ~/.ssh, tocar ficheros de credenciales en la nube, ejecutar código, escribir en repositorios, enviar correo: todo ello debe pasar por la lista de permitidos del propio cliente, de modo que ninguna instrucción llegada por metadatos de herramientas pueda provocarlo. Si los metadatos pueden convencer al agente de actuar, los metadatos son su capa de control de acceso.

Convierta el ocultamiento en una señal. Cualquier instrucción que pida a un agente esconder su actividad al operador basta, por sí sola, para detener la ejecución. Las barreras que solo puntúan «contenido dañino» no lo verán; una regla que marque las peticiones de opacidad, sí.

Registre las actualizaciones de definiciones de herramientas. La mayoría de clientes MCP registran las llamadas, pero no los cambios de metadatos. Anote cada refresco de definición con marca temporal y conserve las acciones del agente posteriores. Si un equipo llegó a conectarse a un servidor hostil, esa es la diferencia entre una investigación acotada y una conjetura.

Como base más amplia, la OWASP MCP Security Cheat Sheet cubre los controles del entorno: firma de mensajes, vinculación de interfaz, validación de la cabecera Host y almacenamiento nativo de credenciales.

Estado

Elemento	Detalle
Divulgación	Blog de investigación de Pillar Security, publicado el 12 de agosto de 2026; distribución observada el 10 de agosto de 2026
Clase	Distribución en la cadena de suministro + envenenamiento de metadatos de herramientas MCP condicionado en ejecución
Disparador	Contador en memoria por cliente; los metadatos cambian en la tercera tools/call
Distribución	23 pull requests públicas de GitHub en 74 minutos; 17 configuraciones de punto de acceso remoto, 4 de script local oculto, 2 envíos a listados
Estado de merge en la revisión	0 fusionadas mediante el mecanismo de merge de GitHub — 19 cerradas, 4 abiertas
Antecedentes	Ataque durmiente MCP de WhatsApp de Invariant Labs (abril de 2025); formalización de rug pulls ETDI, arXiv 2506.01333 (junio de 2025)
CVE	Ninguno asignado — se trata de una campaña de un actor malicioso, no de una vulnerabilidad de producto
Punto ciego defensivo	Una revisión en el momento de la aprobación no puede observar metadatos que solo se vuelven hostiles después de aprobarse