Os fornecedores "escondidos" em seu código: o caso Keyv/NPM e o risco de terceiros

Em 4 de agosto de 2026, atacantes comprometeram a conta no GitHub do desenvolvedor responsável pelo keyv, uma biblioteca JavaScript de código aberto muito usada, e a usaram para injetar código malicioso no keyv e em uma família de pacotes de caching relacionados. Só o keyv é baixado cerca de 127 milhões de vezes por semana, então o alcance do estrago foi imediato.

Não houve exploração de nenhuma falha no npm. Os atacantes se aproveitaram de uma conta de mantenedor confiável e do próprio fluxo de publicação do projeto, e foi assim que as versões contaminadas saíram com assinaturas válidas e aparência totalmente legítima. Quem instalou ou atualizou um pacote afetado executou o código malicioso automaticamente, ainda durante a instalação, antes mesmo de usar a biblioteca.

O payload é um worm autorreplicante que os pesquisadores associam à família Shai-Hulud. Ele coleta credenciais da máquina em que cai (tokens de npm e GitHub, chaves da AWS, chaves SSH, segredos de CI/CD), criptografa tudo e envia para repositórios no GitHub controlados pelos atacantes, cuja descrição traz a frase "Shai-Hulud: Here We Go Again". Em seguida, se espalha para outros pacotes que a vítima tem permissão de publicar. Em poucas horas, já havia atingido centenas de pacotes em várias organizações, somando mais de 2 bilhões de instalações por mês, e continuava crescendo.

Por que isso é um problema de terceiros

Ninguém clicou em link de phishing. Nenhum firewall foi burlado. Um desenvolvedor apenas instalou uma atualização de rotina e herdou o comprometimento de outra pessoa, escondido dentro de uma dependência em que a empresa confiava havia anos e que, na maioria das vezes, nunca chegou a escolher de forma consciente.

E é aqui que vale parar para pensar. Dá para ter um programa de segurança interno maduro e, mesmo assim, ficar exposto porque um componente três camadas abaixo no seu build foi contaminado lá na origem. O código aberto sobre o qual seus produtos são construídos se comporta como qualquer outro fornecedor: está dentro do seu perímetro, mas a segurança dele não depende de você.

Assinatura e proveniência não evitaram nada disso. Elas confirmam de onde veio o pacote, não se o código dentro dele é seguro. Quando a própria conta de origem está comprometida, até uma versão perfeitamente assinada entrega malware.

O que realmente ajuda

Quando um incidente desses é divulgado oficialmente, o estrago quase sempre já está feito. O próprio mantenedor não sabia que sua conta havia sido comprometida até o worm já estar se espalhando. A defesa precisa ser contínua, e não reativa: saber quais componentes de código aberto rodam nas suas aplicações, acompanhar as exposições ligadas a eles e conseguir cruzar um incidente público com o seu próprio ambiente rapidamente.

É exatamente essa lacuna que os módulos de CTI e TPCRM do QuimeraX foram feitos para fechar: identificar exposições que nascem fora do seu perímetro e conectá-las à sua cadeia de risco com tempo suficiente para agir.

Porque, seja o elo fraco um fornecedor, um parceiro ou um único pacote de código aberto, o resultado é o mesmo. O risco da sua cadeia de suprimentos sempre foi o seu risco também.

Para apoiar organizações na avaliação de sua exposição, a equipe de Threat Intelligence da QuimeraX publicou um relatório completo de CTI sobre a campanha Shai-Hulud. O relatório apresenta uma análise técnica detalhada do ataque, incluindo os pacotes afetados, indicadores de comprometimento (IOCs), infraestrutura utilizada pelos atacantes, avaliação de impacto e recomendações práticas de mitigação e detecção.

Leia o relatório completo de CTI.

Quer saber quanto da sua exposição começa fora do seu próprio perímetro? Fale com o time do QuimeraX.

Referências

QuimeraX. keyv 6.0.0 Compromised With an Install Hook and an IDE Auto-Run Hook - Real-time Open Source Software Supply Chain Security. Publicado em 4 de agosto de 2026.
Disponível em: news.quimerax.com/news/97fb3f1c-0c0b-4327-87b7-08f637ab5d7e