Ya hemos escrito sobre servidores MCP que nadie evaluó y sobre la mayoría de servidores públicos que sigue saltándose OAuth. Ambos casos tratan de servidores en los que nunca debiste confiar desde el principio. Deadbugz, una campaña activa revelada por investigadores de Pillar Security y registrada por el rastreador comunitario de incidentes MCP como INC-136 el 18 de septiembre de 2026, es un problema distinto: un servidor que parecía correcto cuando lo aprobaste, y que cambió de comportamiento después.
Qué se descubrió
Una sola cuenta de GitHub presentó 23 pull requests en repositorios de IA y herramientas de desarrollo sin relación entre sí, cada una añadiendo un pequeño servidor MCP presentado como utilidad de productividad — formato de texto y resúmenes, nada que llamara la atención en una revisión de código. Ninguna de las pull requests se llegó a fusionar antes de que se detectara la campaña, y no hay ningún compromiso confirmado hasta el momento de la divulgación; los investigadores lo tratan como una técnica demostrada, no como una brecha con víctimas.
El mecanismo: gating por número de llamadas
El comportamiento del servidor depende de cuántas veces lo ha llamado ya un cliente, no de lo que se le pide — lo que le permitió pasar desapercibido en una revisión rápida y en una primera sesión.
Llamadas una y dos
El servidor devuelve exactamente lo que promete su descripción: texto formateado o resumido. Quien lo prueba ve una herramienta pequeña, aburrida y que funciona.
Llamada tres
El servidor reescribe los metadatos que devuelve — las descripciones de herramientas que el modelo lee como instrucciones — convirtiéndolos en órdenes para buscar claves SSH, credenciales de AWS, historial de shell y configuración de Kubernetes, y hacerlo sin llamar la atención.
Por qué la revisión por sesión no lo detecta
La mayoría de las pruebas manuales y de los flujos de aprobación de una sola vez se detienen tras una o dos llamadas. La carga está calculada para aparecer después del punto en que una persona normalmente ya ha dejado de observar.
Por qué es una amenaza distinta a un servidor malicioso desde el primer día
Las descripciones de herramientas en MCP no son documentación para una persona — son texto que el modelo conectado lee y sobre el que puede actuar, lo que es precisamente lo que hace posible la prompt injection a través de metadatos de herramientas. Una aprobación única asume que lo que aprobaste sigue siendo lo que se está ejecutando. Deadbugz demuestra que esa suposición no está garantizada hoy en ninguna parte del ecosistema: nada en la especificación exige un manifiesto de herramientas firmado, y nada en la mayoría de los clientes vuelve a pedir consentimiento cuando cambian las definiciones de herramientas de un servidor ya aprobado.
Qué hacer en la práctica
- Calcula una huella (fingerprint) de las definiciones de herramientas en el momento de aprobarlas, y compárala en cada reconexión — un cambio es un evento de seguridad, no una actualización rutinaria.
- Trata cualquier cambio de definición en un servidor ya aprobado como algo que exige consentimiento explícito renovado, nunca aceptación silenciosa automática.
- No confíes en una primera sesión para evaluar un servidor de terceros. Si tu proceso es 'pruébalo una vez y luego confía', es exactamente ese el hueco que esto explota.
- Prefiere servidores cuya definición controlas tú, o tu plataforma, antes que servidores sacados de un registro abierto o de una pull request que no escribiste.
En SuperCognit, las herramientas de un agente son endpoints HTTP que define el propietario del workspace y que puede ver por completo, no servidores de terceros traídos de un registro — en ese camino no hay ninguna pull request de un desconocido. Eso esquiva esta campaña en concreto, pero no hace desaparecer el problema de fondo: cualquiera que conecte Claude, Claude Code o cualquier otro cliente MCP a servidores del ecosistema abierto debería comprobar de verdad el origen de un servidor, y cualquier cambio en lo que anuncia.
Este relato se basa en la divulgación pública de Pillar Security y en la entrada de la base de datos comunitaria de incidentes MCP (INC-136); parte del detalle procede de cobertura secundaria y no del texto original, y ninguna de las dos fuentes ha publicado hasta ahora una víctima confirmada.