CVE-2025-54313

Quatro versões do pacote npm eslint-config-prettier (8.10.1, 9.1.1, 10.1.6 e 10.1.7) foram publicadas por um atacante que roubou o token npm do mantenedor via phishing, e continham um script de pós-instalação que tenta executar uma DLL maliciosa em máquinas Windows. O pacote tem mais de 30 milhões de downloads semanais e é puxado automaticamente por praticamente qualquer projeto que usa Prettier + ESLint, o que torna o alcance potencial enorme mesmo sendo um ataque pontual e já contido pelo mantenedor.

Não é uma falha de lógica no código do eslint-config-prettier — é um comprometimento de cadeia de suprimentos (CWE-506, código embutido malicioso) via roubo de credencial de publicação. O mantenedor (JounQin) recebeu um e-mail de phishing convincente, com remetente falsificado como 'support@npmjs.com', apontando para o domínio typosquat 'npnjs.com'. Ao inserir credenciais nesse site, seu token de publicação no registro npm foi roubado e usado para publicar quatro versões sem nenhum commit ou PR correspondente no repositório GitHub — sinal que expôs o ataque rapidamente.

As versões maliciosas incluem um arquivo 'install.js' registrado como hook 'postinstall' no package.json. Dentro dele há uma função chamada 'logDiskSpace()' que, a despeito do nome, não monitora disco: ela invoca o binário do sistema Windows 'rundll32.exe' para carregar uma DLL chamada 'node-gyp.dll' embutida no pacote. Essa DLL é um trojan reconhecido (detecção de 19/72 engines no VirusTotal no momento da divulgação), com potencial de execução remota de código no host onde o pacote foi instalado.

O mesmo mantenedor teve outros pacotes seus comprometidos com a mesma técnica: eslint-plugin-prettier (4.2.2, 4.2.3), synckit (0.11.9), @pkgr/core (0.2.8) e napi-postinstall (0.3.1). Um pacote de terceiros não relacionado, 'got-fetch' (versões 5.1.11 e 5.1.12), foi comprometido de forma quase idêntica, com uma DLL chamada 'crashreporter.dll' — indício de que se trata do mesmo grupo atacante rodando uma campanha mais ampla contra mantenedores npm.

O vetor de exploração não depende de nada que o usuário final da vítima faça além de instalar o pacote: o payload roda automaticamente via hook 'postinstall' do npm no momento do 'npm install' (ou equivalente em pnpm/yarn/bun), sem interação adicional. É por isso que o vetor CVSS marca UI:N — a 'interação' já é o ato normal de instalar dependências. A complexidade de ataque (AC:H) reflete o pré-requisito real: o atacante precisa primeiro comprometer as credenciais de publicação de um mantenedor legítimo, o que aqui aconteceu por phishing direcionado, não por falha técnica no npm.

O payload é condicionado à plataforma: só é efetivo em máquinas Windows. Ambientes Linux e macOS que instalaram as mesmas versões não executam o carregamento da DLL, conforme confirmado por equipes que analisaram o incidente. Isso limita bastante o impacto prático em ambientes de produção baseados em containers Linux, mas afeta diretamente estações de desenvolvimento Windows e pipelines de CI/CD que rodam em runners Windows — que é onde 'devDependencies' como linters normalmente são instaladas.

A janela de exploração ativa foi curta: os pacotes maliciosos foram publicados em 18 de julho de 2025, detectados pela comunidade horas depois via diff suspeito entre versões npm sem commits correspondentes no GitHub, e o mantenedor revogou o token e depreciou as versões no mesmo dia. Ferramentas de atualização automática de dependências (Dependabot, Renovate) e pipelines fixados em 'latest' aumentaram o risco de ingestão automática durante essa janela.

Não instale nem mantenha em lockfiles as versões afetadas: eslint-config-prettier 8.10.1, 9.1.1, 10.1.6, 10.1.7. O mantenedor marcou essas versões como 'deprecated' no registro npm e coordenou a remoção junto ao suporte do npm; segundo o próprio ecossistema, o caminho seguro é fazer rollback para 10.1.5 ou uma versão anterior conhecida como limpa, ou para uma versão publicada após a remediação do incidente — verifique a data de publicação e a existência de commit correspondente no GitHub antes de confiar em qualquer versão nova. Não há, nas fontes analisadas, um número de versão específico anunciado pelo fornecedor como 'a correção oficial'; trate qualquer versão 8.10.1/9.1.1/10.1.6/10.1.7 como definitivamente comprometida e qualquer versão publicada com correspondência de commit no repositório como confiável.

Ação imediata recomendada: auditar package-lock.json, pnpm-lock.yaml, yarn.lock e bun.lock em busca das versões listadas (inclua também eslint-plugin-prettier 4.2.2/4.2.3, synckit 0.11.9, @pkgr/core 0.2.8, napi-postinstall 0.3.1 e, se usado, got-fetch 5.1.11/5.1.12). Se instalação ocorreu após 18 de julho de 2025 em máquina Windows, apague node_modules, limpe o cache do npm e reinstale a partir de um lockfile limpo; considere a máquina potencialmente comprometida até análise, e rotacione segredos que possam ter sido expostos durante builds executados nesse período.

Controle compensatório estrutural, não específico desta CVE: fixar versões exatas em CI/CD em vez de usar tags 'latest' ou ranges semver amplos, exigir 2FA em contas npm de mantenedores (mitigação do lado do fornecedor, fora do seu controle direto, mas relevante para avaliar risco de dependências), e usar ferramentas de escaneamento de pacote que alertem sobre scripts de instalação inesperados ou novas versões sem histórico de commit correspondente. Atualizar 'apenas' para a versão mais recente não é garantia — o mito a evitar é assumir que 'a última versão publicada é sempre a mais segura'; neste incidente, era exatamente o contrário.

Procure pelo hook 'postinstall' apontando para um arquivo 'install.js' contendo uma função chamada 'logDiskSpace()' nas dependências instaladas — esse nome de função é a assinatura reportada do payload. Em nível de sistema Windows, procure por processos 'rundll32.exe' sendo filhos de processos node/npm/pnpm/yarn, especialmente carregando uma biblioteca chamada 'node-gyp.dll' (ou, no caso do pacote relacionado got-fetch, 'crashreporter.dll') fora dos caminhos esperados de instalação nativa do node-gyp legítimo.

Em nível de dependências, faça grep nos lockfiles por eslint-config-prettier@8.10.1, @9.1.1, @10.1.6 ou @10.1.7 (e nas versões correlatas listadas em versions_affected) — a presença de qualquer uma delas é evidência direta de exposição, independente de ter sido explorada. Não há um indicador de rede confiável e público (C2, domínio de callback) documentado nas fontes consultadas; o risco maior é local, via execução da DLL, e a ausência de tráfego de rede suspeito não descarta comprometimento.