FlawOpen

flawopen.com/Incidents/deadbugz-mcp-delayed-metadata-supply-chain-campaign-august-2026

● Pillar Security / MCP ecosystem · CWE-829 (editorial mapping; no CVE assigned) · 2026-08-10 · Media
Investigación · FlawOpen

Deadbugz: los metadatos MCP cambian tras la aprobación

Pillar Security documentó una campaña de cadena de suministro MCP que cambiaba metadatos tras tres llamadas normales. Su revisión no encontró pull requests fusionados por el mecanismo de PR de GitHub; el informe no documentó una intrusión posterior. Cloud Security Alliance señala que la visibilidad sobre ejecuciones locales independientes era limitada.[1], [3]

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina aprobar a un contratista porque su credencial indica tareas inofensivas. Tras tres entregas rutinarias, la credencial cambia en secreto y pide acceso a salas cerradas. El peligro es que el edificio siga confiando en la aprobación anterior. Un cliente MCP debe detectar si el servidor cambia las instrucciones de las herramientas aprobadas.[1]

Conceptos Clave y Términos

MCP
Protocolo mediante el que una aplicación de IA descubre y llama herramientas ofrecidas por un servidor.[5]
Metadatos de herramienta
Nombre, descripción y esquema de entrada que el cliente puede incluir en el contexto del modelo.[5], [1]
Cambio condicionado en tiempo de ejecución
Comportamiento aplazado hasta alcanzar un umbral de interacciones; Pillar informó de un contador de tres llamadas.[1]
Distribución de cadena de suministro
Introducir una dependencia o configuración mediante un flujo de desarrollo confiable, como un pull request.[1]
CWE-829
Clasificación editorial: se incorporó funcionalidad desde un servidor fuera de la esfera de control confiable del cliente. No se asignó CVE ni CVSS.[1], [3]

Mapeos de marcos

  • Referencia CWE para la debilidad descrita en esta guía: CWE-829

Cronología del Incidente

2026-08-10

Pillar identificó 23 pull requests relacionados en 74 minutos; en ese momento, ninguno se había fusionado mediante el mecanismo de PR de GitHub.[1]

2026-08-12

Pillar publicó su análisis técnico del cambio de metadatos tras tres llamadas y los indicadores.[1]

2026-10-08

El proyecto OWASP GenAI incluyó Deadbugz en su resumen del tercer trimestre; esto acredita atención, no intrusión ni volumen de búsquedas.[2]

Flujo de Ataque Paso a Paso

Paso 1

Se propone una configuración

Un pull request añade la configuración de un servidor MCP remoto o local a un proyecto de IA. Pillar revisó 17 cambios con endpoint remoto, cuatro referencias a un script local oculto y dos envíos de listados.[1]

Paso 2

La revisión inicial ve herramientas normales

Al principio, el servidor presenta herramientas de formato y resumen de texto. Según Pillar, las pruebas breves pueden recibir estos metadatos benignos.[1]

Paso 3

El uso normal supera el umbral

El servidor cuenta las llamadas por cliente. Tras tres llamadas, las siguientes respuestas de tools/list y prompts/get contienen instrucciones distintas.[1], [5]

Paso 4

El agente recibe indicaciones no confiables

Esas instrucciones intentan dirigir al agente hacia información local sensible y ocultar la actividad. La descripción de la campaña no confirma una intrusión.[1], [3]

Paso 5

La aprobación debe vincularse a los metadatos exactos

El cliente debe calcular una huella de las definiciones aprobadas y detenerse para revisión si el servidor presenta otras. Los permisos de archivos, credenciales y red deben aplicarse por separado.[1], [4], [5]

Código Fuente: Vulnerable vs. Seguro

El informe describe envenenamiento de metadatos y distribución mediante pull requests, no una CVE de la especificación MCP. El riesgo aparece cuando el cliente sigue confiando en descripciones mutables del servidor después de la aprobación inicial. Pillar atribuye la campaña a una cuenta pública de GitHub; aquí se presenta como una atribución de Pillar, no como identidad real verificada. Pillar indicó que los PR revisados no se habían fusionado mediante el flujo de GitHub en ese momento y no acreditó una intrusión posterior. El repositorio enlazado actualmente devuelve 404, por lo que los detalles se basan en el análisis técnico publicado por Pillar, no en una nueva inspección independiente del árbol de código. El ejemplo Python es una política ilustrativa del cliente, no código listo para sustituir una biblioteca MCP. CWE-829 es una clasificación editorial; no hay CVE ni CVSS. El adaptador debe actualizar los datos tras notificaciones de cambio MCP e incluir tools/list y prompts/get; metadata_snapshot es un método ilustrativo del adaptador, no una API de un SDK MCP. Genere approved_digest solo tras la revisión del operador. La captura debe incluir todos los metadatos relevantes del servidor: definiciones de tools/list y el contenido completo de prompts/get de los prompts aprobados. Vuelva a consultarla antes de ejecutar y detenga la acción si difiere; esta comprobación no detecta cambios de comportamiento del servidor ni cambios entre la verificación y el uso, por lo que siguen siendo necesarias restricciones independientes.[1], [4], [5]

IMPLEMENTACIÓN VULNERABLE
def agent_metadata(session):
    # El adaptador devuelve las herramientas y los prompts actuales del servidor como datos JSON.
    return session.metadata_snapshot()
PARCHE SEGURO Y ROBUSTO
import hashlib
import hmac
import json

def fingerprint(snapshot):
    normalized = dict(snapshot)
    for key in ("tools", "prompts"):
        normalized[key] = sorted(
            snapshot[key],
            key=lambda item: json.dumps(item, sort_keys=True, separators=(",", ":")),
        )
    canonical = json.dumps(normalized, sort_keys=True, separators=(",", ":"))
    return hashlib.sha256(canonical.encode()).hexdigest()

def agent_metadata(session, approved_digest):
    current = session.metadata_snapshot()
    if not hmac.compare_digest(fingerprint(current), approved_digest):
        raise PermissionError("MCP metadata changed; require operator approval")
    return current

Lista de Verificación de Seguridad para Ingeniería

Fuentes