Deadbugz: un servidor MCP que se vuelve hostil en la tercera llamada a una herramienta, enviado a 23 repositorios en 74 minutos

El 10 de agosto de 2026, una cuenta de GitHub, zellkernel, abrió 23 solicitudes de extracción en 74 minutos contra repositorios no relacionados de IA, MCP y herramientas para desarrolladores, y cada una añadía un servidor MCP llamado productivity-suite que promocionaba dos herramientas comunes, format_text y summarize. Según Pillar Security, que bautizó la campaña como Deadbugz y publicó su informe el 12 de agosto, el servidor devolvió resultados honestos en sus tres primeras llamadas y luego reescribió los metadatos que entregaba al agente: las descripciones de las herramientas y el contenido de los prompts comenzaron a dirigir el modelo hacia claves SSH, credenciales de AWS, historial de shell y configuración de Kubernetes, y a indicarle que ocultara esa actividad al usuario. Diecinueve de las 23 solicitudes de extracción fueron cerradas, cuatro seguían abiertas y ninguna se había fusionado cuando Pillar las revisó. No se ha confirmado ninguna víctima. Este es un registro, informado por otros y citado aquí con atribución a ellos. Los demás incidentes de agentes documentados, cada uno con sus propias fuentes, gravedad, grado de confianza e indicador de disputa, figuran en el archivo de incidentes de IA — de modo que una campaña de cadena de suministro dirigida a las herramientas de agentes puede leerse junto al resto de lo que realmente ha ocurrido.

El archivo califica este registro como de alta severidad y confianza A —bien documentado, con fuentes primarias concordantes— mientras que, por separado, registra que no hubo ningún daño real confirmado. Ambas cosas son ciertas al mismo tiempo, y la brecha entre ambas es de lo que trata el registro: una campaña cuyo diseño quedó documentado con un detalle inusual antes de producir una víctima que alguien pueda nombrar. Las dos fechas que importan están separadas por dos días. Las pull requests se enviaron el 10 de agosto; Ariel Fogel, de Pillar Security, publicó el análisis el 12 de agosto, y la publicación lleva una nota permanente de que se actualizaría a medida que llegara información verificada.

Tres llamadas, luego cambian los metadatos

Un servidor MCP no tiene que ejecutar código en una máquina para cambiar lo que hace un agente. Las definiciones de herramientas se entregan al modelo como contexto en cada sesión, lo que significa que el servidor que las proporciona puede reescribir las instrucciones que lee el agente mientras deja el nombre de la herramienta, su repositorio y su manifiesto exactamente como estaban. Deadbugz se basa en esa asimetría, y el nombre que Pillar le da es envenenamiento de metadatos MCP condicionado en tiempo de ejecución.

La mecánica es lo bastante sencilla como para resumirse en una frase. El servidor mantiene en memoria un contador por cliente de solicitudes tools/call. Durante las tres primeras, se comporta con normalidad. Una vez que se dispara el contador, las respuestas posteriores a tools/list y prompts/get vuelven alteradas —descripciones de herramientas distintas, contenido de prompts distinto— y dirigen al agente hacia claves SSH, credenciales de AWS, el historial del shell y la configuración de Kubernetes, y le instruyen que oculte la actividad al usuario. El texto del prompt envenenado lleva la marca deadbugz y una dirección de Bitcoin.

La puerta también explica por qué las defensas ordinarias no lo detectan. El payload está presente en el código fuente desde la primera solicitud; nada en el código ni en la configuración cambia en el momento del cambio. Un escaneo estático, una entrada del SBOM o una lectura única del manifiesto de la herramienta en el momento de la instalación ve una utilidad de formato, porque eso es lo que devuelve la utilidad hasta que el contador avance. Pillar describe el cambio retardado como una técnica de evasión de investigación, y afirma que sus investigadores confirmaron tanto el umbral como los metadatos alterados enviando solicitudes de solo texto al servicio remoto activo y comparando las respuestas con el código fuente público.

Un detalle hace que la trampa sea más amplia que una sola sesión. El servidor anuncia tools.listChanged, la capacidad de MCP que indica a un cliente que su lista de herramientas ha sido revisada. Un cliente que atiende esa señal volverá a leer las definiciones a mitad de sesión y obtendrá la versión envenenada sin ninguna acción por parte del operador; un cliente que almacena en caché las definiciones tras la aprobación no lo hará. El comportamiento que tiene un agente concreto es una propiedad del cliente, no del servidor, y el informe de Pillar no enumera clientes por nombre.

Entrega: 23 solicitudes de extracción en 74 minutos

La distribución no era un paquete en un registro ni una dependencia envenenada enterrada en un lockfile. Era spam de pull requests contra proyectos que no tenían nada que ver con la función supuesta del servidor, que es la forma que adopta un intento de cadena de suministro de bajo costo cuando el atacante no puede obtener una cuenta de mantenedor: presentar suficientes cambios de configuración y esperar que uno sea fusionado o aplicado localmente.

