Deadbugz: um servidor MCP que se torna hostil na terceira chamada de ferramenta, enviado para 23 repositórios em 74 minutos

Em 10 de agosto de 2026, uma conta do GitHub, zellkernel, abriu 23 pull requests em 74 minutos contra repositórios de IA, MCP e ferramentas de desenvolvimento não relacionados entre si, cada um adicionando um servidor MCP chamado productivity-suite que anunciava duas ferramentas comuns, format_text e summarize. Segundo a Pillar Security, que batizou a campanha de Deadbugz e publicou seu relatório em 12 de agosto, o servidor retornou resultados honestos nas três primeiras chamadas e então reescreveu os metadados que entregava ao agente: as descrições das ferramentas e o conteúdo dos prompts passaram a direcionar o modelo para chaves SSH, credenciais da AWS, histórico de shell e configuração do Kubernetes, e a instruí-lo a ocultar essa atividade do usuário. Dezenove dos 23 pull requests foram fechados, quatro ainda estavam abertos e nenhum havia sido mesclado quando a Pillar os analisou. Nenhuma vítima foi confirmada. Este é um registro, relatado por outros e aqui citado a eles. Os demais incidentes documentados envolvendo agentes, cada um com suas próprias fontes, grau de severidade, nível de confiança e sinalização de disputa, estão em the AI incident archive — assim, uma campanha de cadeia de suprimentos voltada para ferramentas de agentes pode ser lida ao lado de tudo o que de fato aconteceu.

O arquivo classifica este registro como de severidade alta e confiança A — bem documentado, com fontes primárias concordantes — enquanto, separadamente, registra que não houve nenhum dano real confirmado. Ambas as coisas são verdadeiras ao mesmo tempo, e é sobre essa lacuna que o registro trata: uma campanha cujo desenho foi documentado em detalhes incomuns antes de produzir uma vítima que qualquer pessoa possa nomear. As duas datas que importam estão separadas por dois dias. Os pull requests foram enviados em 10 de agosto; Ariel Fogel, da Pillar Security, publicou a análise em 12 de agosto, e a publicação traz uma nota permanente de que seria atualizada à medida que informações verificadas chegassem.

Três chamadas, depois os metadados mudam.

Um servidor MCP não precisa executar código em uma máquina para mudar o que um agente faz. As definições de ferramentas são entregues ao modelo como contexto em cada sessão, o que significa que o servidor que as fornece pode reescrever as instruções que o agente lê, deixando o nome da ferramenta, seu repositório e seu manifesto exatamente como estavam. O Deadbugz é construído sobre essa assimetria, e o nome que Pillar dá para isso é envenenamento de metadados MCP condicionado em tempo de execução.

A mecânica é simples o bastante para ser resumida em uma frase. O servidor mantém um contador em memória, por cliente, de solicitações de tools/call. Para as três primeiras, ele se comporta normalmente. Quando o contador é disparado, as respostas posteriores a tools/list e prompts/get voltam alteradas — descrições de ferramentas diferentes, conteúdo de prompt diferente — apontando o agente para chaves SSH, credenciais da AWS, histórico do shell e configuração do Kubernetes e instruindo-o a ocultar a atividade do usuário. O texto do prompt envenenado carrega o marcador deadbugz e um endereço Bitcoin.

O gate também explica por que as defesas comuns não o detectam. O payload está presente no código-fonte desde a primeira requisição; nada no código ou na configuração muda no momento da troca. Uma verificação estática, uma entrada no SBOM ou uma leitura única do manifesto da ferramenta no momento da instalação enxerga um utilitário de formatação, porque é isso que o utilitário retorna até que o contador avance. A Pillar descreve a troca atrasada como uma técnica de evasão de pesquisa e afirma que seus pesquisadores confirmaram tanto o limiar quanto os metadados alterados ao enviar requisições apenas de texto ao serviço remoto em execução e comparar as respostas com o código-fonte público.

Um detalhe torna a armadilha mais ampla do que uma única sessão. O servidor anuncia tools.listChanged, a capacidade MCP que informa a um cliente que a sua lista de ferramentas foi revista. Um cliente que respeite esse sinal voltará a ler as definições a meio da sessão e obterá a versão envenenada sem qualquer ação do operador; um cliente que faça cache das definições aquando da aprovação não o fará. O comportamento que um determinado agente tem é uma propriedade do cliente, não do servidor, e o documento de Pillar não enumera clientes por nome.

Entrega: 23 pull requests em 74 minutos

