Zod Comprometido? O Alerta de Malware no NPM

Zod Comprometido? O Alerta de Malware no NPM

Um commit aparentemente comum, só atualizando a versão de uma biblioteca JavaScript muito usada, escondia um script que consultava um contrato na blockchain Ethereum e, a partir da resposta, baixava e executava código remoto durante a instalação. Isso aconteceu com o Zod, uma das bibliotecas de validação de dados mais populares do ecossistema JavaScript/TypeScript.

O caso foi descoberto por desenvolvedores que analisaram o histórico de commits do repositório oficial no GitHub e levantou alerta imediato na comunidade — Zod é dependência direta ou indireta de milhares de projetos, incluindo ferramentas que lidam com dados sensíveis.

Neste artigo, explicamos exatamente o que o commit alterava, por que isso é considerado um padrão clássico de ataque à cadeia de suprimentos de software, e o que fazer se o seu projeto usa essa biblioteca.

O que exatamente o commit alterou

A versão passou de 4.6.5 para 4.6.6 nos pacotes zod e zod/mini. Junto com a mudança de versão, três alterações chamaram atenção de quem revisou o código:

  • Um novo arquivo chamado meta.test.mjs foi adicionado — apesar do nome sugerir um teste, o conteúdo é um script minificado e ofuscado em base64, sem relação nenhuma com testes automatizados.
  • O package.json dos dois pacotes passou a rodar esse arquivo automaticamente como preinstall — ou seja, o script executa sozinho no momento em que qualquer pessoa instala a biblioteca, antes mesmo de qualquer código do projeto rodar.
  • O workflow de publicação automática (release.yml) foi alterado para publicar a nova versão no npm sozinho, removendo um comentário que antes exigia aprovação manual do mantenedor antes de qualquer publicação.
💡 Dica Iazando: Scripts de “preinstall” e “postinstall” em pacotes npm são um dos vetores de ataque mais comuns em cadeia de suprimentos justamente porque rodam automaticamente, sem o desenvolvedor perceber. Rodar npm install --ignore-scripts por padrão em ambientes sensíveis reduz bastante esse risco.
Programador digitando comandos em um terminal de computador
O script suspeito foi configurado para rodar automaticamente como “preinstall”, antes de qualquer código do projeto ser executado. Foto: Jakub Zerdzicki / Pexels.

O que o script parecia fazer, segundo a leitura do código

Pela análise do diff publicado no GitHub, o comportamento do script seguia um fluxo bem conhecido entre pesquisadores de segurança:

  1. Consultava, via chamadas JSON-RPC, um endereço fixo de contrato na rede Ethereum, usando endpoints RPC públicos.
  2. Decodificava uma lista de domínios a partir da resposta do contrato.
  3. Baixava de cada domínio um arquivo JSON num caminho /loader e, se os campos esperados estivessem presentes, gravava um payload binário num diretório temporário do sistema.
  4. Importava dinamicamente código JavaScript codificado em base64 por meio de uma URL do tipo data:, definindo uma variável de ambiente antes de executar.
  5. Apagava o diretório temporário depois de concluir, dificultando a investigação posterior.

Usar um contrato de blockchain como fonte dos endereços de download é uma técnica cada vez mais comum entre atacantes, porque contratos inteligentes são difíceis de remover ou bloquear — diferente de um domínio comum, que pode ser derrubado por uma denúncia.

O que ainda não está confirmado

É importante separar o que o código mostra do que foi efetivamente comprovado em produção. Até a publicação deste artigo, a página do commit no GitHub não trazia nenhum comentário do mantenedor explicando o que aconteceu, nem confirmação pública de que a versão comprometida chegou a ser publicada no npm ou foi revertida antes disso.

Ou seja: o código do commit é, por si só, compatível com um ataque de cadeia de suprimentos — mas não há, nesta análise, prova de que algum usuário final já tenha sido afetado na prática. Também não se sabe se a causa foi uma conta de mantenedor comprometida, uma dependência interna atacada, ou outra explicação ainda não divulgada.

Representação visual de uma rede blockchain com conexões de dados
O script consultava um contrato na blockchain Ethereum para decodificar uma lista de domínios de onde baixaria código. Foto: Pachon in Motion / Pexels.

O que fazer se seu projeto usa Zod

Situação Ação recomendada
Ainda não atualizou para 4.6.6 Trave a versão anterior no seu gerenciador de pacotes até haver esclarecimento oficial.
Já instalou a versão 4.6.6 Procure o arquivo meta.test.mjs dentro de node_modules e reinstale as dependências com --ignore-scripts.
Tem chaves/segredos no mesmo ambiente Considere revogar e trocar credenciais que estavam acessíveis no ambiente onde a instalação rodou.
Quer confirmação oficial Acompanhe os avisos de segurança do repositório e do registro do npm antes de considerar o caso encerrado.

Perguntas frequentes

O Zod é uma biblioteca perigosa de usar?

Não pelo que a biblioteca faz — Zod é amplamente usada e bem avaliada pela comunidade. O risco aqui é específico de uma versão (4.6.6) e do processo de publicação, não da proposta da ferramenta em si.

Como esse tipo de ataque é chamado?

É um ataque à cadeia de suprimentos de software (supply chain attack): em vez de atacar diretamente quem usa um sistema, o atacante compromete uma peça que várias aplicações dependem, multiplicando o alcance.

Rodar “npm install –ignore-scripts” resolve o problema sozinho?

Ajuda bastante a reduzir a superfície de ataque, porque impede scripts de instalação automáticos — mas não substitui conferir se a versão instalada é mesmo segura nem revisar dependências regularmente.

Isso afeta só quem usa Zod em projetos Node.js?

O risco se aplica a qualquer ambiente onde o pacote é instalado via npm, incluindo builds de front-end e back-end que dependem de Zod direta ou indiretamente por outra biblioteca.

Conclusão

O caso do Zod é um bom lembrete de que até bibliotecas populares e bem mantidas podem ser alvo de ataques à cadeia de suprimentos — e de que revisar dependências não é exagero, é rotina básica de segurança. Enquanto não houver confirmação oficial, a recomendação segue sendo cautela.

Quer entender outro episódio recente de segurança no ecossistema de IA e código aberto? Leia também: Google Pausa Programa de Bug Bounty Open Source.