Mastra expõe a fragilidade da cadeia de fornecimento npm: 144 pacotes comprometidos e um postinstall que rouba segredos

Um grande ataque à cadeia de abastecimento comprometeu até 144 pacotes npm sob o espaço de nomes @mastra, explorando uma instalação massiva de versões maliciosas que adicionem uma dependência troceada chamada "easy-day-js". De acordo com a análise de vários equipamentos de resposta, o vetor não foi código obviamente malicioso dentro de cada pacote, mas uma cadeia de instalação: a biblioteca falsa é executada em um hook postinstall, baixe um carregador que desactiva a validação TLS, recupera um segundo estádio de um servidor controlado pelos atacantes e exibe um stealer multiplataforma capaz de exfiltrar histórico de navegador, dados de extensões de carteiras de criptomoedas e persistir no Windows, macOS e Linux.

O atacante aproveitou o compromisso de uma conta legítima do ecossistema para publicar, em minutos, mais de 140 versões maliciosas dentro do scope de Mastra, aproveitando que a política do projeto permitia publicar com um token pessoal sem exigir as atestações de procedência (SLSA) geradas pelo CI. Isso demonstra a diferença prática entre gerar provas de integridade na CI e exigir-lhes como requisito de publicação: se a verificação de assinaturas ou de atestações tivesse sido obrigatória, as versões teriam sido automaticamente rejeitadas.

As implicações são críticas: pacotes populares como @mastra/core(com centenas de milhares de downloads semanais) amplificam o impacto, e uma vez que o payload é executado durante a instalação, uma simples execução de npm install em um desenvolvimento local ou no runners da CI pode comprometer segredos antes mesmo de o desenvolvedor importar a livraria no seu código. Além do roubo de chaves, a capacidade do malware para remover impressões e operar em background dificulta a detecção forense.

Se a sua organização usa @mastra/* ou executou instalações recentemente, tente cada host, runner e ambiente de build como potencialmente comprometido. Entre as ações imediatas a considerar estão: reverter versões verificadas ou commits de confiança; revogar e rodar todos os tokens e credenciais que poderiam ter sido usados por runners ou desenvolvedores; revogar tokens pessoais e reemitir com políticas mais restritivas; e reconstruir imagens e runners desde origens imutáveis. Também é imprescindível auditar sistemas em busca de sinais de execução do postinstall: processos filhos lançados a partir de pastas de node_modules, entradas de persistência (serviços systemd, launchd, tarefas programadas, chaves Run no Windows), e conexões para endereços IP observados pelos pesquisadores (para a campanha foram apontados servidores C2 conhecidos que convém verificar).

Em termos de mitigação a médio e longo prazo, as lições são claras: exigir atestações de procedência e assinatura de pacotes, limitar e controlar tokens NPM com permissões mínimas, usar políticas que verifiquem assinaturas durante a instalação e promover installations reprodutíveis e auditadas. Integrar SBOMs em pipelines, restringir instalações em runners não isolados e centralizar as dependências aprovadas em um proxy privado reduz a superfície de ataque. Implementar controlos de egress e monitorização de tráfego a partir de runners e desenvolvedores ajuda a detectar choques suspeitos no momento em que ocorrem.

Para quem gere projetos de código aberto, a recomendação é rever o processo de gestão de colaboradores e descopes: revogar acessos a contribuintes que já não participam, forçar a publicação de fluxos de CI com atestações SLSA e auditar tokens pessoais regularmente. As boas práticas de supply chain – como exigir SLSA, assinar artefatos e adotar políticas de verificação na instalação – já não são opcionais se se quiser manter confiança em dependências externas.

Se precisar de orientação técnica sobre como exigir atestações e assinaturas em seu fluxo de trabalho, a especificação SLSA e as recomendações de segurança na cadeia de fornecimento são recursos úteis: veja a documentação da SLSA em https://slsa.dev/ e o guia de boas práticas da comunidade sobre segurança da cadeia de abastecimento https://owasp.org/www-project-supply-chain-security/. Para orientação específica sobre as políticas e práticas de segurança do npm consulte https://docs.npmjs.com/about-security.

Em suma, o incidente que afeta o @mastra/* destaca a fragilidade da confiança implícita no ecossistema de pacotes: proteger-se requer combinar controles técnicos (firmas, atestações, isolamento de runners) com governança (gestão de acessos e tokens). Atúe rapidamente para conter exposição, audite exaustivamente ambientes afetados e evolucione suas pipelines para que um único token comprometido não possa voltar a causar uma liberação maciça de código malicioso.