Raio de explosão04·08·2026 09:35:00 UTC

Às 09:35:00 UTC, o ChainDrop já estava no registro, e nenhuma faixa do stylelint o aceitava.

npm install sem lockfile, 4 ago 2026, às 09:35:00 UTC

O keyv, onde o ataque começou, ficou de fora: ^5.6.0 não aceita 6.0.0.

Às 09:35:00 UTC, o ChainDrop já estava no registro, e nenhuma faixa do stylelint o aceitava.09:35:00 UTC. Caminho: stylelint → file-entry-cache → flat-cache → cacheable → @cacheable/memory → @cacheable/utils → keyv; nenhum infectado alcançável; 3 arestas barradas pela faixa.file-entry-cacheoutras 34 diretas

116 NO GRAFO · 6 NO CAMINHOFaixas do grafo coletado em 25 set 2026 (deps.dev); raiz resolvida no instante escolhido

09:35:00 UTC · keyv 6.0.0 publicada. ^5.6.0 não aceita 6.0.0: barrado.

A manhã de 4 de agosto

  1. 09:30:00nenhuma versão publicadaantes do primeiro evento
  2. 09:35:00keyv@6.0.0barrado · ^5.6.0
  3. 10:10:44cacheable@2.5.1abre 3 saltos
  4. 10:10:55flat-cache@6.1.24abre 2 saltos
  5. 10:11:29@cacheable/memory@2.2.1abre 4 saltos
  6. 10:13:02file-entry-cache@11.1.6abre 1 salto
  7. 10:14:21@cacheable/utils@2.5.1abre 4 saltos
  8. ~10:39remoção começa (StepSecurity)grafo sem mudança

Caminho

porta de entrada: file-entry-cache, dependência direta

Barrados pela faixa

E se fosse outro pacote

Sem lista de maliciosos: escolha qualquer um dos 115 pacotes do grafo do stylelint e veja todos os caminhos até ele. Tocar num pacote do gráfico faz o mesmo.

O que fazer

  1. Veja o seu caminho no repositório. Compare as versões que aparecem com a lista em Fontes e método.

    npm ls keyv flat-cache file-entry-cache cacheable cacheable-request --all
  2. Commite o lockfile e instale com npm ci no CI: ele instala o que está no lockfile e não resolve faixas de novo.

    npm ci
  3. Trave a porta de entrada com overrides no package.json até o incidente fechar.

    "overrides": { "file-entry-cache": "11.1.5" }
  4. Durante a janela de um incidente, instale sem scripts: o ChainDrop entrava pelo preinstall.

    npm install --ignore-scripts

Fontes e método

Lista de IOCs do ChainDrop, Datadog Security Labs
Apache-2.0. 444 pacotes, 2.236 versões no arquivo usado; a StepSecurity conta 2.212. Artigo: “ChainDrop” worm compromises hundreds of popular npm packages (4 ago 2026).
Dados de dependências: deps.dev (Google), CC BY 4.0
O grafo resolvido de cada caso, com a faixa de cada aresta (API v3, GetDependencies), e a data de publicação da raiz.
OSV e ossf/malicious-packages
Apache-2.0. O registro MAL-… de cada versão maliciosa, com o mecanismo e os créditos.
Registro do npm
O segundo em que cada versão maliciosa foi publicada (campo time). Só esses horários foram guardados.
StepSecurity, “ChainDrop npm Worm”
A remoção: o npm começou a despublicar por volta de 10:39 UTC, e os 11 portadores principais foram revertidos até 18:10 UTC. É a afirmação deles; a hora de saída de cada versão não é pública.

Dados coletados uma vez em 25 set 2026; a página não consulta nada ao abrir.

A regra. Uma aresta está aberta quando uma versão maliciosa do pacote de destino já estava publicada naquele instante e a faixa da aresta a aceita (semver do npm). Está barrada quando há versão maliciosa publicada e a faixa não aceita nenhuma.

  • A raiz é a versão que npm install dava na manhã de 4 de agosto; o resto é o grafo como o deps.dev o coletou, não o de 4 de agosto. A regra usa a faixa de cada aresta, não a versão resolvida.
  • As dependências da versão maliciosa não são conhecidas (foi despublicada); supõe-se que tinha as mesmas faixas da versão limpa anterior.
  • Com lockfile commitado e npm ci, nada disso é resolvido de novo. A página não afirma que alguém foi infectado.
  • A hora em que cada versão saiu do registro não é conhecida; o gráfico não encolhe a zona depois de 10:39.