Backdoor no Postmark está baixando e-mails

• Foi detectado recentemente um comportamento malicioso no módulo postmark-mcp
• A partir da versão 1.0.16, foi adicionado um código que copia e-mails para um servidor externo do desenvolvedor
• Veio à tona uma vulnerabilidade estrutural que expõe e-mails sensíveis de centenas de organizações
• A ausência de um modelo de confiança para servidores MCP está ampliando o risco de ataques à cadeia de suprimentos
• Todos os usuários de MCP precisam de verificação imediata e remoção

---

O que são servidores MCP e visão geral do caso postmark-mcp

• Servidores MCP são ferramentas que permitem que assistentes de IA automatizem tarefas repetitivas, como envio de e-mails e execução de consultas em banco de dados
• Essas ferramentas operam com privilégios muito elevados, e o código criado por desenvolvedores é instalado quase que com base apenas em confiança, sem praticamente nenhum sistema real de verificação
• O pacote popular postmark-mcp pegou o código-fonte do repositório oficial do Postmark no GitHub, adicionou uma linha maliciosa de BCC e depois o publicou no npm com o mesmo nome
• A partir da versão 1.0.16, uma única linha foi adicionada a um código que parecia normal, fazendo com que todos os e-mails fossem copiados para o servidor pessoal do desenvolvedor (giftshop.club)
• Em outras palavras, foi um incidente em que todas as informações de e-mail ficaram expostas, incluindo redefinições de senha, faturas, memorandos internos e documentos confidenciais

Detecção do comportamento anômalo e estrutura do ataque

• O Risk Engine da Koi detectou sinais anômalos na versão 1.0.16
• A identidade do desenvolvedor parecia legítima no GitHub e em outros lugares, e as 15 primeiras versões funcionaram sem problemas, construindo confiança
• Na 1.0.16, foi adicionada uma única linha de código com a função de vazar informações importantes para fora
• O invasor usou uma técnica de personificação do desenvolvedor existente ao mesmo tempo em que copiava o código (Classic impersonation)
• Uma ferramenta que antes era usada normalmente acabou se tornando, em certo momento, parte de uma infraestrutura baseada em confiança, passando depois a executar comportamento malicioso

Impacto e método do vazamento de e-mails

• Com cerca de 1.500 downloads por semana, e assumindo que aproximadamente 20% estejam em uso ativo, centenas de organizações estariam expostas
• Estima-se que 3.000 a 15.000 e-mails por dia tenham sido enviados para giftshop.club
• Os usuários não verificam individualmente o comportamento da ferramenta e deixam a maior parte da execução automática a cargo do assistente de IA
• Não existe qualquer modelo de segurança, sandbox ou processo de verificação separado
• Embora o desenvolvedor tenha removido o pacote do npm, isso não surte efeito nos ambientes onde ele já foi instalado, de modo que os dados continuam sendo vazados

Análise das etapas do ataque

• Etapa 1: distribuição de ferramenta legítima

  • Da 1.0.0 até a 1.0.15, ela funcionou sem problemas e acumulou confiança

• Etapa 2: inserção de código malicioso

  • Na 1.0.16, foi adicionada uma linha de BCC, ativando a cópia de e-mails para um destino externo

• Etapa 3: coleta de informações

  • Senhas, chaves de API e dados financeiros/de clientes foram vazados para giftshop.club

• Não foi possível contatar o desenvolvedor, e embora o pacote tenha sido removido do npm, os danos em ambientes já instalados continuam em andamento

Falhas estruturais no ecossistema MCP

• Diferentemente de pacotes npm comuns, servidores MCP são ferramentas de alto risco que assistentes de IA chamam automaticamente centenas ou milhares de vezes
• Nem a IA nem as soluções de segurança existentes conseguem detectar se o código é malicioso, e tudo depende apenas de confiança
• Todo o ecossistema MCP tem uma estrutura arriscada, na qual todos os privilégios sobre ativos sensíveis são delegados a desenvolvedores anônimos
• São necessários controles de segurança, como identificação de ataques por detecção de mudanças de comportamento e um gateway de cadeia de suprimentos
• A Koi está promovendo o bloqueio de entrada e a verificação de pacotes maliciosos semelhantes com seu Risk Engine e gateway

Medidas de resposta e IOC

• Pacote malicioso: postmark-mcp (npm)
• Versão maliciosa: 1.0.16 ou superior
• E-mail de exfiltração: phan@giftshop[.]club
• Domínio: giftshop[.]club

Como detectar

• Verificar nos logs de e-mail sinais de envio com giftshop.club em BCC
• Revisar parâmetros inesperados de encaminhamento de e-mail na configuração do servidor MCP
• Analisar com rigor o histórico de instalação do postmark-mcp versão 1.0.16 ou superior

Resposta e recuperação

• Remover imediatamente o postmark-mcp
• Rotacionar todas as credenciais compartilhadas por e-mail durante o período de comprometimento
• Investigar integralmente os logs de e-mail contendo informações sensíveis possivelmente roubadas
• Se o dano for confirmado, reportar imediatamente às autoridades competentes

Conclusão e recomendações

