Nos últimos dias, a comunidade JavaScript foi surpreendida por um grave ataque à cadeia de suprimentos, comprometendo pacotes NPM amplamente utilizados como o eslint-config-prettier — que sozinho possui mais de 30 milhões de downloads semanais. Essa ação maliciosa teve como objetivo distribuir malware por meio de versões adulteradas desses pacotes, afetando projetos ao redor do mundo.
O ataque evidencia o quão vulnerável o ecossistema de código aberto pode ser quando mantenedores de confiança são alvo de engenharia social. Neste artigo, explicamos o que ocorreu, quais pacotes e versões foram comprometidos, como o ataque funcionava e, o mais importante, como os desenvolvedores podem se proteger.
O que aconteceu: O sequestro das bibliotecas
O incidente veio à tona quando usuários relataram comportamentos estranhos ao instalar pacotes como o eslint-config-prettier. A investigação revelou que o mantenedor original, conhecido como JounQin, havia sido vítima de um ataque de phishing. Com acesso ao seu token NPM, o atacante conseguiu publicar novas versões maliciosas de diversos pacotes sob seu controle.
Essas versões comprometidas passaram a instalar scripts maliciosos automaticamente no momento da instalação, afetando especialmente usuários de sistemas Windows. Esse tipo de ataque — onde um pacote legítimo é alterado para espalhar código malicioso — é conhecido como ataque à cadeia de suprimentos JavaScript, e tem se tornado cada vez mais comum.
O vetor do ataque: Um simples e-mail de phishing
O ponto de entrada foi um e-mail de phishing enviado para o mantenedor, disfarçado como uma mensagem oficial da NPM, vinda do endereço falso [email protected]. O e-mail solicitava que o desenvolvedor fizesse login para resolver uma suposta violação de política. Ao clicar no link e inserir suas credenciais, o invasor obteve acesso total à conta NPM de JounQin.
Com esse acesso, o atacante publicou novas versões de diversos pacotes legítimos com scripts maliciosos embutidos, aproveitando-se da confiança da comunidade nesses projetos.
Como o malware funciona: O script de pós-instalação
O mecanismo do ataque foi implementado através de um script postinstall — um recurso legítimo do NPM que permite executar comandos após a instalação do pacote.
O código malicioso era incorporado em um arquivo chamado install.js, que continha uma função aparentemente inofensiva chamada logDiskSpace(). Porém, em sistemas Windows, essa função executava uma biblioteca DLL maliciosa chamada node-gyp.dll usando o comando rundll32.
Com isso, o código malicioso podia ser executado sem levantar suspeitas durante a instalação do pacote, comprometendo a máquina do desenvolvedor ou os ambientes de CI/CD utilizados em pipelines automatizadas.
Ação imediata: Como verificar se você foi afetado e o que fazer
Se você ou sua equipe utilizam os pacotes citados, é fundamental agir imediatamente. A seguir, mostramos como identificar se há risco em seu projeto e o que fazer para mitigar o impacto.
Verifique suas dependências e versões
Confira se seu projeto está utilizando alguma das versões maliciosas abaixo:
- eslint-config-prettier: versões 8.10.1, 9.1.1, 10.1.6 e 10.1.7
- eslint-plugin-prettier: versões 4.2.2 e 4.2.3
- synckit: versão 0.11.9
- @pkgr/core: versão 0.2.8
- napi-postinstall: versão 0.3.1
Procure por essas versões nos seus arquivos package-lock.json, yarn.lock, pnpm-lock.yaml ou similares. Ferramentas como npm ls, yarn list ou pnpm list também podem ajudar na detecção.
Próximos passos e medidas de segurança
Se qualquer uma dessas versões estiver presente no seu projeto, siga os seguintes passos:
- Atualize os pacotes afetados para versões limpas ou remova-os imediatamente, se possível.
- Audite seus arquivos de lock e pipelines CI/CD em busca de execuções inesperadas.
- Revogue tokens e segredos expostos (API Keys, variáveis de ambiente, etc.) que possam ter sido comprometidos.
- Rode uma varredura de segurança, como
npm auditou ferramentas externas como Snyk e Socket.dev. - Habilite a autenticação de dois fatores (2FA) nas suas contas do NPM, GitHub e demais serviços de desenvolvimento.
O cenário maior: A crescente ameaça aos repositórios de código aberto
Este caso está longe de ser um evento isolado. Em 2024, já havíamos visto ataques semelhantes afetando event-stream, coa, ua-parser-js e outros pacotes populares. O vetor mais comum tem sido a engenharia social, onde o atacante convence um mantenedor a entregar o controle — seja por phishing, falsas propostas de parceria ou trocas de e-mail fraudulentas.
Por isso, plataformas como o NPM e o GitHub vêm reforçando práticas como o uso obrigatório de autenticação de dois fatores, especialmente para quem mantém projetos com grande número de downloads.
Mantenedores de bibliotecas populares são alvos de alto valor. A comunidade precisa entender que a segurança do código aberto não é responsabilidade apenas dos grandes fornecedores, mas de todos nós — desenvolvedores, equipes de DevOps, mantenedores e usuários finais.
Conclusão: A confiança e a fragilidade do ecossistema open source
Este ataque demonstra como um único ponto de falha, como a conta de um mantenedor, pode colocar em risco milhões de projetos em todo o mundo. A combinação de credenciais comprometidas com a confiança implícita no ecossistema NPM cria o cenário perfeito para um ataque à cadeia de suprimentos.
É essencial adotar uma postura de “confiança zero” com relação às dependências. Devemos:
- Auditar regularmente nossas bibliotecas
- Utilizar ferramentas de detecção de anomalias
- Habilitar todas as medidas de segurança possíveis
- Tratar cada dependência como um possível vetor de ataque
A confiança é a base do código aberto — mas, como vimos, ela pode ser explorada. E cabe à comunidade aprender com esses eventos para fortalecer suas defesas.