A distribuição não era um pacote em um registro nem uma dependência envenenada enterrada em um lockfile. Era spam de pull requests contra projetos que não tinham nada a ver com a suposta função do servidor, que é a forma que uma tentativa de cadeia de suprimentos de baixo custo assume quando o atacante não consegue uma conta de mantenedor: abrir alterações de configuração suficientes e esperar que uma seja mesclada ou aplicada localmente.

A divisão das 23 feita pela Pillar é tripartite. Dezessete adicionam um endpoint MCP remoto, productivity-suite-mcp[.]onrender[.]com/mcp, hospedado no Render; quatro invocam um arquivo Python local oculto em ~/.config/.cache/.sys/.deadbug-mcp.py; dois são envios a diretórios ou listagens, que o relatório trata como reconhecimento ou preenchimento, e não como entrega. A janela é indicada como das 21:52 às 23:07 UTC de 10 de agosto de 2026 — 74 minutos no enquadramento da divulgação, embora os dois carimbos de tempo, por si sós, abranjam 75, e nada no registro depende desse minuto. Apenas um repositório-alvo é nomeado individualmente: getsentry/sentry-mcp, pull request #1239, citado como exemplo da entrega de artefato local.

A conta por trás disso era substancial para a idade dela. Na época da coleta do Pillar, zellkernel tinha 50 repositórios públicos, 20 deles forks, e 21 desses 50 tinham sido criados em 10 de agosto, o mesmo dia da campanha. O perfil estava vinculado de forma cruzada à conta no X @llmgod, que tinha um link de volta para a conta do GitHub, o que é o tipo de vinculação recíproca que indica uma identidade criada para um propósito específico, em vez de uma sequestrada.

Dezenove fechados, quatro abertos, zero mesclados é o número mais repetido no registro e também o mais frequentemente interpretado como sinal verde, o que não é bem o caso. O botão de merge do GitHub não é o registro de execução de um host: um mantenedor pode puxar uma branch e executá-la, aplicar uma configuração manualmente, ou um job de CI pode buscar o head de um PR antes de qualquer comentário. Os quatro pull requests que gravam uma configuração invocando um caminho local de script são aqueles em que essa lacuna mais importa, porque o script é buscado e executado inteiramente fora da contabilização de merge do GitHub. A Cloud Security Alliance Labs fez o mesmo apontamento em sua nota de 2 de setembro: as contagens de fechados e não mesclados não provam que nada foi executado.

O que está estabelecido e o que não está

Estabelecido pela divulgação, no sentido de que a Pillar o relata a partir de artefatos que leu e, em um caso, de um serviço que consultou: o servidor e seu repositório de código-fonte, as duas ferramentas anunciadas, o contador e o limite de três chamadas, os quatro alvos de credenciais, as contagens de PR e seu status de merge no momento da revisão, e o vínculo entre a conta do GitHub e o handle no X. O teste da própria Pillar contra o endpoint ativo é o item mais forte da lista, porque é uma reprodução e não uma leitura de código-fonte.

Não está estabelecido, e o registro é cuidadoso quanto a isso: uma vítima. O campo real_harm do arquivo é false, o que é uma afirmação sobre evidências, não sobre intenção — ninguém produziu um host, um log ou uma credencial roubada ligada a esta campanha. Também não foram identificadas a pessoa ou o grupo por trás de zellkernel e @llmgod; a Pillar atribui a operação às contas e para por aí. O motivo financeiro se apoia num endereço Bitcoin incorporado ao payload, o que é uma inferência a partir de um indicador, não uma conclusão sobre o ator. E a pergunta que um defensor mais quer ver respondida — se a campanha ainda está em andamento — não tem resposta no registro: a postagem foi marcada como uma que seria atualizada, e nenhuma revisão posterior ou aviso de remoção do GitHub ou da Render está visível.

A corroboração é mais frágil do que o grau de confiança pode sugerir, e vale a pena dizer isso com clareza. Duas Cloud Security Alliance Labs notas de pesquisa, datadas de 30 de agosto e 2 de setembro de 2026, reiteram a campanha; a mais recente é explícita ao afirmar que credita ao Pillar a descoberta, os detalhes do PR, o comportamento do servidor e a atribuição da conta, e não descreve nenhuma verificação independente própria. Uma Armor postagem de blog datada de 22 de setembro de 2026 fornece orientação defensiva e afirma que a Pillar desmontou o servidor; não oferece nenhuma evidência forense própria. Nenhum CVE foi atribuído, e a CSA afirma que esta não é uma vulnerabilidade da especificação MCP. Em 29 de outubro de 2026, as buscas não revelam nenhum comunicado do GitHub ou da Render, nem cobertura na imprensa especializada de segurança mainstream — nenhum item do BleepingComputer, The Register, SecurityWeek ou Hackread — o que é incomum para uma campanha de cadeia de suprimentos desse formato e é, em si, parte do que o registro mostra. "Fontes primárias concordam", aqui, significa uma fonte primária de origem e um conjunto de documentos secundários que derivam dela.

