Como o grupo Sapphire Sleet comprometeu 145 pacotes da Mastra no npm — e o que muda com a resposta da Microsoft

Juntos, os pacotes afetados registravam mais de 1,1 milhão de downloads por semana . O episódio expôs como uma única conta de mantenedor pode se transformar em um ponto de entrada para atingir milhares de ambientes de desenvolvimento, pipelines de CI/CD e sistemas em nuvem.

Como o ataque aconteceu

A operação combinou engenharia social, publicação automatizada e uma dependência com nome semelhante ao de uma biblioteca legítima. O objetivo era fazer com que o código malicioso fosse executado antes mesmo de o desenvolvedor rodar sua aplicação.

1. Sequestro da conta de um mantenedor

Os invasores primeiro comprometeram, por meio de engenharia social, as credenciais de um mantenedor legítimo da Mastra . A conta, identificada como ehindero, tinha permissão para publicar pacotes em todo o escopo @mastra .

Esse nível de acesso foi decisivo: em vez de invadir cada projeto individualmente, os criminosos precisaram controlar apenas uma conta confiável para alterar numerosos pacotes de uma só vez.

2. Publicação em massa em poucos minutos

Com a conta sob controle, os atacantes republicaram os pacotes do namespace @mastra/* em uma janela de cerca de 88 minutos. Alguns relatos indicam que a maior parte da publicação ocorreu em apenas 19 minutos . A velocidade é compatível com o uso de um script automatizado para distribuir as versões adulteradas.

3. Inclusão da dependência falsa easy-day-js

As versões comprometidas receberam uma dependência maliciosa chamada easy-day-js, um typosquat — nome criado para se parecer com o de uma biblioteca conhecida — de dayjs, uma biblioteca legítima de datas amplamente utilizada . Por causa da semelhança, um desenvolvedor poderia não perceber o componente suspeito ao revisar as dependências.

A campanha passou a ser identificada por pesquisadores como “easy-day-js” .

4. Execução automática durante a instalação

O código malicioso era acionado por meio do script postinstall do npm. Assim, bastava executar npm install de um pacote afetado para disparar o payload; não era necessário iniciar a aplicação nem executar uma função específica do Mastra .

Esse comportamento é particularmente perigoso em ambientes de desenvolvimento e automação, onde a instalação de dependências costuma ocorrer automaticamente durante builds e implantações.

5. Roubo de credenciais e ativos digitais

Depois de executado, o payload procurava chaves de carteiras de criptomoedas, credenciais de serviços de nuvem e segredos usados em sistemas de CI/CD, como pipelines de compilação, testes e publicação . O código também desativava a verificação de TLS e baixava um ladrão de informações de segundo estágio a partir de uma infraestrutura controlada pelos atacantes .

Microsoft atribui o ataque ao Sapphire Sleet

Em 19 de junho de 2026, a Microsoft afirmou, com alto grau de confiança, que a operação foi conduzida pelo Sapphire Sleet, um ator estatal norte-coreano que tem como foco principal os setores financeiro e de criptomoedas .

A avaliação considerou a infraestrutura utilizada e os padrões de comportamento, técnicas e procedimentos — conhecidos pela sigla TTPs — observados após o comprometimento. A Amazon Threat Intelligence também relacionou o grupo a campanhas anteriores contra pacotes do npm, incluindo axios, debug, chalk e typo-crypto .

O que mudou na segurança do ecossistema

O incidente da Mastra ocorreu no npm, mas ajudou a reforçar uma mudança mais ampla: reduzir a dependência de credenciais de publicação que permanecem válidas por meses ou anos. A Microsoft anunciou medidas específicas para o NuGet, seu repositório de pacotes para o ecossistema .NET, e recomendou uma forma mais segura de autenticação.

Chaves de API do NuGet passam a durar no máximo 30 dias

A partir de 17 de agosto de 2026, novas chaves de API do NuGet.org terão validade máxima de 30 dias, em vez de até 365 dias . Todas as chaves criadas antes dessa data serão expiradas em 1º de novembro de 2026 .

A lógica é limitar o período em que uma credencial roubada pode ser explorada. Uma chave de longa duração pode permitir que um invasor publique versões adulteradas de pacotes confiáveis por um período prolongado — exatamente o tipo de risco evidenciado pelo caso Mastra e pelo comprometimento recente do pacote NX Console .

Trusted Publishing substitui segredos permanentes

A Microsoft recomenda que os mantenedores migrem para o Trusted Publishing, fluxo lançado em setembro de 2025 que usa o padrão OpenID Connect (OIDC) para substituir chaves de API de longa duração .

Entre os principais benefícios estão :

• nenhum segredo permanente armazenado no repositório ou no sistema de CI/CD;
• credenciais temporárias, emitidas a cada publicação e normalmente válidas por cerca de uma hora;
• validação da identidade do workload, considerando o repositório, o workflow e, quando configurado, o ambiente autorizado;
• fim da rotação manual de segredos; e
• redução significativa do impacto caso uma credencial seja exposta.

Em um workflow com Trusted Publishing, o sistema de CI/CD — por exemplo, o GitHub Actions — solicita um token OIDC assinado criptograficamente. O NuGet.org valida as informações do token em relação à política do publicador e fornece uma chave temporária, de uso único, válida apenas para aquela sessão de publicação .

Medidas adicionais adotadas pelo npm

O próprio ecossistema npm também vem restringindo credenciais persistentes:

• Tokens clássicos foram revogados: em dezembro de 2025, o npm revogou permanentemente todos os tokens clássicos de longa duração. O comando npm login passou a emitir tokens de sessão válidos por duas horas .

• Tokens granulares têm prazo limitado: novos tokens granulares com permissão de escrita passaram a ter validade padrão de sete dias e máxima de 90 dias .

• Publicação em etapas ganhou disponibilidade geral: o recurso staged publishing exige que um mantenedor aprove explicitamente uma versão usando autenticação de dois fatores antes de ela ficar disponível para instalação pública .

Em conjunto, essas mudanças tentam bloquear o caminho explorado pelo Sapphire Sleet: uma única credencial de publicação, de longa duração e com proteção insuficiente, capaz de alterar todo um escopo de pacotes.

O que desenvolvedores e mantenedores devem fazer

• Revise as chaves do NuGet imediatamente. Chaves criadas antes de 17 de agosto de 2026 expirarão em 1º de novembro. Gere novas credenciais ou planeje a migração para o Trusted Publishing antes do prazo .

• Prefira Trusted Publishing em pipelines de CI/CD. A autenticação baseada em OIDC elimina a necessidade de manter segredos de longa duração em arquivos, repositórios e sistemas de automação. O modelo é compatível com NuGet.org, npm e PyPI .

• Audite os fluxos de publicação do npm. Verifique se os pipelines usam sessões temporárias, tokens granulares com prazo limitado ou Trusted Publishing, em vez de credenciais antigas e persistentes .

• Fixe versões de dependências críticas. Usar versões conhecidas e validadas reduz o risco de instalar automaticamente uma atualização comprometida .

• Considere desativar scripts automáticos durante a instalação. O comando npm install --ignore-scripts, ou a configuração global ignore-scripts = true, impede a execução automática de scripts preinstall e postinstall. A medida deve ser avaliada de acordo com as necessidades do projeto, já que algumas dependências legítimas dependem desses scripts .

O caso Mastra mostra que a segurança da cadeia de software não depende apenas de examinar o código da aplicação. A conta que publica uma dependência, a forma como o pipeline se autentica e o que acontece durante um simples npm install podem ser tão importantes quanto o código que o time escreveu.