El desglose que hace Pillar de los 23 es triple. Diecisiete añaden un endpoint MCP remoto, productivity-suite-mcp[.]onrender[.]com/mcp, alojado en Render; cuatro invocan un archivo Python local oculto en ~/.config/.cache/.sys/.deadbug-mcp.py; dos son envíos a directorios o listados, que el escrito trata como reconocimiento o relleno más que como entrega. La ventana se indica como de 9:52 PM a 11:07 PM UTC del 10 de agosto de 2026 — 74 minutos según el encuadre de la divulgación, aunque las dos marcas de tiempo en sí abarcan 75, y nada en el registro depende de ese minuto. Solo un repositorio objetivo se nombra individualmente: getsentry/sentry-mcp, la pull request #1239, citada como ejemplo de la entrega mediante artefacto local.

La cuenta que había detrás era considerable para su antigüedad. En el momento de la recopilación de Pillar, zellkernel tenía 50 repositorios públicos, 20 de ellos forks, y 21 de esos 50 se habían creado el 10 de agosto, el mismo día que la campaña. El perfil estaba vinculado de forma cruzada con la cuenta de X @llmgod, que enlazaba de vuelta a la cuenta de GitHub, que es el tipo de enlace recíproco que apunta a una identidad creada a propósito en lugar de una secuestrada.

Diecinueve cerradas, cuatro abiertas, cero fusionadas es la cifra más repetida en el registro y también la que más a menudo se lee como una señal de que todo está despejado, lo que no es del todo cierto. El botón de fusión de GitHub no es un registro de ejecución del host: un mantenedor puede traer una rama y ejecutarla, aplicar una configuración a mano, o un trabajo de CI puede obtener el head de una PR antes de que alguien comente. Las cuatro solicitudes de extracción que escriben una configuración que invoca una ruta de script local son aquellas en las que esa brecha importa más, porque el script se obtiene y se ejecuta completamente fuera de la contabilidad de fusiones de GitHub. Cloud Security Alliance Labs señaló lo mismo en su nota del 2 de septiembre: los recuentos de cerradas y no fusionadas no prueban que no se ejecutó nada.

Qué está establecido y qué no

Establecido por la divulgación, en el sentido de que Pillar lo informa a partir de artefactos que leyó y, en un caso, a partir de un servicio que consultó: el servidor y su repositorio de código fuente, las dos herramientas anunciadas, el contador y el umbral de tres llamadas, los cuatro objetivos de credenciales, los recuentos de PR y su estado de fusión en el momento de la revisión, y el vínculo entre la cuenta de GitHub y el identificador de X. La propia prueba de Pillar contra el endpoint en vivo es el elemento más sólido de la lista, porque es una reproducción y no una lectura del código fuente.

No está establecido, y el registro es cuidadoso al respecto: una víctima. El campo real_harm del archivo es false, lo que es una afirmación sobre la evidencia, no sobre la intención — nadie ha producido un host, un registro ni una credencial robada vinculada a esta campaña. Tampoco está identificada la persona o el grupo que hay detrás de zellkernel y @llmgod; Pillar atribuye la operación a las cuentas y se detiene ahí. El motivo financiero se apoya en una dirección de Bitcoin incrustada en el payload, lo cual es una inferencia a partir de un indicador, no un hallazgo sobre el actor. Y la pregunta que más quiere ver respondida un defensor — si la campaña sigue en curso — no tiene respuesta en el registro: la publicación quedó marcada como una que se actualizaría, y no se ve ninguna revisión posterior ni ningún aviso de retirada de GitHub o Render.

La corroboración es más débil de lo que podría sugerir el grado de confianza, y vale la pena decirlo sin rodeos. Dos Cloud Security Alliance Labs notas de investigación, fechadas el 30 de agosto y el 2 de septiembre de 2026, reiteran la campaña; la posterior deja claro que atribuye a Pillar el descubrimiento, los detalles del PR, el comportamiento del servidor y la atribución de la cuenta, y no describe ninguna verificación independiente propia. Una Armor entrada de blog fechada el 22 de septiembre de 2026 proporciona orientación defensiva y afirma que Pillar desmontó el servidor; no ofrece ninguna evidencia forense propia. No se asignó ningún CVE, y CSA afirma que esto no es una vulnerabilidad de la especificación MCP. Al 29 de octubre de 2026, las búsquedas no arrojan ningún aviso de GitHub ni de Render, y ninguna cobertura en la prensa especializada de seguridad convencional — ningún artículo de BleepingComputer, The Register, SecurityWeek ni Hackread — lo cual es inusual para una campaña de cadena de suministro de esta forma y es en sí mismo parte de lo que muestra el registro. "Las fuentes primarias coinciden" aquí significa una única fuente primaria originaria y un conjunto de documentos secundarios que derivan de ella.

