Uma conta esquecida de colaborador comprometeu todo o escopo de pacotes npm da Mastra

Em 17 de junho de 2026, um invasor republicou todo o escopo npm @mastra, inserindo uma única dependência maliciosa em 143 pacotes — e esse número continua crescendo. Entre eles está @mastra/core, que recebe cerca de 4 milhões de downloads por mês e é usado por centenas de projetos dependentes. A dependência injetada, easy-day-js, imita o dayjs. Seu script de instalação desativa a verificação de TLS, baixa uma carga maliciosa de segundo estágio de um endereço IP direto e executa em segundo plano um ladrão de criptomoedas multiplataforma. O ataque a esse pacote npm foi possível porque o acesso ao escopo de uma conta de um ex-colaborador nunca foi revogado.

Atenção: se você instalou algum pacote @mastra, ou algo que dependa de um deles, em uma árvore de dependências nova ou atualizada em 17 de junho de 2026 ou depois, considere isso um incidente de exposição de credenciais e carteiras e continue lendo.

ATUALIZAÇÃO: a Snyk adicionou um novo pacote comprometido: @mastra/node-speaker, versão 0.1.1.

Em resumo

• Incidente: tomada do escopo npm @mastra, com republicação em massa e injeção de uma dependência maliciosa

• Dependência maliciosa: easy-day-js@1.11.22 (um impostor do dayjs que atua como dropper)

• Alerta da Snyk: SNYK-JS-EASYDAYJS-17353313, código malicioso incorporado, afeta easy-day-js 1.11.21 e 1.11.22

• Pacotes afetados: praticamente todo o escopo @mastra, republicado em 17 de junho de 2026; a correção da própria Mastra abrange 142 pacotes publicáveis

• Versões de destaque: @mastra/core@1.42.1, mastra@1.13.1, create-mastra@1.13.1

• CVE / CVSS: nenhum atribuído; trata-se de um incidente ativo na cadeia de suprimentos, e o código-fonte da Mastra não foi modificado

• Carga maliciosa: ladrão de carteiras de criptomoedas multiplataforma e trojan de acesso remoto com persistência

