Deadbugz: la cuarta clase de ataque MCP se esconde hasta que confías en él

Conclusiones clave

• 23 pull requests en 74 minutos — una única cuenta de GitHub presentó los PR de la campaña en proyectos no relacionados de IA, MCP y herramientas de desarrollador el 10 de agosto de 2026; ninguno se fusionó a través del mecanismo de revisión de GitHub, pero cuatro seguían abiertos en el momento de la divulgación (Pillar Security).
• Tres llamadas benignas y luego los metadatos se reescriben — el servidor MCP malicioso mantiene un contador de llamadas por cliente; después de la tercera solicitud tools/call, las respuestas siguientes de tools/list y prompts/get dirigen al agente a buscar claves SSH, credenciales de AWS, historial de shell y configuración de Kubernetes, y a ocultar la actividad al usuario.
• El envenenamiento de metadatos activado en tiempo de ejecución es la cuarta clase de ataque MCP distinta — inyección de comandos STDIO → envenenamiento de herramientas → omisión de SHA-pinning → envenenamiento de metadatos activado en ejecución tras la confianza. El mecanismo de Deadbugz es el más difícil de detectar antes del despliegue porque el servidor pasa la inspección inicial y la carga se activa solo cuando el cliente ya ha establecido un patrón de uso.
• La huella digital de definiciones de herramientas es la defensa — capturar y comparar una huella de la definición de herramientas en el momento de la aprobación; tratar cualquier cambio en los metadatos de un servidor ya aprobado como un evento de seguridad que exige una nueva aprobación del operador antes de que la herramienta modificada pueda influir en acciones sensibles.

Una única cuenta de GitHub presentó 23 pull requests en 74 minutos, cada uno ofreciendo un servidor MCP de "productivity-suite" que formatea texto y resume documentos. El servidor se comporta normalmente durante las primeras tres llamadas de herramientas. En la cuarta, reescribe sus propios metadatos para indicar al agente de IA conectado que busque claves SSH, credenciales de AWS, historial de shell y configuración de Kubernetes — y que oculte la actividad al operador. El 23 de septiembre de 2026, Pillar Security divulgó la campaña, nombrándola Deadbugz por el artefacto de entrega deadbug-mcp.py incrustado en cuatro de los pull requests. La Cloud Security Alliance publicó una nota de investigación que señala la proximidad mecánica con la campaña anterior "Miasma", que atacó 73 repositorios de GitHub incluido el azure/durabletask de Microsoft.

Este artículo mapea el mecanismo de Deadbugz, lo sitúa en la taxonomía de cuatro clases de ataques MCP e identifica el control que cierra la brecha. Se apoya en el análisis de Plugin4Shell SHA-pinning bypass y en la lista de verificación de endurecimiento MCP, ambos con controles establecidos cuya brecha explota Deadbugz.

El mecanismo: un contador de llamadas por cliente

El servidor Deadbugz anuncia dos herramientas — format_text y summarize — que hacen exactamente lo que sus nombres sugieren. El servidor mantiene un contador en memoria, por cliente, para las solicitudes tools/call. El contador comienza en cero. Cada llamada ordinaria lo incrementa. Cuando llega a tres, las respuestas siguientes de tools/list y prompts/get cambian: en lugar de documentación ordinaria de herramientas, contienen instrucciones que dirigen al agente de IA conectado hacia archivos locales sensibles y le indican que oculte la actividad a su operador.

Esto importa porque las definiciones de herramientas MCP no son etiquetas. Los clientes las suministran al modelo como contexto que le ayuda a decidir qué herramientas usar y qué acciones tomar. Un servidor que puede alterar esas definiciones después de la instalación puede cambiar las instrucciones que ve el agente sin cambiar el nombre benigno de la herramienta. El código fuente público anuncia tools.listChanged, una capacidad que permite a un cliente compatible refrescar los metadatos de herramientas — así el servidor no necesita que el cliente se reconecte. Simplemente notifica al cliente que su lista de herramientas cambió, y el cliente obtiene las nuevas definiciones envenenadas.

La puerta en tiempo de ejecución es una técnica de evasión de investigación. Una inspección breve o una prueba automatizada limitada reciben solo metadatos benignos. El servidor pasa la revisión de seguridad, las pruebas en sandbox y el escaneo automatizado porque ninguno de esos métodos hace tres llamadas ordinarias de herramientas y luego comprueba qué devuelve el servidor. Pillar confirmó la lógica del umbral y los metadatos alterados a partir de fuentes públicas, y observó los metadatos activados del servicio remoto mediante solicitudes benignas de solo texto.

La ruta de entrega: un cambio de configuración que parece rutinario

