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.mjsfoi 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.jsondos dois pacotes passou a rodar esse arquivo automaticamente comopreinstall— 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.
npm install --ignore-scripts por padrão em ambientes sensíveis reduz bastante esse risco.

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:
- Consultava, via chamadas JSON-RPC, um endereço fixo de contrato na rede Ethereum, usando endpoints RPC públicos.
- Decodificava uma lista de domínios a partir da resposta do contrato.
- Baixava de cada domínio um arquivo JSON num caminho
/loadere, se os campos esperados estivessem presentes, gravava um payload binário num diretório temporário do sistema. - 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. - 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.

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.
