7-Zip: desbordamiento de montón LZX y RCE con un CAB manipulado (CVE-2026-125742)

Resumen

• Un desbordamiento de montón en el decodificador LZX de 7-Zip permite que un CAB multi-volumen manipulado ejecute código al extraerlo. La ventana LZX puede reducirse entre volúmenes mientras el decodificador conserva un desplazamiento obsoleto.
• Las versiones de 7-Zip anteriores a 26.06 están afectadas. El fallo está en el decodificador, por lo que afecta a las compilaciones de Windows, Linux y macOS que comparten ese código.
• El registro CVE lo califica como CVSS v4.0 8.5 High, CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, y CWE-787. No se conoce explotación en entornos reales, y CVE-2026-125742 no está en el catálogo Known Exploited Vulnerabilities (KEV) de CISA al 10 de noviembre de 2026.
• Actualice a 7-Zip 26.06, publicado el 6 de noviembre de 2026, y no extraiga archivos CAB multi-volumen que no sean de confianza hasta que todas las copias estén actualizadas. Véase «¿Cómo lo corrijo?».

¿Estoy afectado?

Todas estas condiciones deben cumplirse:

• Usa 7-Zip anterior a 26.06. El rango afectado del registro CVE es toda versión anterior a 26.06.
• El atacante puede conseguir que extraiga un archivo CAB multi-volumen manipulado con 7-Zip, por ejemplo por correo, por un recurso compartido o por una descarga.
• La extracción usa el decodificador LZX propio de 7-Zip, que es el predeterminado para las carpetas CAB comprimidas con LZX. Otro archivador puede incluir código distinto.

El registro CVE da el rango de versiones desde «0» hasta «26.06» exclusivo. La corrección está en el código fuente 26.06 y en la versión 26.06 publicada el 6 de noviembre de 2026. El fallo está en CPP/7zip/Compress/LzxDecoder.cpp, compartido por las compilaciones oficiales.

Compruebe la versión instalada desde un terminal:

7zz i | head -n 3

En Windows el ejecutable de consola es 7z, así que ejecute 7z i en PowerShell o en el símbolo del sistema; la aplicación gráfica muestra la versión en Ayuda y luego Acerca de 7-Zip. Las compilaciones oficiales de Linux y macOS instalan 7zz. Chocolatey y Windows Package Manager informan del paquete instalado:

choco list 7zip
winget list 7zip.7zip

Si la línea de versión dice 26.05 o una anterior, la instalación está afectada. Una instalación 26.06 está corregida para esta CVE.

¿Cómo lo corrijo?

Actualice 7-Zip a 26.06 en cada máquina que extraiga archivos que no sean de confianza.

1. En Windows, instale la compilación 26.06 desde la página de descarga oficial, o use un gestor de paquetes: winget upgrade 7zip.7zip choco upgrade 7zip -y
2. En Linux, use el paquete de su distribución cuando incluya 26.06. Si no, instale la compilación oficial de Linux desde 7-zip.org. Confirme la versión con 7zz i.
3. En macOS, instale la compilación 26.06 de macOS desde la página de descarga oficial y confirme la versión con 7zz i.
4. Revise el software que incluye su propia copia de 7-Zip, como instaladores y gestores de archivos. Actualizar el 7-Zip del sistema no actualiza una copia incluida.

No hay ningún interruptor de configuración que desactive la ruta LZX vulnerable y mantenga la extracción CAB. Hasta que todas las copias estén actualizadas, trate los archivos CAB multi-volumen como código que no es de confianza:

1. No extraiga archivos CAB que lleguen por correo o desde una descarga que no sea de confianza.
2. Si debe inspeccionar uno, extráigalo en una máquina virtual o un contenedor desechable con un usuario sin privilegios.
3. Bloquee los adjuntos CAB multi-volumen en la pasarela de correo. Eso reduce la exposición; no corrige el decodificador.

¿Cuál es la causa raíz?

El decodificador mantiene una posición de escritura _pos para su ventana LZX, y solo la reinicia en el límite de una ventana cuando continúa un archivo multi-volumen. Un volumen posterior puede pedir una ventana más pequeña, y el redimensionamiento libera el búfer anterior sin reiniciar _pos.

Esta es la lógica de continuación vulnerable en Code_WithExceedReadWrite() en 7-Zip 26.05:

if (!_keepHistory)
{
  _pos = 0;
  _overDict = false;
}
else if (_pos == _winSize)
{
  _pos = 0;
  _overDict = true;
}
_writePos = _pos;
_unpackedData = _win + _pos;