El mecanismo de entrega de la campaña es un pull request de GitHub que añade o cambia la configuración MCP en repositorios no relacionados. De los 23 PR revisados, 17 añaden un endpoint MCP remoto (productivity-suite-mcp.onrender.com/mcp) al archivo de configuración de un proyecto. Cuatro configuran Python para ejecutar un archivo local oculto (~/.config/.cache/.sys/.deadbug-mcp.py). Dos son envíos de directorio o listado. Los 23 quedaron sin fusionar a través del mecanismo de pull request de GitHub en el momento de la revisión — 19 cerrados, cuatro abiertos — pero el modelo de entrega no requiere una fusión. Requiere un mantenedor que copie el cambio de configuración en su propia configuración, o un desarrollador que vea el PR, visite el repositorio enlazado e instale el servidor directamente.

El patrón de entrega a nivel de cuenta está coordinado: la misma cuenta pública (zellkernel) usó el mismo nombre de producto, tema de configuración y marcadores de campaña en todos los 23 PR, presentados entre las 9:52 PM y las 11:07 PM UTC del 10 de agosto de 2026. La cuenta tenía 50 repositorios públicos al momento de la recolección, incluidos 20 forks, y creó 21 repositorios solo el 10 de agosto. El perfil de GitHub de la cuenta enlaza a un perfil de X (@llmgod) que enlaza de vuelta a la cuenta de GitHub — una vinculación pública atribuida a la cuenta entre la identidad de entrega y la actividad pública centrada en IA/LLM.

Este modelo de entrega extiende el patrón de cadena de suministro que documentó el análisis de Plugin4Shell: cambios de configuración vía PR como vector que evita por completo los controles del marketplace. Plugin4Shell explotó el SHA-pinning del marketplace nombrando una rama como el commit fijado. Deadbugz evita los controles del marketplace al no usar un marketplace en absoluto — va directamente a los proyectos de código abierto a través de su flujo de contribución.

Las cuatro clases de ataque

La familia de seguridad MCP ahora tiene cuatro clases de ataque distintas, cada una explotando una frontera de confianza diferente:

Clase	Mecanismo	Documentado por primera vez	Dificultad de detección
Inyección de comandos STDIO	Comandos maliciosos incrustados en cadenas de configuración STDIO	Abril de 2026, más de 20 CVEs (Practical DevSecOps)	Media — el análisis estático detecta metacaracteres de shell
Envenenamiento de herramientas	La descripción de una herramienta benigna cambia después de la aprobación para manipular al agente	Invariant Labs, abril de 2025, WhatsApp sleeper	Media — detección de cambio de metadatos en el cliente
Omisión de SHA-pinning	Una rama nombrada como SHA defeats la verificación de fijación del marketplace	Plugin4Shell, septiembre de 2026	Difícil — requiere aserción de HEAD resuelto tras el checkout
Envenenamiento de metadatos activado en ejecución	Metadatos maliciosos retenidos hasta N llamadas, luego entregados a través de tools/list	Deadbugz, septiembre de 2026	Máxima — las pruebas de pre-despliegue no cruzan el umbral

La secuencia de ataque de Deadbugz y la taxonomía de cuatro clases, visualizadas:

Cada clase explota la misma brecha estructural: un mecanismo de confianza que realiza su comprobación en el momento equivocado o no la realiza. La inyección STDIO confía en cadenas de configuración sin sanitización. El envenenamiento de herramientas confía en que las descripciones no cambiarán después de la aprobación. SHA-pinning confía en que el commit resuelto coincide con el nombre fijado. El envenenamiento activado en ejecución confía en que lo que el servidor devolvió durante las pruebas es lo que devolverá durante el uso.

Deadbugz es el más difícil de detectar antes del despliegue porque el comportamiento del servidor durante la inspección es genuinamente benigno. La carga maliciosa no está oculta en el código de forma que el análisis estático pueda señalarla — está bloqueada detrás de un contador en tiempo de ejecución que solo se activa después de que el cliente ha establecido un patrón de uso. Un equipo de seguridad que se conecta al servidor, llama a format_text una o dos veces y comprueba la respuesta no verá nada incorrecto. El ataque está diseñado para pasar exactamente ese tipo de revisión.

Por qué los controles existentes no bastan

La lista de verificación de endurecimiento MCP organiza 12 controles en cinco capas: transporte, autenticación, registro de herramientas, tiempo de ejecución y auditoría. Deadbugz explota una brecha en las capas de registro de herramientas y tiempo de ejecución. Los controles de registro de herramientas de la lista verifican el servidor en el momento de la aprobación — comprobando nombres, esquemas y descripciones antes de que el servidor entre en producción. Pero las herramientas de Deadbugz son genuinamente benignas en el momento de la aprobación. Los controles de tiempo de ejecución monitorizan acciones no autorizadas, pero los metadatos envenenados no son en sí mismos una acción — son una instrucción que dirige al agente hacia una acción que el agente ejecuta después, aparentemente dentro de su alcance autorizado.