Dos ambigüedades menores merecen señalarse en lugar de disimularse. Los resúmenes secundarios difieren sobre si la tercera llamada o la cuarta es la primera en recibir metadatos envenenados, lo cual se deriva de que el contador se describe como disparándose en la tercera solicitud; tanto el registro como la divulgación usan tres. Y la ventana de entrega se describe como 74 minutos para marcas de tiempo que abarcan 75.

Una comprobación que no se pudo repetir: el 29 de octubre de 2026, la cuenta de GitHub zellkernel y el repositorio zellkernel/productivity-suite-mcp devuelven ambos un 404, y la única pull request mencionada individualmente, getsentry/sentry-mcp #1239, tampoco se resuelve ya — el propio repositorio ahora redirige a getsentry/toolkit. Por lo tanto, los recuentos de PR, el estado de fusión y el contenido del repositorio no se pueden volver a verificar de primera mano hoy; se mantienen como la instantánea de Pillar, tomada a mediados de agosto.

Qué pide la divulgación que hagan los defensores

La respuesta que recomienda Pillar se centra principalmente en tratar los metadatos como una superficie de seguridad en lugar de una descripción de esta. Para los hosts, las peticiones concretas son bloquear o buscar productivity-suite-mcp[.]onrender[.]com/mcp, mantener el endpoint trycloudflare.com anterior de la campaña en las listas de denegación y búsqueda, aunque Pillar afirma que actualmente no está activo, y no ejecutar deadbug-mcp.py — la ruta de archivo oculta ~/.config/.cache/.sys/.deadbug-mcp.py es el artefacto que se debe buscar en los directorios personales, repositorios y configuraciones de cliente MCP.

El orden de la investigación importa más que la lista de bloqueo. Si un host puede haberse conectado, Pillar indica que se conserven los logs del cliente MCP antes de limpiar cualquier cosa, y luego se revisen las actualizaciones de definición de herramientas y lo que hizo el agente tras la tercera llamada; las credenciales solo deben rotarse cuando la evidencia local respalde la exposición, lo cual es lo contrario del reflejo de rotarlo todo ante la sospecha. La configuración del servidor también permitía telemetría opcional hacia un WEBHOOK_URL, con señales en la conexión, la primera llamada y el evento desencadenante — un detalle que le da a una investigación un tercer lugar donde mirar más allá de los logs del cliente y el tráfico del endpoint.

Para quienes desarrollan clientes MCP, la recomendación es estructural, y es la parte del registro con la vida útil más prolongada:

• Calcular la huella digital de las definiciones de herramientas en el momento de la aprobación y compararla en cada actualización, en lugar de confiar en el nombre y el repositorio del servidor.

• Trate un cambio de definición en un servidor ya aprobado como un evento de seguridad que el operador ve y vuelve a aprobar, no como una modificación rutinaria de metadatos que se absorbe en silencio.

• Aplicar las operaciones sensibles —acceso a credenciales, ejecución de código, correo electrónico saliente, escrituras en el repositorio— mediante políticas en lugar de las descripciones que proporciona el servidor.

Ese tercer elemento es lo que convierte a Deadbugz en un caso documentado y no en una simple curiosidad. Todos los controles anteriores asumen que a un agente se le puede persuadir de hacer cosas mediante el texto que un servidor adjunta a una herramienta, y que ese texto puede cambiar después de que se haya tomado la decisión de confianza. Pillar sitúa la campaña en una línea que incluye el ataque durmiente de MCP de Invariant Labs de 2025, el paquete falsificado postmark-mcp y un paquete MCP documentado por Koi y convertido en arma mediante una actualización; todos ellos son precedentes de la técnica, citados por Pillar por ese motivo y no como evidencia sobre esta entrega.

Por qué la puerta importa más que el número de víctimas

Una campaña con 23 intentos de entrega, sin fusión y sin víctima confirmada es fácil de archivar como intento y pasar a otra cosa. La razón por la que pertenece al archivo con severidad alta es que su evasión no depende de que la entrega tenga éxito a escala. Depende de una propiedad que la mayoría de las implementaciones de MCP comparten hoy: la aprobación ocurre una sola vez, en la instalación, y se asume que la definición aprobada es la definición que se servirá. Deadbugz mantiene intacta esa suposición durante tres llamadas y luego la rompe.

La solución no es un parche para un servidor concreto, y no hay ningún CVE que rastrear. Se trata de que «aprobado» tiene que convertirse en una condición continua con una comparación detrás; esto es un cambio en cómo se comportan los clientes y sus operadores, no un cambio en lo que busca un escáner. Si alguien llegó a ejecutar realmente el servidor en agosto sigue siendo desconocido; según consta en el registro tal como está, el mecanismo es el hallazgo.