if (outSize > _winSize - _pos)
  return S_FALSE;

_keepHistory es verdadero cuando el decodificador continúa en el siguiente gabinete. _pos es el desplazamiento de escritura actual, _winSize es el tamaño actual de la ventana y _win es el búfer de la ventana. En un archivo nuevo _pos se pone a cero. En una continuación solo se pone a cero cuando es exactamente igual a _winSize.

El redimensionamiento ocurre en Set_DictBits_and_Alloc():

const UInt32 newWinSize = (UInt32)1 << numDictBits;
if (_needAlloc)
{
  if (!_win || newWinSize != _winSize)
  {
    z7_AlignedFree(_win);
    _winSize = 0;
    const size_t alloc_size = newWinSize + k_OutBufSize_Add;
    _win = (Byte *)z7_AlignedAlloc(alloc_size);
    if (!_win)
      return E_OUTOFMEMORY;
    memset(_win, 0, alloc_size);
  }
}
_winSize = newWinSize;

La función libera la ventana anterior, asigna la más pequeña y actualiza _winSize. No toca _pos. Un primer volumen comprimido con una ventana de 2 MB puede por tanto avanzar _pos mucho más allá de la ventana de 32 KB que declara un volumen posterior. Cuando llega la continuación, _pos conserva el desplazamiento mayor.

La comprobación de límites es la última línea del fragmento vulnerable. outSize y _winSize no tienen signo, y _pos es mayor que _winSize. La resta _winSize - _pos se desborda a un valor enorme, así que la comprobación pasa. El decodificador escribe entonces en _win + _pos, unos 1.3 MB más allá del inicio del búfer de 32 KB.

¿Cómo se explota?

Un par de volúmenes CAB manipulados lleva al decodificador a través de una ventana grande. Luego reduce la ventana y entrega un bloque de continuación que se decodifica en el desplazamiento obsoleto.

1. El atacante envía v1.cab y v2.cab. La víctima extrae v1.cab con 7-Zip.
2. v1.cab contiene carpetas comprimidas con una ventana LZX grande. Una carpeta avanza _pos hasta el desplazamiento elegido, y otra escribe un script de shell en el disco.
3. Una carpeta vacía declara una ventana de 32 KB. El decodificador libera el búfer de 2 MB, asigna un búfer de 32 KB y actualiza _winSize, pero _pos conserva el valor grande anterior.
4. v1.cab termina con un puntero de continuación a v2.cab. 7-Zip abre el segundo volumen y pasa su bloque comprimido al decodificador LZX con _keepHistory todavía verdadero.
5. La comprobación de límites se desborda y el decodificador escribe en _win + _pos, más allá de la asignación de 32 KB.
6. El exploit usa la preparación del montón para colocar un objeto COutFileStream en ese desplazamiento. La escritura fuera de límites sobrescribe su puntero de vtable y sus campos de tipo FILE.
7. La siguiente escritura a través del flujo corrupto pasa por una vtable FILE de glibc desplazada. Eso lleva a _IO_file_xsputn, que trata el objeto como un FILE * y sobrescribe la estructura real de la entrada estándar. La técnica House of Apple 2 lo convierte en una llamada a system("sh r"). El script que escribió el primer volumen ya está en el disco, y el atacante recibe una shell inversa.

El investigador probó la cadena en Arch Linux x86-64 con glibc 2.44 contra 7-Zip 26.04 y 26.05. El análisis describe una cadena completa.

Incluye una forma de ensamblar las direcciones de libc a partir de un puntero de arena del montón sin una fuga separada. Reporta cerca del 30 por ciento de éxito para una variante con reintentos. Los desplazamientos dependen de la versión de 7-Zip, la compilación de glibc y la disposición del montón. La demostración pública es Linux; el análisis no demuestra una cadena para Windows.

No se conoce explotación en entornos reales. El registro CVE y el análisis del investigador son los únicos informes públicos, y ninguno nombra una víctima ni una campaña.

¿Cómo se desarrolla el ataque?

Un primer volumen CAB avanza la posición de escritura LZX bajo una ventana grande. Un volumen posterior reduce la ventana sin reiniciar esa posición, y la decodificación de continuación escribe más allá del nuevo búfer. El exploit convierte esa escritura en ejecución de código.

¿Qué puede hacer un atacante?

Un atacante que consigue que la víctima extraiga el archivo manipulado ejecuta código con los privilegios del usuario que ejecuta 7-Zip. El análisis demuestra una shell inversa en Linux. El impacto depende de los privilegios de ese usuario y de la máquina.