• É indispensável aplicar procedimentos de verificação da identidade do desenvolvedor, validação de código e inspeção de segurança em todos os servidores MCP
• Pelas características do MCP (infraestrutura automatizada de apoio por IA), é essencial adotar ao menos um modelo mínimo de desconfiança e monitoramento contínuo
• Usuários do postmark-mcp 1.0.16 ou superior devem removê-lo imediatamente e adotar medidas de segurança sem demora
• É preciso ter em mente que o uso baseado apenas em confiança coloca todos diante do risco de ataques à cadeia de suprimentos
• Adotar Paranoia (desconfiança/suspeita) como política padrão é uma estratégia racional para o uso de MCP

[GN⁺]

Comentários do Hacker News

• Fico me perguntando qual é a diferença entre isso e a porta dos fundos em uma extensão do Thunderbird. Eu mantinha uma extensão do Thunderbird no passado e, quando perdi o interesse, apareceu uma pessoa que fez algumas contribuições reais e depois começou a insistir fortemente para assumir o projeto. No fim, achei absurdo entregar as chaves de dezenas de milhares de caixas de e-mail para um desconhecido, então recusei. Já é engraçado que as pessoas confiassem tanto em mim para começo de conversa, mas pelo menos eu sou uma boa pessoa
  • Penso exatamente a mesma coisa. Isso não é por causa de MCP; é o mesmo problema para qualquer software. No fim, você não tem escolha a não ser confiar nos desenvolvedores e fornecedores. Não há como impedir a Microsoft de copiar meus e-mails do Outlook, nem o Google de copiar o Gmail. Mesmo sendo open source e existindo a ideia de que “muitos olhos” revisam o código, isso talvez valha para projetos populares, mas ainda assim o risco continua. No fim, a maioria das pessoas simplesmente confia nos desenvolvedores. Esse problema é um vício antigo, tão velho quanto o próprio software
  • Na situação que você descreveu, eu sempre lembro de uma fala do Zuckerberg sobre privacidade. A gente precisa pensar por que entrega nossos dados e nossa privacidade assim, sem mais nem menos, para qualquer pessoa
  • Já aconteceu muitas vezes de eu colocar no carro um bêbado desconhecido e levar para casa. Sempre digo que pegar carona com um estranho desses é realmente perigoso. Sinceramente, foi sorte terem encontrado por acaso alguém bem-intencionado como eu, com tempo sobrando. Acho que isso acontece com frequência porque costumo ir tarde da noite a bares pequenos do bairro
• Não concordo com a premissa de que um único download no NPM equivale a uma organização única. Esse número é muito inflado. Um download no npm significa apenas que alguém (rodando um npm i) ou alguma coisa (um ambiente automatizado) instalou o pacote. No trabalho real, se o CI estiver montado de qualquer jeito, ele roda npm i por execução, ou até por etapa. Então 1.500 downloads podem, na prática, vir de apenas 2 empresas. Uma com um desenvolvedor usando isso para um PoC, e outra com a configuração de CI toda bagunçada. Até olhando o repositório oficial, são só 1 watch, 0 forks e 2 stars https://github.com/ActiveCampaign/postmark-mcp. O problema de MCP e da cadeia de suprimentos é sério, mas neste caso o impacto real é praticamente zero
  • Pela mesma lógica, os downloads dos pacotes populares de Python logo vão chegar ao ponto de cada ser humano do planeta — crianças, idosos e até quem nem sabe o que é um computador — ter feito um download cada. https://pypistats.org/top
• O artigo em si é bom, mas não entendo por que eu deveria ler uma versão traduzida por IA e resumida pelo ChatGPT. Eu preferia que mostrassem só o prompt original. Do jeito que está, parece desnecessariamente lento e meio desrespeitoso com o usuário
  • Ainda bem que você sentiu isso também. Eu odeio demais esse estilo de texto com intervenção de IA, mas tenho amigos que nem percebem ou simplesmente não se importam
