Ataque a pacotes NPM compromete mais de 430 bibliotecas e expõe credenciais de desenvolvedores
Um ataque direcionado ao ecossistema NPM colocou em risco milhares de projetos de software ao comprometer a conta de um mantenedor de pacotes amplamente utilizados. A invasão permitiu a inclusão de código malicioso em bibliotecas populares e desencadeou uma cadeia de infecções que afeta mais de 430 pacotes, com impacto potencial em milhões de desenvolvedores e empresas ao redor do mundo.
Segundo a análise divulgada por Ilyas Makari em 4 de agosto, o alvo inicial do ataque foi o pacote keyv, um dos mais usados no NPM, com cerca de 127 milhões de downloads por semana. A partir dele, o invasor conseguiu propagar o malware para 433 outros pacotes, que somados ultrapassam 2 bilhões de instalações mensais. Ou seja, trata-se de um incidente de grande escala, com potencial para atingir praticamente qualquer cadeia de supply chain que dependa desse ecossistema.
Como o ataque foi realizado
O invasor obteve acesso à conta de um mantenedor legítimo no NPM, o que lhe deu permissão para publicar novas versões de pacotes já consolidados e confiáveis. Em vez de criar bibliotecas novas e suspeitas, o atacante escolheu um vetor muito mais eficaz: inserir código malicioso em atualizações aparentemente normais de dependências amplamente utilizadas.
Esse código foi adicionado em versões específicas dessas bibliotecas, sem alterar significativamente seu funcionamento principal, o que dificultou a detecção imediata. Assim, qualquer desenvolvedor ou pipeline de CI/CD que fizesse o download ou atualização automática para essas versões comprometidas passava a executar o malware de forma transparente, sem qualquer alerta visível.
O que o malware faz
O programa malicioso foi projetado para roubar credenciais e segredos sensíveis do ambiente comprometido. Entre os alvos principais estão:
– Tokens de acesso a serviços como npm, GitHub, AWS e Kubernetes
– Arquivos de configuração de ferramentas e serviços
– Chaves privadas armazenadas na máquina da vítima
– Outras informações que possam permitir movimento lateral e novos acessos não autorizados
Ao obter esses dados, o atacante não apenas coleta informações, mas também se vale das credenciais capturadas para continuar a propagação do ataque, ampliando o impacto a cada nova máquina ou conta comprometida.
Propagação automática e efeito em cadeia
Um dos aspectos mais preocupantes desse incidente é a capacidade do malware de se espalhar automaticamente. Com as credenciais roubadas, o código malicioso:
– Publica novas versões infectadas de outros pacotes NPM
– Altera arquivos de configuração em repositórios GitHub comprometidos
– Ajusta dependências de projetos para apontar para versões maliciosas
– Possivelmente ajusta scripts de build ou deploy para manter a persistência
Com isso, qualquer usuário que confie nesses repositórios ou pacotes pode, sem perceber, importar uma versão contaminada e abrir as portas de seu ambiente de desenvolvimento, CI/CD ou até de produção para o invasor. Trata-se de um típico ataque à cadeia de suprimentos de software (software supply chain), em que o elo frágil é uma dependência amplamente confiada por milhares de projetos.
Exfiltração de dados: GitHub como canal de comunicação
As informações coletadas pelo malware não são enviadas diretamente para um servidor facilmente bloqueável. Em vez disso, os dados roubados são:
– Criptografados localmente
– Enviados para repositórios públicos no GitHub
Esse método reduz a chance de detecção por mecanismos tradicionais que monitoram conexões suspeitas com domínios maliciosos. Como os dados estão criptografados, eles se tornam ilegíveis para terceiros, mas permanecem acessíveis aos invasores, que conhecem a forma de decodificá-los. Além disso, foi identificado um domínio alternativo, registrado em maio de 2026, preparado como plano de contingência para o envio das informações caso o canal principal se tornasse inviável.
Principais pacotes afetados
Entre as bibliotecas comprometidas estão:
– keyv
– flat-cache
– file-entry-cache
– cacheable-request
– Outros pacotes relacionados da mesma família
Muitas dessas dependências são utilizadas de forma indireta em grandes aplicações, inclusive por empresas conhecidas como Deliveroo, Picsart e Qlik, o que amplifica o risco para organizações que, muitas vezes, nem sabem que sua infraestrutura depende desses componentes.
Por que esse tipo de ataque é tão perigoso
Ataques via pacotes NPM exploram um ponto sensível do desenvolvimento moderno: a confiança quase automática em bibliotecas de terceiros. Em pipelines de CI/CD, é comum:
– Atualizar dependências de forma automática ou sem revisão manual detalhada
– Confiar em pacotes populares apenas pela quantidade de downloads ou estrelas
– Não fixar versões (version pinning), permitindo que novas releases sejam adotadas sem inspeção
Isso cria um cenário perfeito para invasores: basta comprometer um único mantenedor influente para alcançar uma base gigantesca de vítimas, sem a necessidade de atacar cada organização individualmente. Além disso, ao roubar tokens de acesso, o atacante pode:
– Entrar em repositórios privados
– Modificar códigos internos
– Implantar backdoors em produtos finais
– Acessar ambientes de nuvem e orquestração (como AWS e Kubernetes)
Recomendações imediatas para equipes de desenvolvimento
A Aikido Security recomenda que todas as equipes de desenvolvimento façam uma varredura urgente em seus projetos para identificar:
1. Se algum dos pacotes listados como comprometidos está sendo utilizado
2. Quais são as versões específicas instaladas em cada projeto
3. Se houve atualizações recentes coincidentes com o período do ataque
A empresa destaca a importância de usar ferramentas que:
– Detectem pacotes maliciosos ou suspeitos
– Bloqueiem a instalação de bibliotecas comprometidas antes da execução do código
– Analise o histórico de dependências e log de builds para identificar possíveis pontos de infecção
Como mitigar o impacto nos seus projetos
Além da verificação pontual, é fundamental adotar práticas estruturais para reduzir o impacto desse tipo de ataque:
1. Fixar versões de dependências (version pinning)
– Em vez de usar intervalos abertos (como `^1.2.0`), definir versões exatas
– Revisar manualmente mudanças antes de atualizar para novas releases
2. Usar lockfiles e reprodutibilidade de builds
– Garantir que o mesmo conjunto de versões seja utilizado em todos os ambientes
– Permitir auditorias posteriores para saber exatamente quais versões estavam em uso em determinado momento
3. Auditorias regulares de dependências
– Rodar scanners de segurança focados em supply chain
– Revisar dependências transitivas, não apenas as diretas
4. Revisão de credenciais e tokens
– Revogar e regenerar tokens de npm, GitHub, AWS, Kubernetes e outras plataformas se houver qualquer suspeita
– Implementar rotação periódica de chaves e tokens como prática padrão
5. Segregação de privilégios
– Limitar o escopo dos tokens de acesso (princípio do menor privilégio)
– Evitar usar credenciais com permissão de escrita ampla em ambientes de build
Como saber se você já foi comprometido
Mesmo após corrigir dependências, é essencial verificar se o ambiente já não foi invadido. Alguns sinais e ações recomendadas:
– Revisar o histórico de publicações de pacotes em contas NPM e GitHub associadas à sua equipe
– Verificar se houve commits inesperados em repositórios, especialmente alterando arquivos de configuração, workflows de CI ou arquivos de dependência
– Conferir logs de acesso em provedores de nuvem e plataformas de repositório em busca de logins incomuns, horários suspeitos ou IPs desconhecidos
– Monitorar tráfego de saída em busca de padrões anômalos, mesmo quando mascarados como conexões legítimas
Se houver qualquer indicação de comprometimento, é recomendável:
– Isolar ambientes suspeitos
– Forçar rotação de credenciais em massa
– Realizar uma análise forense básica para entender o alcance da invasão
Estratégia de longo prazo: fortalecer a cadeia de supply chain
Esse incidente reforça que segurança de aplicações não se resume ao código próprio da empresa. É indispensável incluir a gestão de dependências como parte central da estratégia:
– Adotar uma política formal de uso de bibliotecas de terceiros
– Manter uma lista aprovada de pacotes considerados críticos ou sensíveis
– Exigir revisões de segurança para adoção de novos pacotes muito populares ou que tenham acesso a dados críticos
– Integrar ferramentas de monitoramento de vulnerabilidades e comportamentos suspeitos diretamente no pipeline de CI/CD
Empresas mais maduras em segurança já tratam o repositório de dependências como um ativo estratégico, mantendo mirrors internos, caches de pacotes revisados e até repositórios privados com versões “confiáveis” congeladas, reduzindo a exposição a ataques externos.
O que desenvolvedores individuais podem fazer
Mesmo quem trabalha em projetos menores ou como freelancer pode adotar medidas para se proteger:
– Desconfiar de atualizações repentinas em pacotes críticos sem necessidade funcional clara
– Ler notas de release e, quando possível, inspecionar mudanças em bibliotecas muito sensíveis
– Evitar armazenar chaves privadas e tokens sem criptografia em máquinas locais
– Utilizar gerenciadores de segredos em vez de arquivos `.env` espalhados e mal protegidos
Além disso, vale considerar a adoção de autenticação multifator (MFA) em contas de NPM, GitHub e serviços de nuvem, dificultando que um vazamento de senha ou token leve, por si só, à tomada completa de contas.
Conclusão: um alerta para todo o ecossistema
O ataque aos pacotes NPM como keyv, flat-cache, file-entry-cache, cacheable-request e dezenas de outros funciona como um lembrete contundente de que a superfície de ataque do desenvolvimento moderno vai muito além do código escrito internamente. Quando mais de 430 bibliotecas são comprometidas e somam bilhões de instalações mensais, qualquer organização que use JavaScript, Node.js ou ferramentas que dependam desse ecossistema precisa considerar que pode ter sido afetada.
A resposta adequada envolve não apenas corrigir versões e remover dependências maliciosas, mas também repensar processos, revisar credenciais e elevar o nível de segurança em toda a cadeia de desenvolvimento. Em um cenário de “pandemia” de fraudes digitais, ignorar o risco da supply chain é deixar a porta dos sistemas escancarada para o próximo ataque.