La bomba gzip en node-tar crea una falla crítica (CVSS 9.2) para pipelines de Node.js
CVE-2026-59873 permite agotar CPU y disco con un pequeño tarball. La biblioteca realiza 106 millones de descargas semanales en npm y sostiene gran parte de la cadena de build JavaScript.
La biblioteca node-tar, una de las dependencias más transversales del ecosistema JavaScript, recibió el 12 de julio el registro de la CVE-2026-59873, clasificada en CVSS 9.2 por la Base de Datos de Asesoría de GitHub. El defecto se encuentra en los caminos de extracción y análisis en src/extract.ts: ninguna versión anterior a 7.5.19 aplica límites estrictos al total descomprimido, al conteo de entradas o a la tasa de compresión. Una pequeña bomba gzip cuidadosamente construida es suficiente para agotar el disco y la CPU del proceso que abre el archivo.
La magnitud del daño está en el denominador. El paquete tar en npm registra 106,4 millones de descargas por semana, según Snyk, cifra que lo coloca entre las bibliotecas de soporte más consumidas del registro. Gran parte de esto proviene de pipelines de CI/CD ejecutando npm install desde cero, pero el volumen revela la superficie de exposición: donde hay Node procesando archivos empaquetados, casi seguro hay node-tar debajo.
Qué hace la falla
El patrón de explotación es el clásico DoS a través de un archivo comprimido: un tarball de pocos kilobytes que, al ser expandido, consume gigabytes de RAM y disco. En runtimes que realizan extracciones como parte del despliegue o build, la diferencia entre un pipeline saludable y un pod que no responde se convierte en una cuestión de qué paquete pasó por último por la cinta. La clasificación CWE-770 aplicada al caso describe la categoría: asignación de recursos sin límites ni throttling. Es el tipo de defecto que suele convertirse en un problema en SREs.
En la misma ventana del día 12 llegaron otras dos CVEs relacionadas. La CVE-2026-59874, con CVSS 8.7, afecta a tar.replace: un encabezado con suma de verificación válida pero tamaño negativo codificado en base-256 hace que el escáner del archivo se quede atascado, releyendo el mismo encabezado sin salir del lugar. Es un lazo infinito sin salida, catalogado en CWE-835, corregido en 7.5.18. Por otro lado, la CVE-2026-59871 rompe el proceso por confusión de tipo en encabezados PAX numéricos, permitiendo derribar el servicio a través de un tarball malformado.
Por qué esto importa fuera del bug tracker
El riesgo real de node-tar sale del bug tracker cuando se observa dónde opera la biblioteca. En pipelines de CI/CD que descargan y expanden tarballs de fuentes semi-confiables, en entornos multi-tenant de PaaS que abren cargas de clientes y en herramientas de infraestructura que consumen artefactos empaquetados, el vector es siempre el mismo: alguien envía un tarball, alguien extrae, alguien se bloquea. Sin el techo de descompresión que introduce la versión 7.5.19, un solo archivo malicioso puede arrastrar a trabajadores de un clúster entero hasta el agotamiento de recursos.
El equipo de node-tar ya publicó 7.5.19, con el endurecimiento de límites, y 7.5.18, cerrando el bucle en replace. Sin embargo, la ventana de exposición es la distancia entre el commit de corrección y el momento en que el build reconstruye el árbol de dependencias. En muchos entornos empresariales, con pinning agresivo y políticas de parches mensuales, este intervalo supera semanas.
El patrón de enero hasta ahora
La cadencia de CVEs en la biblioteca ha sido alta a lo largo de 2026. En enero, la CVE-2026-23745 ya había obligado a node-tar hasta la versión 7.5.3 porque la biblioteca fallaba en sanitizar linkpath en entradas de hardlink y symlink, permitiendo sobrescribir archivos fuera de la raíz de extracción. En ese caso, el propio npm CLI quedó protegido porque filtra Link y SymbolicLink de los paquetes que instala, pero cualquier pipeline interno que ejecutara tar sobre inputs no confiables quedó vulnerable hasta actualizar. El aviso de GitHub para esta CVE enumeró miles de proyectos dependientes.
Las empresas que solo consumen tarballs de artefactos internos firmados continúan relativamente seguras. Quienes procesan archivos enviados por usuarios, agregadores de datos, integraciones con proveedores y contenido público están en la primera línea, porque la explotación no requiere autenticación y no necesita un payload sofisticado. Vale la pena programar la actualización junto con el próximo ciclo de build, verificar dónde la extracción ocurre sin límites de tiempo o espacio configurados fuera del proceso y, para los operadores de PaaS que aceptan cargas de archivos, considerar el aislamiento en cgroups o contenedores descartables por operación de extracción.
Este tipo de CVE no genera titulares fuera de los círculos de AppSec, pero tiende a convertirse en un incidente para quienes operan integraciones. La recomendación práctica es observar los pipelines que procesan cualquier archivo comprimido proveniente de fuentes externas, mapear dónde se importa node-tar indirectamente y forzar una actualización a la versión 7.5.19 antes de que los escáneres automáticos comiencen a listar el defecto en los tableros de riesgo de proveedores.