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 · Média
Pesquisa · FlawOpen

Deadbugz: metadados de ferramentas MCP mudam após aprovação

A Pillar Security documentou uma campanha de cadeia de suprimentos MCP que alterava metadados após três chamadas normais. Sua análise não encontrou pull requests mesclados pelo mecanismo de PR do GitHub; o relatório não documentou comprometimento posterior. A Cloud Security Alliance observa que havia visibilidade limitada sobre execuções locais independentes.[1], [3]

💡 Explicação em Linguagem Simples (ELI5)

Imagine aprovar um prestador porque o crachá mostra tarefas inofensivas. Depois de três entregas rotineiras, o crachá muda discretamente e passa a pedir acesso a salas trancadas. O perigo é o prédio continuar confiando na aprovação antiga. Um cliente MCP precisa detectar quando o servidor muda as instruções das ferramentas aprovadas.[1]

Conceitos Centrais e Termos

MCP
Protocolo pelo qual um aplicativo de IA descobre e chama ferramentas oferecidas por um servidor.[5]
Metadados da ferramenta
Nome, descrição e esquema de entrada que o cliente pode incluir no contexto do modelo.[5], [1]
Mudança condicionada à execução
Comportamento oculto até um limite de interações; a Pillar relatou um contador de três chamadas.[1]
Entrega pela cadeia de suprimentos
Introdução de dependência ou configuração por um fluxo de desenvolvimento confiável, como um pull request.[1]
CWE-829
Classificação editorial: funcionalidade veio de um servidor fora da esfera de controle confiável do cliente. Não há CVE nem pontuação CVSS.[1], [3]

Mapeamentos de frameworks

  • Referência CWE para a fraqueza descrita neste guia: CWE-829

Linha do Tempo do Incidente

2026-08-10

A Pillar identificou 23 pull requests relacionados em uma janela de 74 minutos; na época, nenhum havia sido mesclado pelo mecanismo de PR do GitHub.[1]

2026-08-12

A Pillar publicou análise técnica da mudança de metadados após três chamadas e seus indicadores.[1]

2026-10-08

O projeto OWASP GenAI incluiu Deadbugz no resumo do terceiro trimestre; isso demonstra atenção, não comprometimento ou volume de buscas.[2]

Fluxo de Ataque Passo a Paso

Passo 1

A configuração é proposta

Um pull request adiciona a configuração de um servidor MCP remoto ou local a um projeto de IA. A Pillar analisou 17 mudanças com endpoint remoto, quatro referências a script local oculto e duas submissões de listagem.[1]

Passo 2

A análise inicial vê ferramentas comuns

No início, o servidor oferece ferramentas de formatação e resumo de texto. Segundo a Pillar, testes breves podem receber esses metadados benignos.[1]

Passo 3

O uso normal cruza o limite

O servidor conta chamadas por cliente. Após três chamadas, respostas seguintes de tools/list e prompts/get trazem instruções alteradas.[1], [5]

Passo 4

O agente recebe instruções não confiáveis

As instruções tentam direcionar o agente conectado a informações locais sensíveis e ocultar a atividade. A descrição da campanha não confirma comprometimento.[1], [3]

Passo 5

A aprovação deve estar vinculada aos metadados exatos

O cliente deve calcular uma impressão digital das definições aprovadas e pausar para revisão quando o servidor apresentar outras. Permissões de arquivos, credenciais e rede devem ser aplicadas de forma independente.[1], [4], [5]

Código-Fonte: Vulnerável vs. Seguro

O relatório descreve envenenamento de metadados e entrega por pull request, não uma CVE na especificação MCP. O risco surge quando o cliente continua confiando em descrições mutáveis fornecidas pelo servidor após a aprovação inicial. A Pillar atribuiu a campanha a uma conta pública do GitHub; este artigo apresenta isso como uma conclusão da Pillar, não como identidade real verificada. A empresa disse que os PRs analisados não haviam sido mesclados pelo fluxo de PR do GitHub naquele momento e não confirmou comprometimento posterior. O repositório de código referenciado atualmente retorna 404; por isso, os detalhes técnicos dependem da análise publicada pela Pillar, não de uma nova leitura independente do código. O exemplo Python é uma política ilustrativa no cliente, não um trecho pronto para substituir uma biblioteca MCP. CWE-829 é uma classificação editorial; não há CVE nem CVSS. O adaptador deve atualizar os dados após notificações de mudança MCP e incluir tools/list e prompts/get; metadata_snapshot é um método ilustrativo do adaptador, não uma API de SDK MCP. Gere approved_digest somente após revisão do operador. O snapshot deve incluir todos os metadados relevantes fornecidos pelo servidor, incluindo definições de tools/list e o conteúdo completo de prompts/get dos prompts aprovados. Atualize antes de despachar e interrompa a ação se houver divergência; essa verificação não detecta mudanças no comportamento do servidor nem alterações entre a checagem e o uso, portanto permissões independentes continuam necessárias.[1], [4], [5]

IMPLEMENTAÇÃO VULNERÁVEL
def agent_metadata(session):
    # O adaptador retorna as ferramentas e os prompts atuais do servidor como dados JSON.
    return session.metadata_snapshot()
PATCH SEGURO E 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 Verificação de Segurança para Engenharia

Fontes