Las condiciones forman parte del impacto:

• La víctima debe extraer el primer volumen con una compilación afectada de 7-Zip. Abrir el archivo en el gestor de archivos y listar su contenido no es el desencadenante demostrado; el exploit se ejecuta durante la extracción.
• El atacante debe entregar los dos volúmenes. El segundo volumen se abre automáticamente como continuación.
• El exploit está calibrado para una versión de 7-Zip, una glibc y una disposición del montón concretas. Otra compilación puede necesitar nuevos desplazamientos, y la demostración pública cubre Linux x86-64.
• El código se ejecuta con los privilegios del usuario que inició 7-Zip. Un usuario estándar obtiene sus archivos y sesiones. Un administrador que extrae el archivo entrega al atacante ejecución con sus privilegios.
• No se conoce explotación en entornos reales, y ningún informe público nombra una víctima.

Las cifras del análisis fijan la fiabilidad. Reporta 5 de 5 ejecuciones correctas con ASLR desactivado, y 19 de 64 (cerca del 30 por ciento) con ASLR activado para una variante. Un fallo termina con un error de extracción, así que los reintentos son gratuitos. Es un exploit funcional, no uno garantizado.

¿Por qué funciona la corrección?

La corrección reinicia la posición de escritura y el indicador de historial cada vez que el decodificador asigna una ventana nueva, y inicializa ambos campos en el constructor. Eso elimina el desplazamiento obsoleto que la comprobación de límites no detectaba.

Esta es la corrección del commit d3296e39e1f1f92c7b41c0c3848e65640428d42d:

 CDecoder::CDecoder() throw():
+    _pos(0),
     _win(NULL),
+    _overDict(false),
     _isUncompressedBlock(false),
@@
       z7_AlignedFree
         (_win);
       _winSize = 0;
+      _pos = 0;
+      _overDict = false;
       const size_t alloc_size = newWinSize + k_OutBufSize_Add;
       _win = (Byte *)

Set_DictBits_and_Alloc() ahora borra _pos y _overDict en el mismo bloque que libera el búfer anterior. Una reducción de ventana empieza por tanto la continuación en el desplazamiento cero del nuevo búfer, y la resta sin signo ya no puede desbordarse. La inicialización en el constructor también elimina el caso de valor sin inicializar en la primera asignación.

El cambio cierra la ruta demostrada. No cambia el formato del archivo ni la salida del decodificador, así que la extracción CAB multi-volumen normal sigue funcionando. Las notas de la versión 26.06 solo dicen que «se corrigieron algunos errores y vulnerabilidades»; el commit es la corrección concreta de esta CVE.

¿Cómo compruebo si estuve comprometido?

Ni el registro CVE ni el investigador han publicado indicadores de compromiso. El exploit está diseñado para dejar un script de shell y abrir una conexión de red, así que busque esos efectos en lugar de una firma.

• Busque archivos inesperados que aparecieron durante una extracción CAB, sobre todo un script de shell pequeño y muchos archivos pequeños de relleno. La cadena demostrada escribe un script llamado r y usa muchos archivos de relleno para preparar el montón.
• Revise las conexiones salientes de la máquina alrededor de la hora de la extracción, en particular las de 7z, 7zFM o un shell iniciado por ellos.
• Busque pares de archivos CAB entregados juntos, donde el primero nombra un volumen de continuación. Un CAB multi-volumen de una fuente que no es de confianza es el patrón de entrega.
• En un host que extrajo un CAB que no era de confianza, conserve el directorio extraído y los registros de procesos y de red antes de limpiar. Reconstruya después el host si no puede descartar la ejecución.

Un intento fallido puede no dejar rastro más allá de un error de extracción. La ausencia de un shell o de una conexión no demuestra que el archivo fuera inofensivo.

Cronología

• 2026-11-06: se publica 7-Zip 26.06 con el commit d3296e39e1f1f92c7b41c0c3848e65640428d42d, que reinicia _pos y _overDict al asignar la ventana.
• 2026-11-10 11:57 UTC: VulnCheck reserva CVE-2026-125742.
• 2026-11-10 12:00 UTC: VulnCheck publica el registro CVE y su aviso.
• 2026-11-10: Nguyễn Trần Thanh Lâm publica el análisis técnico y la demostración de explotación.

Preguntas frecuentes

¿Se explota CVE-2026-125742 en entornos reales?