Duas ambiguidades menores merecem ser apontadas em vez de atenuadas. Os resumos secundários divergem sobre se a terceira chamada ou a quarta é a primeira a receber metadados envenenados, o que decorre de o contador ser descrito como disparando na terceira solicitação; o registro e a divulgação usam ambos três. E a janela de entrega é descrita como 74 minutos para carimbos de data/hora que abrangem 75.

Uma verificação que não pôde ser repetida: em 29 de outubro de 2026, a conta do GitHub zellkernel e o repositório zellkernel/productivity-suite-mcp retornam ambos 404, e o único pull request nomeado individualmente, getsentry/sentry-mcp #1239, também não resolve mais — o próprio repositório agora redireciona para getsentry/toolkit. As contagens de PR, o status de merge e o conteúdo do repositório, portanto, não podem ser reverificados diretamente pela fonte primária hoje; eles permanecem como o snapshot da Pillar, capturado em meados de agosto.

O que a divulgação pede que os defensores façam

A resposta recomendada pela Pillar trata principalmente de considerar os metadados como uma superfície de segurança, e não como uma descrição dela. Para os hosts, as solicitações concretas são bloquear ou procurar por productivity-suite-mcp[.]onrender[.]com/mcp, manter o endpoint trycloudflare.com anterior da campanha nas listas de bloqueio e de busca, embora a Pillar diga que ele não está ativo no momento, e não executar deadbug-mcp.py — o caminho do arquivo oculto ~/.config/.cache/.sys/.deadbug-mcp.py é o artefato a ser procurado em diretórios home, repositórios e configurações de clientes MCP.

A ordem da investigação importa mais do que a lista de bloqueio. Se um host pode ter se conectado, Pillar orienta preservar os logs do cliente MCP antes de limpar qualquer coisa, depois revisar as atualizações de definição de ferramentas e o que o agente fez após a terceira chamada; as credenciais só devem ser rotacionadas quando evidências locais sustentarem exposição, o que é o oposto do reflexo de rotacionar tudo por suspeita. A configuração do servidor também permitia telemetria opcional para um WEBHOOK_URL, envio de beacons na conexão, na primeira chamada e no evento de gatilho — um detalhe que dá à investigação um terceiro lugar para procurar além dos logs do cliente e do tráfego de endpoint.

Para as pessoas que criam clientes MCP, a recomendação é estrutural, e é a parte do registro com a maior vida útil:

• Gere a impressão digital das definições da ferramenta no momento da aprovação e compare-as a cada atualização, em vez de confiar no nome e no repositório do servidor.

Trate uma alteração de definição em um servidor já aprovado como um evento de segurança que o operador vê e reaprova, e não como uma alteração rotineira de metadados a ser engolida silenciosamente.

• Imponha operações sensíveis — acesso a credenciais, execução de código, envio de e-mails externos, gravações no repositório — por meio de políticas, e não de descrições fornecidas pelo servidor.

Esse terceiro item é o que faz do Deadbugz um registro em vez de uma curiosidade. Todo controle acima pressupõe que um agente possa ser convencido a fazer coisas pelo texto que um servidor anexa a uma ferramenta, e que esse texto possa mudar depois que a decisão de confiança foi tomada. A Pillar situa a campanha em uma linhagem que inclui o ataque sleeper de MCP de 2025 da Invariant Labs, o pacote postmark-mcp falsificado e um pacote MCP documentado pela Koi e armado por meio de uma atualização — todos eles precedentes da técnica, citados pela Pillar para isso e não como evidência sobre esta entrega.

Por que o gate importa mais do que o número de vítimas

Uma campanha com 23 tentativas de entrega, sem merge e sem vítima confirmada é fácil de arquivar como tentativa e seguir em frente. A razão pela qual ela pertence ao arquivo com severidade alta é que sua evasão não depende de a entrega ter sucesso em escala. Ela depende de uma propriedade que a maioria das implantações de MCP compartilha hoje: a aprovação acontece uma vez, na instalação, e presume-se que a definição que foi aprovada será a definição que será servida. Deadbugz mantém essa suposição intacta por três chamadas e então a quebra.

A correção não é um patch para um servidor específico, e não há CVE a acompanhar. É que "aprovado" precisa se tornar uma condição contínua com uma comparação por trás — o que é uma mudança no comportamento dos clientes e de seus operadores, não uma mudança no que um scanner procura. Ainda não se sabe se alguém de fato executou o servidor em agosto; pelo registro como está, o mecanismo é o achado.