Ataque easy-day-js compromete 144 pacotes npm do ecossistema Mastra para IA

Conta de colaborador legítimo publicou mais de 140 versões maliciosas que puxam um stealer de criptomoedas via dependência clonada de dayjs durante o postinstall

Componente	144 pacotes npm no escopo @mastra/*, incluindo @mastra/core (~918 mil downloads semanais), mais a dependência maliciosa easy-day-js publicada por sergey2016
Vetor	Sequestro da conta npm ehindero (ex-colaborador com acesso ao escopo não revogado); publicação em massa de versões sem atestação SLSA; execução de payload ofuscado no hook postinstall ao resolver a dependência easy-day-js
Impacto	Instalação dispara dropper que baixa segundo estágio de IP 23.254.164[.]92 com validação TLS desabilitada, executa stealer multiplataforma (Windows, macOS, Linux) que coleta histórico de navegador, dados de mais de 160 extensões de carteiras cripto e exfiltra para C2 em 23.254.164[.]123; estáções de trabalho e runners de CI que instalaram versões afetadas devem ser tratados como potencialmente comprometidos
Prioridade	Reverter para versão segura conhecida, rotacionar credenciais expostas em ambientes de build, auditar hosts por artefatos da campanha e exigir instalação com verificação de assinaturas ou política que obrigue atestação de proveniência npm
Artefatos	Pacote easy-day-js (clone funcional de dayjs), contas npm ehindero e sergey2016, infraestrutura 23.254.164[.]92 e 23.254.164[.]123, campanha denominada easy-day-js
Versões	easy-day-js publicado em 16/06/2026 07:05 UTC como cópia limpa; alterações maliciosas inseridas em 17/06/2026 01:01 UTC; onda de publicações maliciosas no escopo Mastra em 17/06/2026
Mitigação	npm removeu versões maliciosas dos pacotes de maior visibilidade e reverteu a tag latest; releases legítimos do Mastra usam trusted publisher com atestação SLSA via CI — versões sem proveniência deveriam ser rejeitadas por política de assinatura

Resumo técnico

Uma campanha de cadeia de suprimentos identificada como easy-day-js comprometeu cerca de 144 pacotes npm associados ao namespace @mastra/*, framework open source em JavaScript e TypeScript voltado à construção de aplicações de inteligência artificial. A operação não embutiu código malicioso diretamente nos pacotes Mastra: em vez disso, injetou a biblioteca de terceiros easy-day-js na lista de dependências de cada artefato afetado, explorando o fluxo normal de resolução e instalação do npm para executar código hostil antes mesmo de qualquer importação ou uso da biblioteca principal.

A publicação maliciosa partiu da conta npm ehindero, ex-colaborador legítimo do projeto Mastra cujo acesso ao escopo nunca foi revogado. Em uma janela curta no dia 17 de junho de 2026, essa conta publicou em massa mais de 140 pacotes maliciosos abrangendo o escopo Mastra. O registro npm posteriormente removeu versões maliciosas dos pacotes de maior perfil e reverteu a tag latest desses artefatos. Entre os afetados está @mastra/core, que registra mais de 918 mil downloads semanais, ampliando significativamente o raio de exposição potencial da campanha.

Fluxo técnico

O pacote easy-day-js foi publicado pelo usuário npm sergey2016 em 16 de junho de 2026, às 07:05 UTC, inicialmente como um clone limpo e funcional da biblioteca de datas dayjs. Aproximadamente dezoito horas depois, em 17 de junho de 2026 às 01:01 UTC, uma nova versão introduziu alterações maliciosas. Quando qualquer pacote Mastra comprometido é instalado, o gerenciador de pacotes resolve e baixa easy-day-js como dependência transitiva; durante o hook postinstall dessa biblioteca, um payload ofuscado é disparado.

Esse primeiro estágio funciona como dropper ou loader: desabilita a validação de certificados TLS, recupera um payload de segundo estágio a partir de infraestrutura controlada pelo atacante no endereço 23.254.164[.]92, executa o binário resultante como processo em segundo plano desacoplado e, em seguida, remove vestígios do loader para reduzir a trilha forense. O estágio final é um coletor de informações multiplataforma capaz de operar em Windows, macOS e Linux, instalar mecanismos de persistência, extrair histórico de navegadores, capturar dados de mais de 160 extensões de navegador associadas a carteiras de criptomoedas e enviar o material coletado para um servidor de comando e controle em 23.254.164[.]123.

A estratégia de dependência transitiva distingue está campanha de injeções diretas de código nos pacotes Mastra: desenvolvedores e pipelines que apenas atualizam dependências ou executam instalações limpas podem ser afetados sem alterar uma linha de código própria. Como a execução ocorre na fase de instalação, a exposição precede qualquer uso consciente do framework, incluindo ambientes de integração contínua que rodam npm install ou equivalentes de forma automatizada.

Superficie afetada

O escopo completo @mastra/* foi atingido de forma coordenada, com a mesma impressão digital técnica repetida em todos os pacotes comprometidos da onda. Organizações que constroem ou implantam aplicações de IA sobre Mastra, bem como qualquer projeto que transitivamente dependa de pacotes do namespace, ficam dentro da superfície de risco enquanto versões maliciosas permanecerem em lockfiles, caches locais ou imagens de build.

Além de estáções de desenvolvimento, runners de CI/CD, contêineres efêmeros de build e ambientes de staging que executaram instalação npm durante a janela de exposição devem ser considerados potencialmente comprometidos, especialmente se tokens, chaves ou segredos estiverem presentes no mesmo host ou em variáveis acessíveis ao processo de instalação.

• Pacotes npm no namespace @mastra/*, com destaque para @mastra/core pelo volume de downloads semanais
• Dependência maliciosa easy-day-js adicionada à cadeia de resolução de cada pacote afetado
• Conta npm ehindero com permissão de publicação no escopo Mastra
• Workstations, pipelines CI/CD e ambientes de build que instalaram versões publicadas na janela de 17/06/2026
• Usuários finais indiretos apenas se artefatos comprometidos tiverem sido incorporados a builds subsequentes sem revisão

Hunting e telemetria

Equipes de segurança e engenharia devem correlacionar eventos de instalação npm com a presença da dependência easy-day-js em árvores de dependências, lockfiles ou caches de pacotes. A execução via postinstall tende a gerar processos filhos desacoplados logo após atividade do gerenciador de pacotes, possivelmente acompanhados de tráfego de rede para os endereços 23.254.164[.]92 e 23.254.164[.]123, com comportamento indicativo de validação TLS desabilitada durante o download do segundo estágio.

Em endpoints, sinais compatíveis com o stealer final incluem acesso ampliado a perfis de navegador, leitura de dados de extensões de carteiras cripto, criação de artefatos de persistência em múltiplos sistemas operacionais e exfiltração periódica para infraestrutura externa. A remoção deliberada do loader após a execução pode deixar lacunas em logs de instalação, tornando relevante a reconstrução temporal entre o timestamp de npm install, alterações em lockfiles e conexões de rede subsequentes.

• Presença de easy-day-js em package-lock.json, yarn.lock, pnpm-lock.yaml ou saída de npm ls em builds recentes do ecossistema Mastra
• Processos iniciados imediatamente após hooks postinstall de pacotes @mastra/* ou de easy-day-js
• Conexões de saída para 23.254.164[.]92 durante instalação e para 23.254.164[.]123 após execução do estágio final
• Modificações em diretórios de extensões de navegador ou perfis associados a carteiras de criptomoedas
• Publicações npm no escopo @mastra/* sem atestação de proveniência SLSA, indicando token pessoal em vez do fluxo de CI confiável

Mitigação

A resposta imediata exige identificar e fixar versões seguras anteriores à onda maliciosa, removendo easy-day-js da árvore de dependências e reconstruindo imagens, caches e ambientes a partir de lockfiles auditados. Credenciais presentes em hosts que instalaram pacotes afetados — tokens npm, chaves de API, segredos de CI, credenciais de cloud e materiais de assinatura de código — devem ser rotacionados após a contenção inicial, assumindo que o stealer pode tê-los coletado se estavam acessíveis no contexto do usuário ou do runner comprometido.

Do ponto de vista preventivo, o caso expõe uma lacuna entre geração e exigência de proveniência: releases legítimos do Mastra são publicados via fluxo de trusted publisher no CI, com atestação SLSA, mas a política do escopo não obrigava a presença dessa atestação. O atacante publicou versões maliciosas com token pessoal, sem proveniência, e uma instalação com verificação de assinaturas npm ou política que rejeite pacotes sem atestação teria bloqueado toda a onda. Revogar acessos de colaboradores inativos ao escopo npm, monitorar publicações que divergem do padrão de CI e integrar verificação de assinaturas ao pipeline de build fecham o ciclo defensivo para ecossistemas open source com alto volume de downloads.

• Reverter pacotes @mastra/* para versões anteriores confirmadas como seguras e regenerar lockfiles
• Remover completamente easy-day-js de dependências diretas e transitivas; invalidar caches npm locais e de CI
• Rotacionar tokens npm, segredos de pipeline, chaves de assinatura e credenciais de serviços acessíveis nos hosts afetados
• Executar varredura forense em workstations e runners que instalaram versões na janela de 17/06/2026, buscando persistência e exfiltração
• Implementar política de instalação que exija atestação SLSA ou npm audit signatures para publicações no escopo Mastra
• Auditar e revogar permissões npm de contas de ex-colaboradores sem necessidade ativa de publicação