La popular librería de compresión zlib vuelve a colocarse en el radar de los equipos de seguridad por una vulnerabilidad crítica relacionada con la utilidad untgz, un componente auxiliar incluido en el árbol de código. El problema, ya catalogado como CVE-2026-22184, afecta a la función TGZfname() y se origina por el uso de una copia sin límites (strcpy) sobre una cadena controlada por el usuario, lo que puede provocar un desbordamiento de búfer global.
Qué se ha encontrado exactamente
Según el aviso difundido en listas de seguridad y el análisis posterior, el fallo aparece cuando untgz procesa el nombre del archivo que se le pasa por línea de comandos. Ese nombre se copia directamente desde argv[] a un búfer global estático de tamaño fijo (1.024 bytes) sin ninguna validación de longitud. El resultado: si el argumento excede ese límite, se escribe fuera de los márgenes del búfer y se corrompe memoria.
El detalle importante para administradores y responsables de plataforma es el matiz que a veces se pierde en los titulares: no se trata del “núcleo” de la librería zlib, sino de una utilidad dentro del directorio contrib. Dicho de otro modo, la superficie de exposición depende de si untgz está presente e invocable en el sistema (o en alguna cadena de herramientas que lo ejecute).
Por qué es “crítico” si parece un bug de línea de comandos
A primera vista, una vulnerabilidad que requiere invocar un binario con un argumento largo podría sonar “local” o limitada. Sin embargo, los escenarios reales que preocupan a los equipos defensivos suelen ser indirectos:
- Pipelines de CI/CD, donde herramientas auxiliares se ejecutan con parámetros derivados de artefactos o nombres generados automáticamente.
- Servicios internos o scripts de automatización que llaman a utilidades externas y pasan nombres de archivo construidos a partir de entradas no confiables.
- Entornos multiusuario (HPC, universidades, laboratorios) en los que un atacante con acceso a shell busca elevar impacto con fallos de memoria.
Los investigadores que documentaron el problema mostraron que el desbordamiento se desencadena antes de cualquier validación o parseo del archivo, lo que simplifica el disparo del fallo: basta con un argumento malformado suficientemente largo.
En cuanto al impacto, se habla de denegación de servicio (caídas), corrupción de memoria y, en determinadas condiciones (arquitectura, compilador, banderas de build y layout de memoria), posible ejecución de código.
Un detalle “incómodo”: la versión 1.3.1.2 y el ruido alrededor del nombre
Otro punto relevante para evitar confusiones en inventarios: en el debate público aparece la referencia a “zlib 1.3.1.2”, pero desde oss-security se aclara que 1.3.1.2 no es una release oficial, sino un tag de Git usado con otros fines. Esto importa porque puede afectar a cómo se rastrea el software vulnerable en entornos donde zlib se compila desde fuentes, se empaqueta con parches o se distribuye con nomenclaturas propias.
Por eso, más que perseguir un número exacto, la recomendación práctica es: confirmar si el binario untgz existe en el sistema y de dónde proviene (paquete, build interno, toolchain, contenedor, etc.).
Qué deberían hacer los administradores de sistemas
Sin necesidad de dramatizar, sí conviene tratarlo como incidente de higiene operativa:
- Comprobar si untgz está presente
- En Linux, una verificación típica es localizar el binario en PATH y revisar a qué paquete pertenece (si aplica). Si untgz no existe, el riesgo operativo suele ser bajo en ese host concreto.
- Reducir exposición
- Si untgz está instalado y no se usa, una medida sensata es retirarlo o restringir su ejecución (control de permisos), especialmente en sistemas compartidos.
- Actualizar cuando exista paquete corregido
- Monitorizar los avisos de tu distribución (Debian/Ubuntu, RHEL, SUSE, etc.) o del proveedor del appliance/imagen. NVD ya recoge el identificador y el resumen técnico del fallo, lo que ayuda a los procesos de gestión de vulnerabilidades a engancharlo en cuanto haya parches oficiales.
- Auditar pipelines y scripts
- Revisar automatizaciones donde se llamen utilidades auxiliares para desempaquetado/gestión de TGZ, especialmente si nombres de archivo o rutas provienen de entradas externas.
Lectura entre líneas: lo que esta vulnerabilidad dice del ecosistema
Este caso vuelve a subrayar una realidad habitual en infraestructuras: muchas veces el riesgo no está en el componente “estrella”, sino en herramientas periféricas que llegan con el código fuente, quedan instaladas por arrastre o aparecen en contenedores “de conveniencia”.
También refuerza una máxima clásica del hardening: si no se usa, se elimina. En 2026, con cadenas de suministro software cada vez más largas, cada binario extra es otra variable que defender.
Preguntas frecuentes
¿La vulnerabilidad afecta a la librería zlib que usa medio Internet o solo a la utilidad untgz?
La información publicada sitúa el problema en la utilidad untgz dentro del directorio contrib, no en el uso típico de la librería zlib como dependencia de compresión en aplicaciones. Aun así, conviene verificar si untgz está presente en tus sistemas.
¿Puede explotarse de forma remota?
El disparador descrito se basa en entrada por línea de comandos, pero puede convertirse en un problema “remoto” si algún servicio, pipeline o script ejecuta untgz con parámetros construidos a partir de datos controlables por un atacante (por ejemplo, nombres de archivo).
¿Cómo puedo saber si estoy expuesto en mis servidores Linux?
El enfoque más práctico es confirmar si existe el binario untgz, identificar su origen (paquete o build) y revisar si alguna automatización lo utiliza. Si no está instalado, la exposición suele ser baja para este caso concreto.
¿Qué priorizo: parchear ya o eliminar untgz?
En entornos donde untgz no sea imprescindible, retirarlo o restringirlo suele ser la mitigación más rápida. En paralelo, lo recomendable es aplicar actualizaciones del proveedor/distribución en cuanto estén disponibles para cerrar el riesgo de forma definitiva.
Fuentes:
- NVD (NIST) – CVE-2026-22184 (nvd.nist.gov)
- oss-security (Openwall) – hilo sobre untgz y aclaraciones de alcance (openwall.com)
- GitHub (zlib) – issue de seguimiento relacionado (github.com)
