Hackers da Coreia do Norte envenenaram 140+ pacotes npm de um framework de IA — o ataque Mastra e o que ele ensina

Todo dev faz isso dezenas de vezes por semana sem pensar: npm install. Você confia que aquele punhado de pacotes — e os pacotes deles, e os pacotes dos pacotes deles — são o que dizem ser. O ataque dessa semana é um lembrete duro de que essa confiança tem um custo.

O que aconteceu?

A Microsoft atribuiu, com "alta confiança", à Coreia do Norte — o grupo estatal Sapphire Sleet (também conhecido como BlueNoroff) — um ataque de cadeia de suprimentos que comprometeu mais de 140 pacotes npm do escopo @mastra, ligado a um framework de IA do ecossistema Node/JavaScript. A divulgação saiu em 19–20 de junho de 2026.

O caminho de entrada foi clássico: os atacantes sequestraram a conta de um mantenedor (com permissão de publicar) e injetaram uma dependência maliciosa chamada easy-day-js — um typosquat da biblioteca legítima dayjs. Nome parecido, intenção oposta.

Como o ataque funcionava

O pacote-isca explorava um postinstall — um script que o npm roda automaticamente assim que o pacote é instalado. Segundo a análise, a cadeia era:

npm install            // você instala (direta ou indiretamente) o pacote
   └─ postinstall      // o npm dispara o script sozinho
        └─ dropper ofuscado
             ├─ desliga a verificação de certificado TLS
             ├─ contata o servidor de comando (C2)
             └─ baixa a 2ª fase: um info-stealer multiplataforma

A segunda fase era um ladrão de dados para Windows, Linux e macOS. Ele varria 166 extensões de carteira de criptomoedas (MetaMask, Phantom, Coinbase e outras), roubava credenciais, chaves de API, tokens de autenticação e carteiras, e instalava persistência (chaves de inicialização no Registro do Windows, LaunchAgents no macOS, serviços systemd no Linux) pra sobreviver a um reboot.

Por que isso te afeta mesmo se você nunca ouviu falar do Mastra

Porque o perigo não é aquele pacote — é o modelo. Você instala A, que depende de B, que depende de C. Se C for trocado por uma versão maliciosa, o código roda na sua máquina, no instante do npm install — antes de você executar uma linha do seu projeto. E não é "problema de quem faz Node": qualquer projeto com front-end — inclusive os meus, em PHP — puxa dezenas de pacotes npm pra montar CSS e JS.

Como blindar suas dependências

• Versione o lockfile e instale com npm ci — ele instala exatamente o que está no package-lock.json, sem resolver versões novas por conta própria.
• Desligue scripts automáticos: npm install --ignore-scripts (ou ignore-scripts=true no .npmrc). Rode postinstall só de pacotes em que você confia.
• Não instale o que acabou de sair. Espere alguns dias antes de adotar uma versão recém-publicada — a maioria dos pacotes envenenados é pega e removida nas primeiras horas.
• Leia o nome com atenção. easy-day-js não é dayjs. Typosquat vive de pressa e piloto automático.
• Rode npm audit e considere um serviço de análise de pacotes (ex.: Socket) no seu CI.
• Separe os segredos da máquina de dev. Não deixe chaves de produção e carteiras na mesma máquina onde você roda npm install de projeto aleatório. É a diferença entre "instalei um pacote ruim" e "perdi tudo".

Minha leitura

A força do ecossistema npm — reaproveitar o trabalho do mundo inteiro com um comando — é também a sua maior superfície de ataque. Eu trato dependência de terceiro como código não confiável por padrão: lockfile travado, scripts desligados, segredos isolados e um olho no que entra no projeto. Não é paranoia — é o custo de operar num ecossistema aberto.

Quero revisar a segurança do meu projeto

Quer uma revisão das dependências e do pipeline do seu projeto antes que um elo fraco vire dor de cabeça? É exatamente o tipo de coisa que eu faço — bora conversar.

Fontes

BleepingComputer · Microsoft Security (MSTIC)