Bomba gzip no node-tar cria falha crítica (CVSS 9.2) para pipelines Node.js
CVE-2026-59873 permite exaurir CPU e disco com um pequeno tarball. A biblioteca faz 106 milhões de downloads semanais no npm e sustenta boa parte da cadeia de build JavaScript.
A biblioteca node-tar, uma das dependências mais transversais do ecossistema JavaScript, recebeu no dia 12 de julho o registro da CVE-2026-59873, classificada em CVSS 9.2 pelo GitHub Advisory Database. O defeito está nos caminhos de extração e parsing em src/extract.ts: nenhuma versão anterior à 7.5.19 aplica limites rígidos ao total descomprimido, à contagem de entradas ou à taxa de compressão. Uma pequena bomba gzip cuidadosamente construída é o bastante para esgotar disco e CPU do processo que abre o arquivo.
O tamanho do estrago está no denominador. O pacote tar no npm registra 106,4 milhões de downloads por semana, segundo o Snyk, número que o coloca entre as bibliotecas de suporte mais consumidas do registro. Boa parte disso vem de pipelines de CI/CD executando npm install do zero, mas o volume revela a superfície de exposição: onde há Node processando arquivos empacotados, quase certamente há node-tar embaixo.
O que a falha faz
O padrão de exploração é o clássico DoS via arquivo compactado: um tarball de poucos kilobytes que, ao ser expandido, consome gigabytes de RAM e disco. Em runtimes que rodam extrações como parte de deploy ou build, a diferença entre um pipeline saudável e um pod que não responde vira uma questão de qual pacote passou por último pela esteira. A classificação CWE-770 aplicada ao caso descreve a categoria: alocação de recursos sem limites nem throttling. É o tipo de defeito que costuma virar page em SREs.
Na mesma janela do dia 12 chegaram duas outras CVEs relacionadas. A CVE-2026-59874, com CVSS 8.7, atinge tar.replace: um cabeçalho com soma de verificação válida mas tamanho negativo codificado em base-256 faz o scanner do arquivo ficar parado, relendo o mesmo header sem sair do lugar. É um laço infinito sem saída, catalogado em CWE-835, corrigido em 7.5.18. Já a CVE-2026-59871 quebra o processo por confusão de tipo em cabeçalhos PAX numéricos, permitindo derrubar o serviço via tarball malformado.
Por que isso importa fora do bug tracker
O risco real de node-tar sai do bug tracker quando se olha para onde a biblioteca opera. Em pipelines de CI/CD que baixam e expandem tarballs de origens semi-confiáveis, em ambientes multi-tenant de PaaS que abrem uploads de clientes e em ferramentas de infra que consomem artefatos empacotados, o vetor é sempre o mesmo: alguém envia um tarball, alguém extrai, alguém trava. Sem o teto de descompressão que a 7.5.19 introduz, um único arquivo malicioso pode arrastar workers de um cluster inteiro até o esgotamento de recursos.
O time do node-tar já publicou 7.5.19, com o hardening de limites, e 7.5.18, fechando o laço em replace. A janela de exposição, porém, é a distância entre o commit de correção e o momento em que o build reconstrói a árvore de dependências. Em muitos ambientes empresariais, com pinning agressivo e política de patch mensal, esse intervalo passa de semanas.
O padrão de janeiro para cá
A cadência de CVEs na biblioteca ficou alta ao longo de 2026. Em janeiro, a CVE-2026-23745 já havia forçado o node-tar até 7.5.3 porque a lib falhava em sanitizar linkpath em entradas de hardlink e symlink, permitindo sobrescrever arquivos fora da raiz de extração. Naquele caso, o próprio npm CLI ficou protegido porque filtra Link e SymbolicLink dos pacotes que instala, mas qualquer pipeline caseiro que rodasse tar sobre input não confiável ficou vulnerável até atualizar. O advisory do GitHub para essa CVE listou milhares de projetos dependentes.
Empresas que consomem apenas tarballs de artefatos internos assinados continuam relativamente seguras. Quem processa arquivos submetidos por usuários, agregadores de dados, integrações com fornecedores e conteúdo público fica na primeira linha, porque a exploração dispensa autenticação e não precisa de payload sofisticado. Vale programar a atualização junto do próximo ciclo de build, conferir onde a extração acontece sem limites de tempo ou espaço configurados por fora do processo e, para operadores de PaaS que aceitam upload de arquivos, considerar isolamento em cgroups ou containers descartáveis por operação de extração.
Esse tipo de CVE não gera manchete fora dos círculos de AppSec, mas tende a virar incidente para quem opera integrações. A recomendação prática é olhar os pipelines que processam qualquer arquivo comprimido vindo de fora, mapear onde node-tar está sendo importado indiretamente e forçar uma bump para 7.5.19 antes de os scanners automáticos começarem a listar o defeito nos dashboards de risco de fornecedores.