• Status: easy-day-js foi removido do npm, ehindero não é mais proprietário do escopo, e a Mastra lançou versões limpas posteriores (PR #18056). A versão mais recente de @mastra/core latest voltou para a versão limpa 1.42.0. Considere qualquer versão comprometida que você já tenha resolvido como um incidente de exposição do host.

Como o ataque aconteceu

O ponto de entrada foi uma credencial antiga de mantenedor. O escopo @mastra era publicado pela conta npm ehindero, de um ex-colaborador real da Mastra. O histórico de publicações do registro npm mostra lançamentos alfa legítimos de @mastra/core feitos por essa conta no fim de 2024 e no início de 2025. Depois disso, ela ficou inativa, mas seu acesso ao escopo nunca foi revogado.

Há indícios de que a conta foi tomada por terceiros, e não de uma ação interna. Entre eles está a alteração do e-mail, que deixou de ser o endereço original do colaborador e passou a ser ehindero2016@tutamail[.]com. Vale refletir sobre como isso foi possível: o npm não expira permissões de publicação em escopos por inatividade. Assim, uma única credencial antiga de mantenedor bastou para publicar em todos os pacotes do escopo. A causa raiz foi a falta de cuidados básicos com o projeto, não uma vulnerabilidade de dia zero.

O vetor: uma linha em cada package.json

O invasor não alterou o código-fonte da Mastra. O código malicioso foi inserido nos arquivos tar publicados no momento da publicação, e a própria PR de correção da Mastra confirma que o repositório foi verificado e não continha easy-day-js em nenhum package.json ou arquivo de lock (PR #18056). Cada versão maliciosa publicada no npm acrescentou exatamente uma linha ao package.json publicado:

"easy-day-js": "^1.11.21"

A dependência nunca é importada no código-fonte da Mastra. Sua única função é introduzir um trojan durante a instalação. O truque está no intervalo indicado pelo circunflexo. Primeiro, o invasor publicou uma versão limpa de easy-day-js@1.11.21 em 16 de junho, um impostor idêntico byte a byte ao dayjs, até mesmo no arquivo incluído dayjs.min.js e na descrição do pacote. No dia seguinte, publicou easy-day-js@1.11.22 com o malware e a marcou como latest. Como 1.11.22 satisfaz ^1.11.21, uma execução normal de npm install resolve diretamente para a versão armada.

Em seguida, numa onda em 17 de junho de 2026, o invasor republicou o restante do escopo, com a mesma dependência injetada em cada pacote. A correção da própria Mastra identifica com precisão a extensão do impacto: o changeset de emergência avança 142 pacotes publicáveis do escopo @mastra/*, além de mastra, create-mastra e mastracode (PR #18056). As informações públicas variam de 80 a 144 pacotes, dependendo do momento considerado. Porém, a estimativa do próprio fornecedor é a referência mais confiável, e a conclusão é a mesma: praticamente todo o escopo foi afetado.

Em alguns pacotes, o invasor chegou a publicar versões superiores à versão legítima latest (por exemplo, @mastra/schema-compat@1.2.12, @mastra/react@1.0.1, @mastra/voice-playai@0.12.2). Isso obrigou a Mastra a fixar versões explicitamente mais altas, em vez de usar simples atualizações de patch para substituí-las (PR #18060).

O dropper do malware: desativar o TLS, baixar, executar em segundo plano e apagar

easy-day-js@1.11.22 inclui um setup.cjs que é executado como um hook de postinstall. Durante a instalação, ele:

1. Desativa a validação de certificados TLS definindo NODE_TLS_REJECT_UNAUTHORIZED='0', permitindo que uma solicitação HTTPS seja concluída mesmo com um certificado autoassinado em um IP direto.

2. Cria arquivos marcadores (~/.pkg_history, ~/.pkg_logs) para rastrear as instalações.

3. Baixa uma carga maliciosa de segundo estágio de https://23.254.164[.]92:8000/update/49890878 (hospedado na Hostwinds).

4. Grava o arquivo no diretório temporário e o inicia como um processo oculto e separado em segundo plano, sem saída no console.

5. Apaga a si mesmo para reduzir os vestígios forenses.

A carga maliciosa: ladrão de criptomoedas multiplataforma e RAT

O segundo estágio (SHA256 221c45a790dec2a296af57969e1165a16f8f49733aeab64c0bbd768d9943badf) é um ladrão de carteiras de criptomoedas ofuscado, da mesma categoria de cargas maliciosas que a Snyk já identificou em outros ataques ao npm. Ele examina os perfis do Chrome, Brave e Edge em busca de uma lista codificada de extensões de navegador para carteiras de criptomoedas, incluindo MetaMask, Phantom, Solflare, Coinbase Wallet, OKX e Keplr. Além dos dados das carteiras, coleta nome de usuário, nome do host, sistema operacional e arquitetura, versão do Node, aplicativos instalados, histórico do navegador e lista de processos em execução. Depois, codifica tudo em Base64 e inclui os dados em um beacon JSON.

Ele também estabelece persistência disfarçado de ferramenta do Node e envia sinais para um C2 de RAT separado (23.254.164[.]123/49890878) aproximadamente a cada 10 minutos, usando um certificado de teste autoassinado do wolfSSL (CN=www.wolfssl.com, expirado em janeiro de 2018):

• macOS: LaunchAgent em ~/Library/LaunchAgents/com.nvm.protocal.plist

• Linux: serviço de usuário systemd ~/.config/systemd/user/nvmconf.service

• Windows: execução do PowerShell preparada em C:\ProgramData\NodePackages

A dependência inicialmente limpa e depois armada, o dropper de postinstall setup, o download de um IP direto com desvio do TLS e a carga de roubo de criptomoedas são muito semelhantes ao comprometimento do pacote Axios no npm, analisado pela Snyk no início de 2026. A semelhança inclui o dropper executado durante a instalação que se apaga. A Microsoft Threat Intelligence atribuiu aquela campanha anterior ao agente que rastreia como Sapphire Sleet (BlueNoroff). A atribuição deste incidente especificamente não foi confirmada, e não faremos especulações; esse padrão merece atenção dos responsáveis pela defesa, mas não deve ser tratado como fato comprovado.

Análise do impacto

Só @mastra/core recebe cerca de 4 milhões de downloads por mês (registro do npm) e é usado por centenas de projetos dependentes; mastra acrescenta cerca de 1,5 milhão de downloads (registro do npm). Como 142 pacotes do escopo foram republicados, o volume agregado de downloads mensais chega a dezenas de milhões, o que significa que o potencial de impacto é amplo.

A exposição prática é mais restrita do que esse número sugere, e vale ser preciso. Você só está em risco se uma máquina de build ou de desenvolvimento resolveu uma das versões maliciosas durante o período de exposição. Os arquivos de lock são decisivos e representam uma forma segura e reproduzível de gerenciar dependências em projetos npm:

• Fixada por um arquivo de lock versionado em uma versão anterior ao incidente: um npm ci não teria instalado a versão maliciosa. Provavelmente você está em segurança, mas confirme.

• Sem arquivo de lock, usando um intervalo amplo ou fazendo uma instalação nova/regenerando o arquivo de lock em 17 de junho ou depois: o intervalo com circunflexo teria resolvido para a versão armada easy-day-js@1.11.22, e o hook de postinstall teria sido executado.

Como a carga maliciosa é executada durante a instalação, runners de CI, agentes de build temporários e laptops de desenvolvedores também estão em risco, não apenas servidores de produção. Qualquer um desses hosts pode ter exposto credenciais e carteiras.

Detecção: você foi afetado?

1. Verifique se easy-day-js já esteve na sua árvore de dependências. Não há motivo legítimo para ele estar lá:

npm ls easy-day-js

grep -r "easy-day-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

2. Audite as @mastra que foram resolvidas. As versões comprometidas foram publicadas em 17 de junho de 2026 e não têm proveniência SLSA. Verifique o que foi realmente fixado no arquivo de lock:

npm ls @mastra/core mastra create-mastra

3. Faça uma varredura com a Snyk. A Snyk sinaliza o pacote malicioso como SNYK-JS-EASYDAYJS-17353313 (código malicioso incorporado):

snyk test

snyk monitor

4. Procure artefatos nos hosts em qualquer máquina que tenha executado uma instalação durante o período:

#Dropper markers

ls -la ~/.pkg_history ~/.pkg_logs 2>/dev/null

#Persistence

ls -la ~/Library/LaunchAgents/com.nvm.protocal.plist 2>/dev/null      # macOS

ls -la ~/.config/systemd/user/nvmconf.service 2>/dev/null             # Linux

dir "C:\ProgramData\NodePackages"                                      # Windows

5. Verifique os logs de tráfego de saída em busca de conexões com 23.254.164[.]92:8000, 23.254.164[.]123 ou qualquer endereço em 23.254.164.0/24.

Para ver na prática como identificar e corrigir com a Snyk um comprometimento desse tipo que afeta todo um escopo npm, esta demonstração de correção apresenta o processo completo:

Play Video: Shai-Hulud NPM Attack: Remediation with Snyk

Ataque Shai-Hulud ao NPM: correção com a Snyk (um fluxo prático de correção para um ataque à cadeia de suprimentos do npm com republicação em massa).

Correção

Se easy-day-js não estiver presente e o arquivo de lock tiver fixado versões de @mastra anteriores ao incidente: confirme seguindo as etapas de detecção acima, mantenha as versões fixadas no arquivo de lock e siga em frente.

Se você resolveu uma versão maliciosa, considere comprometido qualquer host afetado.

1. Atualize para uma versão limpa; não basta fixar uma versão anterior. A Mastra lançou versões limpas posteriores para todos os 142 pacotes publicáveis e moveu a etiqueta de distribuição latest para além das versões comprometidas (PR #18056, PR #18049), em vez de depender da remoção dos pacotes. Atualize para a versão limpa atual (por exemplo, @mastra/core@1.42.0 ou posterior), gere um arquivo de lock limpo e remova qualquer vestígio de easy-day-js. Como o invasor publicou algumas versões acima da latest legítima, confirme que a versão escolhida é uma versão confiável da Mastra, e não uma versão maliciosa que permaneceu no registro.

2. Altere todas as credenciais às quais o host poderia ter acesso: chaves de nuvem, segredos e tokens de CI, chaves de API de LLMs e outros serviços, tokens npm e chaves SSH. Como a Mastra é um framework de agentes, é especialmente provável que houvesse chaves de provedores de LLMs.

3. Transfira seus criptoativos: se o perfil do navegador na máquina continha uma extensão de carteira visada, considere expostas a frase-semente e as chaves e transfira os fundos para uma carteira nova usando um dispositivo limpo.

4. Remova os mecanismos de persistência: exclua o LaunchAgent, a unidade systemd ou os arquivos preparados em C:\ProgramData\NodePackages, encerre o processo separado e remova os arquivos marcadores do dropper.

5. Se possível, reinstale o sistema do zero. Quando um RAT já estabeleceu persistência, reconstruir o ambiente do zero é a opção mais segura.

Para reduzir a exposição a esse tipo de ataque no futuro:

• Desative os scripts de instalação por padrão com npm config set ignore-scripts true e permita-os apenas quando forem realmente necessários para uma compilação. Isso neutraliza os droppers de postinstall e é uma das práticas recomendadas de segurança para npm da Snyk.

• Faça commit dos arquivos de lock e use npm ci na CI para garantir compilações reproduzíveis e impedir que uma alteração na tag latest provoque uma nova resolução silenciosa de dependências.

• Exija proveniência. A Mastra gerava proveniência SLSA nas publicações da CI, mas isso não era obrigatório. Assim, um token comum ainda podia publicar sem atestados. A mesma brecha permitiu o envio de versões maliciosas no comprometimento do pacote Nx; exigir proveniência no consumo eleva o nível de segurança.

• Fique de olho em dependências fantasma. Um pacote maduro e amplamente utilizado que de repente ganha uma única dependência não utilizada é exatamente o sinal observado aqui. A priorização baseada em risco e a descoberta de ativos em todo o seu ambiente ajudam você a identificar onde um pacote afetado foi instalado e quais instâncias estão acessíveis e têm credenciais, para que você corrija primeiro os hosts expostos, em vez de rastrear todas as instalações do escopo de uma só vez.

Conteúdos relacionados da Snyk

Este é o caso mais recente de uma série de invasões de escopos npm e contas de mantenedores em 2026. O padrão — uma conta de mantenedor comprometida que dispara uma republicação automatizada e rápida — é o mesmo por trás das campanhas Mini Shai-Hulud: 

Play Video: Mini Shai-Hulud: The Most Sophisticated NPM Supply Chain Attack of 2026

Mini Shai-Hulud: o ataque à cadeia de suprimentos do NPM mais sofisticado de 2026 (um passo a passo de como uma única conta de mantenedor comprometida é usada para inserir cavalos de Troia em centenas de pacotes npm de uma só vez, e como detectar e corrigir a exposição).

Para saber mais sobre essa mesma família de ataques e as estratégias de defesa, confira a cobertura da Snyk sobre o comprometimento do npm Axios, o ataque Mini Shai-Hulud ao AntV e ao TanStack, o worm auto propagável node-gyp e os comprometimentos do tinycolor e do ngx-bootstrap. Para aprender a proteger seu pipeline de instalação, consulte Segurança do NPM: como prevenir ataques à cadeia de suprimentos e a lição da Snyk Learn sobre o comprometimento de um pacote legítimo.

Linha do tempo

• Do fim de 2024 ao início de 2025: a conta ehindero publica versões alfa legítimas de @mastra/core e, depois, fica inativa. O acesso ao escopo nunca é revogado.

• 16 de junho de 2026: uma versão limpa de easy-day-js@1.11.21 é publicada como disfarce, imitando o dayjs.

• 17 de junho de 2026, ~01:01 UTC: a versão maliciosa easy-day-js@1.11.22 é publicada e recebe a tag latest.

• 17 de junho de 2026, ~01:12 a 02:36 UTC: a maior parte do escopo @mastra/* é republicada com a dependência easy-day-js injetada.

• 17 de junho de 2026: várias empresas de segurança divulgam o incidente publicamente; easy-day-js é removido do npm e as versões maliciosas são sinalizadas (aviso da Snyk SNYK-JS-EASYDAYJS-17353313).

• 17 de junho de 2026 (no mesmo dia): a Mastra responde removendo o proprietário não autorizado, abrindo alterações de emergência para publicações limpas (PR #18049), publicando versões atualizadas de todos os 142 pacotes publicáveis (PR #18056) e fixando versões superiores explícitas nos casos em que o invasor publicou acima da latest (PR #18060).