• Isso anda aparecendo bastante ultimamente, mas acho que a gente não fala o suficiente sobre o fato de estarmos entregando poderes divinos a essas ferramentas. São ferramentas feitas por pessoas cujo rosto a gente nem conhece, e mesmo assim simplesmente confiamos nelas. O mesmo vale para assistentes de IA. Todo mundo vai lá e confia 100%. Existem artigos apontando isso, mas a sensação é meio “você sabia que, se apontar a arma para o próprio pé e puxar o gatilho, vai levar um tiro no pé??”. É tão óbvio que parece que esses artigos estão criando conteúdo em cima do nada. Fico me perguntando se realmente existe tanta gente que não sabe disso, ou se estão forçando a barra só para escrever texto
  • Teve recentemente aquele artigo sobre um assistente de código com IA que apagou o banco de dados de produção de uma empresa https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/. Há níveis nisso: 1) o fundador confiou totalmente na ferramenta de IA e acabou pagando por isso ele mesmo. Então ele realmente era ignorante sobre o risco. 2) Além disso, ele deixou o DB de produção acessível diretamente a partir do ambiente de desenvolvimento. Era um ambiente em que, cedo ou tarde, algum acidente aconteceria de qualquer forma
  • O que é óbvio para um usuário do HN não é nem um pouco óbvio para a maior parte do mundo. Esse tipo de artigo é conteúdo necessário para essas pessoas. Na prática, o design de servidores MCP e agentes de IA é inseguro por natureza porque segurança nem chegou a ser discutida desde o início. Não sei se isso vai mudar no futuro, mas até lá, o melhor que dá para fazer é continuar avisando
  • “As pessoas são realmente tão desligadas assim?” Até SQL injection básico continua causando danos enormes todos os anos e ainda está no topo do OWASP. SQL injection também é, no fim das contas, um problema de dar poderes divinos ao banco de dados sem entender como ele funciona. Os poderes de ação de um agente de IA também podem não ser visíveis para o usuário
  • O fato de esse tipo de acesso irresponsável estar acontecendo em larga escala via MCP precisa ser mais discutido. Até pessoas normalmente cautelosas muitas vezes não percebem direito o risco
  • Antigamente, deixar clientes de e-mail executarem mensagens com scripts embutidos enviadas por qualquer pessoa na internet era chamado de “revolução da automação”. Também já acharam que deixar crianças usarem a internet em vez de ver TV seria mais saudável, e todos sabemos como isso terminou, não?
• Tem essa ideia de que “virou normal instalar ferramentas feitas por qualquer pessoa aleatória”, mas na verdade isso já vem desde a era do Windows XP, quando a gente instalava sem preocupação qualquer software de ripar CD ou Bonzi Buddy e afins. Conveniência sempre veio antes da segurança. No fim, a lição mais importante é perguntar por que ainda não tornamos “sandbox, sandbox, sandbox” uma realidade. Neste caso, parece que a IA resetou para padrão de fábrica todos os princípios de segurança que já existiam
  • Para a pergunta “as pessoas escolhem conveniência em vez de segurança com facilidade; por que sandbox ainda não virou realidade?”, a resposta é que sandbox não é simples de implementar. E aqui “simples” significa algo oferecido por padrão pelo sistema operacional
• Um usuário pode até enviar para o GMail um e-mail de spam com prompt injection para a IA, sem que nenhum humano precise abrir a mensagem https://www.linkedin.com/posts/eito-miyamura-157305121_we-got-chatgpt-to-leak-your-private-email-activity-7372306174253256704-xoX1/
• Este post de blog é muito difícil de ler. Parece que a IA mexeu nele. Tem frase desnecessária e enfeite demais. Uma pena, porque o tema em si é interessante
• Em discussões sobre segurança da cadeia de suprimentos, pacotes npm quase sempre acabam sendo mencionados. Faz sentido, porque npm é o mais usado e, do ponto de vista dos atacantes, o incentivo também é grande, mas mesmo assim fica um gosto amargo
  • A OpenAI também distribui o Codex CLI pelo npm. Foi feito em Rust e mesmo assim usam um pacote npm. Pessoalmente, acho isso sem sentido. Mas imagino que as alternativas sejam ainda mais inconvenientes
  • Por isso eu não rodo servidores MCP via stdio. Todo MCP fica em uma VM host com isolamento por container Docker, numa VLAN não confiável. E eu só acesso via SSE. Claro, isso ainda é vulnerável a prompt injection, mas eu não conecto ao meu perfil principal do navegador, nem ao meu e-mail ou às minhas contas de nuvem. Fica totalmente separado de informações sensíveis
  • Não é desejável que o comentário acima tenha recebido tantos votos a ponto de parecer a principal conclusão deste artigo. Se a leitura for nessa direção, perde-se a essência do problema
• Talvez o desenvolvedor nem tenha feito isso de propósito. Eu mesmo já publiquei release com código de depuração sem querer. Se era um bcc simples, pode realmente ter sido código de debug
  • Eu vim aqui justamente para dizer isso. Sinceramente, a pessoa não deixaria o próprio e-mail tão escancarado assim se fosse intencional. E em 2025 ainda não é vergonha usar um Gmail pessoal para testes. Além disso, isso não é um problema exclusivo de MCP; pode acontecer com qualquer pacote
  • A reação de apagar o pacote também parece, sinceramente, uma resposta típica de desenvolvedor iniciante tendo o primeiro contato com um problema de segurança. Se foi só um erro de debug e não houve má intenção, então comunicação é o principal: remover a versão problemática, publicar um patch e se comunicar em canais públicos como blog, HN, redes sociais etc. é o caminho para recuperar a confiança. Uma linha do tempo precisa do incidente (e não um resumo escrito por IA como o do OP) também ajuda a reconstruir a confiança
• O problema dos servidores MCP é perigoso, mas esse tipo de ataque pode acontecer em qualquer situação que use dependências externas, como um pacote SMTP, por exemplo
  • Sim, mas com pacote SMTP normalmente se usam bibliotecas antigas e bem estabelecidas, com histórico de confiança. O problema do MCP é que tudo é novo e ainda não houve tempo para construir essa confiança. É meio um deserto de software, um ambiente em que você precisa andar com um revólver de 6 tiros carregado o tempo todo