No se conoce explotación. El registro CVE, el aviso de VulnCheck y el análisis del investigador describen una prueba de concepto funcional, no ataques. La CVE no está en el catálogo Known Exploited Vulnerabilities de CISA al 10 de noviembre de 2026.

¿Existe un exploit público?

Sí, un análisis técnico público describe la cadena completa e incluye vídeos de demostración. No enlaza un repositorio de código de exploit. El registro CVE marca el análisis como referencia de exploit, y el análisis reporta tasas de éxito medidas.

¿Afecta el fallo a 7-Zip en Windows, Linux y macOS?

El decodificador vulnerable es código fuente compartido. La demostración publicada se ejecuta en Linux x86-64, y el análisis dice que los desplazamientos necesitan calibración para cada versión de 7-Zip, glibc y disposición del montón. Windows usa otra biblioteca C, así que la cadena glibc exacta no se traslada, pero la escritura fuera de límites del decodificador sí. Actualice cada plataforma.

¿Se activa al abrir el archivo o solo al extraerlo?

El desencadenante demostrado es la extracción. El decodificador procesa el volumen de continuación mientras escribe los archivos extraídos. Listar el archivo es otra ruta y no se demostró como desencadenante.

¿Es seguro 7-Zip 26.06?

Sí para esta CVE. 26.06 contiene el commit de corrección y es la versión que el registro CVE indica como corregida. Revise por separado las copias incluidas, porque una aplicación que distribuye su propio código de 7-Zip no se actualiza al instalar 26.06.

¿Y si no puedo actualizar de inmediato?

No extraiga archivos CAB multi-volumen de fuentes que no sean de confianza y bloquéelos en la pasarela de correo. Si debe inspeccionar uno, use una máquina virtual o un contenedor desechable con un usuario sin privilegios. Esas medidas reducen la exposición; no corrigen el decodificador.

Referencias

• Registro CVE-2026-125742, VulnCheck como CNA, publicado el 10 de noviembre de 2026, con los vectores CVSS v4.0 8.5 y v3.1 7.8, CWE-787 y el rango afectado anterior a 26.06: https://www.cve.org/CVERecord?id=CVE-2026-125742 (comprobado el 10 de noviembre de 2026)
• Aviso de VulnCheck, «7-Zip before 26.06 Heap Out-of-Bounds Write via LZX Decoder in CAB Extraction», 10 de noviembre de 2026, con el crédito a Nguyễn Trần Thanh Lâm de la Nanyang Technological University: https://www.vulncheck.com/advisories/7-zip-before-26.06-heap-out-of-bounds-write-via-lzx-decoder-in-cab-extraction (comprobado el 10 de noviembre de 2026)
• Commit d3296e39e1f1f92c7b41c0c3848e65640428d42d de 7-Zip, la corrección que reinicia _pos y _overDict en Set_DictBits_and_Alloc(): https://github.com/ip7z/7zip/commit/d3296e39e1f1f92c7b41c0c3848e65640428d42d (comprobado el 10 de noviembre de 2026)
• Versión 26.06 de 7-Zip, indicada por el proveedor como 2026-11-06 (el objeto de versión de GitHub se creó el 2026-11-07): https://github.com/ip7z/7zip/releases/tag/26.06 (comprobado el 10 de noviembre de 2026)
• El código vulnerable Code_WithExceedReadWrite() y Set_DictBits_and_Alloc() en CPP/7zip/Compress/LzxDecoder.cpp en la etiqueta 26.05: https://github.com/ip7z/7zip/blob/26.05/CPP/7zip/Compress/LzxDecoder.cpp#L1444-L1513 (comprobado el 10 de noviembre de 2026)
• Nguyễn Trần Thanh Lâm, «7-Zip Cabinet Window Desync: From Heap OOB Write to Remote Code Execution», 10 de noviembre de 2026, el análisis de la causa raíz, la cadena de explotación y las tasas de éxito medidas: https://potion-brew.pages.dev/posts/7zip-cab-lzx-window-desync-rce (comprobado el 10 de noviembre de 2026)
• Página del paquete comunitario de Chocolatey para 7zip, 35,677,761 descargas totales y 6,087 descargas de la versión 26.6.0, comprobada el 10 de noviembre de 2026: https://community.chocolatey.org/packages/7zip (comprobado el 10 de noviembre de 2026)
• Fuente JSON del catálogo Known Exploited Vulnerabilities de CISA, consultada para CVE-2026-125742 sin coincidencia al 10 de noviembre de 2026: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (comprobado el 10 de noviembre de 2026)