La tesis de módulos gobernados — que los registros de auditoría, los límites de velocidad, los errores tipados y la arquitectura de kill-switch hacen de la capa de gobernanza la frontera de seguridad — gana una cuarta clase de ataque como evidencia. El mecanismo de Deadbugz valida la tesis desde la dirección opuesta: un servidor sin controles de gobernanza (sin detección de cambios de metadatos, sin huella de definiciones de herramientas, sin diff visible para el operador de lo que el agente ve) es exactamente la superficie de ataque que explota la campaña.

La defensa: la huella de definiciones de herramientas

La recomendación de Pillar es concreta e implementable: capturar y comparar una huella de definiciones de herramientas en el momento de la aprobación. Cuando un cliente MCP aprueba un servidor, registra un hash de cada definición de herramienta que el servidor devuelve — nombre, descripción, esquema de entrada y anotaciones. Cuando el servidor notifica posteriormente al cliente que su lista de herramientas cambió (vía tools.listChanged), el cliente obtiene las nuevas definiciones, las compara con la huella y presenta el diff al operador como un evento de seguridad. La herramienta modificada no puede influir en acciones sensibles hasta que el operador la vuelva a aprobar.

Este control cierra la brecha que explota Deadbugz porque no depende de pruebas previas al despliegue. Monitoriza los metadatos reales que el servidor entrega en tiempo de ejecución, después de cruzar la frontera de confianza. La comparación de huellas detecta la reescritura de metadatos sin importar cuándo se activa la puerta en tiempo de ejecución — tres llamadas, treinta llamadas o trescientas. El control también detecta la clase anterior de envenenamiento de herramientas (el WhatsApp sleeper de Invariant Labs), porque ambos ataques comparten el mismo mecanismo: una descripción de herramienta que cambia después de la aprobación.

Cuatro pasos de implementación para un equipo que ejecuta servidores MCP en producción:

1. Registrar huellas de definiciones de herramientas en el momento de la aprobación. Hashear cada definición de herramienta que el servidor devuelve durante la conexión inicial. Almacenar las huellas junto al registro de aprobación del servidor en el sistema de gestión de configuración del agente.
2. Monitorizar las respuestas de tools/list y prompts/get en busca de deriva. Cuando el servidor notifique al cliente que su lista de herramientas cambió, obtener las nuevas definiciones y compararlas con las huellas almacenadas. Marcar cualquier diferencia como un evento de deriva de metadatos.
3. Exigir nueva aprobación del operador para las definiciones de herramientas modificadas. Una definición de herramienta modificada no puede influir en el comportamiento del agente hasta que un operador humano revise el diff y vuelva a aprobar explícitamente el servidor. Esto convierte una reescritura silenciosa de metadatos en un evento de seguridad visible.
4. Cercar la lectura de archivos sensibles, el acceso a credenciales y la ejecución de código con políticas — no con metadatos de herramientas. La carga de Deadbugz instruye al agente para buscar claves SSH, credenciales de AWS y configuración de Kubernetes. Esas lecturas deben ser acciones aplicadas por políticas que exijan autorización explícita, no consecuencias de instrucciones contenidas en metadatos de herramientas remotos. El análisis de agentes AI fantasma documenta la brecha de control en tiempo de ejecución que determina si una búsqueda de credenciales dirigida por metadatos pasa desapercibida.

Lecturas relacionadas

• SHA Pinning no es verificación: Plugin4Shell y el primer RCE de cadena de suministro en agentes de IA — la tercera clase de ataque MCP, que comparte el modelo de entrega vía PR de Deadbugz y el objetivo de cadena de suministro
• Lista de verificación de endurecimiento MCP: 1,467 servidores expuestos y los controles que los cierran — la línea base de 12 controles; la huella de definiciones de herramientas pertenece a las capas de registro de herramientas y tiempo de ejecución
• Seguridad MCP: por qué 200,000 instancias vulnerables hacen de los módulos gobernados un criterio de compra — la tesis de módulos gobernados que Deadbugz valida: un servidor sin controles de gobernanza es exactamente la superficie de ataque que explota la campaña

---

Un distribuidor B2B mid-market ejecuta un agente de procurement que se conecta a NetSuite, BigCommerce y tres catálogos de proveedores a través de módulos MCP. La revisión de seguridad del equipo se conecta a cada servidor MCP nuevo, llama a sus herramientas dos veces y comprueba las respuestas. Deadbugz pasa esa revisión. El equipo añade la huella de definiciones de herramientas a la configuración de su cliente MCP — las definiciones iniciales de cada servidor se hashean en la aprobación, las respuestas de tools/list se monitorizan en busca de deriva, y las definiciones modificadas activan una puerta de reaprobación del operador antes de que la herramienta modificada pueda influir en el comportamiento del agente. La próxima campaña de envenenamiento de metadatos se convierte en un diff señalado y una revisión, no en una exposición de credenciales.

Solicite una construcción con alcance. Descubrimiento de una semana. Recibe un inventario de sistemas, un mapa de flujos de trabajo y un alcance fijo — con o sin nosotros.