7-Zip : débordement de tas LZX et RCE via une archive CAB piégée (CVE-2026-125742)

En bref

• Un débordement de tas dans le décodeur LZX de 7-Zip permet à une archive CAB multi-volume piégée d'exécuter du code à l'extraction. La fenêtre LZX peut rétrécir entre deux volumes alors que le décodeur garde un décalage périmé.
• Les versions de 7-Zip antérieures à 26.06 sont concernées. La faille est dans le décodeur, donc elle touche les versions Windows, Linux et macOS qui partagent ce code.
• L'enregistrement CVE la note 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, et CWE-787. Aucune exploitation dans la nature n'est connue, et CVE-2026-125742 ne figure pas au catalogue Known Exploited Vulnerabilities (KEV) de la CISA au 10 novembre 2026.
• Mettez à jour vers 7-Zip 26.06, publié le 6 novembre 2026, et n'extrayez pas d'archives CAB multi-volume non fiables tant que chaque copie n'est pas à jour. Voir « Comment corriger ? ».

Suis-je concerné ?

Toutes ces conditions doivent être réunies :

• Vous utilisez 7-Zip antérieur à 26.06. La plage concernée dans l'enregistrement CVE est toutes les versions avant 26.06.
• L'attaquant peut vous faire extraire une archive CAB multi-volume piégée avec 7-Zip, par courriel, par un partage de fichiers ou par un téléchargement.
• L'extraction utilise le décodeur LZX de 7-Zip, qui est celui par défaut pour les dossiers CAB compressés en LZX. Un autre archiveur peut embarquer un code différent.

L'enregistrement CVE donne la plage de versions de « 0 » à « 26.06 » exclu. Le correctif est dans le code source 26.06 et dans la version 26.06 publiée le 6 novembre 2026. La faille se trouve dans CPP/7zip/Compress/LzxDecoder.cpp, partagé par les versions officielles.

Vérifiez la version installée depuis un terminal :

7zz i | head -n 3

Sous Windows, l'exécutable console est 7z, donc lancez 7z i dans PowerShell ou l'invite de commandes ; l'application graphique affiche la version dans Aide, puis À propos de 7-Zip. Les versions officielles Linux et macOS installent 7zz. Chocolatey et Windows Package Manager indiquent le paquet installé :

choco list 7zip
winget list 7zip.7zip

Si la ligne de version indique 26.05 ou une version antérieure, l'installation est concernée. Une installation 26.06 est corrigée pour cette CVE.

Comment corriger ?

Mettez à jour 7-Zip vers 26.06 sur chaque machine qui extrait des archives non fiables.

1. Sous Windows, installez la version 26.06 depuis la page de téléchargement officielle, ou utilisez un gestionnaire de paquets : winget upgrade 7zip.7zip choco upgrade 7zip -y
2. Sous Linux, utilisez le paquet de votre distribution quand il fournit 26.06. Sinon, installez la version Linux officielle depuis 7-zip.org. Confirmez la version avec 7zz i.
3. Sous macOS, installez la version macOS 26.06 depuis la page de téléchargement officielle et confirmez la version avec 7zz i.
4. Vérifiez les logiciels qui embarquent leur propre copie de 7-Zip, comme les installateurs et les gestionnaires d'archives. Mettre à jour le 7-Zip du système ne met pas à jour une copie embarquée.

Aucun commutateur de configuration ne désactive le chemin LZX vulnérable tout en conservant l'extraction CAB. Tant que chaque copie n'est pas à jour, traitez les archives CAB multi-volume comme du code non fiable :

1. N'extrayez pas d'archives CAB reçues par courriel ou depuis un téléchargement non fiable.
2. Si vous devez en inspecter une, extrayez-la dans une machine virtuelle ou un conteneur jetable avec un utilisateur non privilégié.
3. Bloquez les pièces jointes CAB multi-volume à la passerelle de messagerie. Cela réduit l'exposition ; cela ne corrige pas le décodeur.

Quelle est la cause racine ?

Le décodeur conserve une position d'écriture _pos pour sa fenêtre LZX, et il ne remet cette position à zéro qu'à la frontière d'une fenêtre lorsqu'il continue une archive multi-volume. Un volume ultérieur peut demander une fenêtre plus petite, et le redimensionnement libère l'ancien tampon sans réinitialiser _pos.

Voici la logique de continuation vulnérable dans Code_WithExceedReadWrite() à 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 vaut vrai quand le décodeur continue dans la cabine suivante. _pos est le décalage d'écriture courant, _winSize la taille courante de la fenêtre et _win le tampon de la fenêtre. Sur une archive neuve, _pos est remis à zéro. Sur une continuation, il n'est remis à zéro que lorsqu'il vaut exactement _winSize.

Le redimensionnement se produit dans 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 fonction libère l'ancienne fenêtre, alloue la plus petite, puis met à jour _winSize. Elle ne touche pas à _pos. Un premier volume compressé avec une fenêtre de 2 Mo peut donc avancer _pos bien au-delà de la fenêtre de 32 Ko qu'un volume ultérieur déclare. À l'arrivée de la continuation, _pos contient encore le grand décalage.

La vérification des limites est la dernière ligne de l'extrait vulnérable. outSize et _winSize sont non signés, et _pos est supérieur à _winSize. La soustraction _winSize - _pos déborde vers une valeur énorme, donc la vérification passe. Le décodeur écrit alors à _win + _pos, soit environ 1,3 Mo après le début du tampon de 32 Ko.

Comment la faille est-elle exploitée ?

Une paire de volumes CAB piégés fait passer le décodeur par une grande fenêtre, rétrécit la fenêtre, puis livre un bloc de continuation décodé au décalage périmé.

1. L'attaquant envoie v1.cab et v2.cab. La victime extrait v1.cab avec 7-Zip.
2. v1.cab contient des dossiers compressés avec une grande fenêtre LZX. Un dossier avance _pos jusqu'au décalage choisi, et un autre écrit un script shell sur le disque.
3. Un dossier vide déclare une fenêtre de 32 Ko. Le décodeur libère le tampon de 2 Mo, alloue un tampon de 32 Ko et met à jour _winSize, mais _pos garde l'ancienne grande valeur.
4. v1.cab se termine par un pointeur de continuation vers v2.cab. 7-Zip ouvre le second volume et transmet son bloc compressé au décodeur LZX avec _keepHistory toujours vrai.
5. La vérification des limites déborde et le décodeur écrit à _win + _pos, au-delà de l'allocation de 32 Ko.
6. L'exploit utilise le façonnage du tas pour placer un objet COutFileStream à ce décalage. L'écriture hors limites écrase son pointeur de vtable et ses champs de type FILE.
7. L'écriture suivante via le flux corrompu passe par une vtable FILE de glibc décalée. Cela mène à _IO_file_xsputn, qui traite l'objet comme un FILE *, écrase la structure réelle de l'entrée standard, et la technique House of Apple 2 transforme cela en appel à system("sh r"). Le script écrit par le premier volume est déjà sur le disque, et l'attaquant reçoit un reverse shell.

Le chercheur a testé la chaîne sur Arch Linux x86-64 avec glibc 2.44 contre 7-Zip 26.04 et 26.05. L'analyse décrit une chaîne complète.

Elle inclut une manière d'assembler les adresses libc à partir d'un pointeur d'arène du tas sans fuite séparée. Elle rapporte environ 30 pour cent de réussite pour une variante avec des tentatives répétées. Les décalages dépendent de la version de 7-Zip, de la compilation de glibc et de la disposition du tas. La démonstration publique est sous Linux ; l'analyse ne démontre pas de chaîne Windows.

Aucune exploitation dans la nature n'est connue. L'enregistrement CVE et l'analyse du chercheur sont les seuls rapports publics, et aucun ne nomme de victime ni de campagne.

Comment se déroule l'attaque ?

Un premier volume CAB avance la position d'écriture LZX sous une grande fenêtre. Un volume ultérieur rétrécit la fenêtre sans réinitialiser cette position, et le décodage de continuation écrit au-delà du nouveau tampon. L'exploit transforme cette écriture en exécution de code.

Que peut faire un attaquant ?

Un attaquant qui obtient l'extraction de l'archive piégée exécute du code avec les droits de l'utilisateur qui lance 7-Zip. L'analyse démontre un reverse shell sous Linux. L'impact dépend des privilèges de cet utilisateur et de la machine.

Les conditions font partie de l'impact :

• La victime doit extraire le premier volume avec une version concernée de 7-Zip. Ouvrir l'archive dans le gestionnaire de fichiers et lister son contenu n'est pas le déclencheur démontré ; l'exploit s'exécute pendant l'extraction.
• L'attaquant doit livrer les deux volumes. Le second volume est ouvert automatiquement comme continuation.
• L'exploit est calibré pour une version de 7-Zip, une glibc et une disposition de tas précises. Une autre compilation peut nécessiter de nouveaux décalages, et la démonstration publique couvre Linux x86-64.
• Le code s'exécute avec les droits de l'utilisateur qui a lancé 7-Zip. Un utilisateur standard obtient ses fichiers et ses sessions. Un administrateur qui extrait l'archive donne à l'attaquant une exécution avec ses droits.
• Aucune exploitation dans la nature n'est connue, et aucun rapport public ne nomme de victime.

Les chiffres de l'analyse fixent la fiabilité. Elle rapporte 5 réussites sur 5 avec ASLR désactivé, et 19 sur 64 (environ 30 pour cent) avec ASLR activé pour une variante. Un échec se termine par une erreur d'extraction, donc les tentatives sont gratuites. C'est un exploit fonctionnel, pas un exploit garanti.

Pourquoi le correctif fonctionne-t-il ?

Le correctif remet à zéro la position d'écriture et l'indicateur d'historique chaque fois que le décodeur alloue une nouvelle fenêtre, et il initialise les deux champs dans le constructeur. Cela supprime le décalage périmé que la vérification des limites n'attrapait pas.

Voici le correctif du 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() efface désormais _pos et _overDict dans le même bloc qui libère l'ancien tampon. Un rétrécissement de fenêtre démarre donc la continuation à l'offset zéro dans le nouveau tampon, et la soustraction non signée ne peut plus déborder. L'initialisation dans le constructeur supprime aussi le cas de valeur non initialisée lors de la première allocation.

Le changement ferme le chemin démontré. Il ne modifie ni le format d'archive ni la sortie du décodeur, donc l'extraction CAB multi-volume ordinaire continue de fonctionner. Les notes de version 26.06 indiquent seulement que « certains bogues et vulnérabilités ont été corrigés » ; le commit est le correctif précis de cette CVE.

Comment vérifier si j'ai été compromis ?

Ni l'enregistrement CVE ni le chercheur n'ont publié d'indicateurs de compromission. L'exploit est conçu pour laisser un script shell et ouvrir une connexion réseau ; cherchez donc ces effets plutôt qu'une signature.

• Cherchez des fichiers inattendus apparus pendant une extraction CAB, notamment un petit script shell et de nombreux petits fichiers de remplissage. La chaîne démontrée écrit un script nommé r et utilise beaucoup de fichiers de remplissage pour façonner le tas.
• Examinez les connexions sortantes de la machine autour de l'heure de l'extraction, en particulier celles de 7z, 7zFM ou d'un shell lancé par eux.
• Cherchez des paires de fichiers CAB livrées ensemble, où le premier nomme un volume de continuation. Une archive CAB multi-volume venue d'une source non fiable est le schéma de livraison.
• Sur un hôte qui a extrait une archive CAB non fiable, conservez le répertoire extrait et les journaux de processus et de réseau avant le nettoyage. Reconstruisez ensuite l'hôte si vous ne pouvez pas écarter une exécution.

Une tentative échouée peut ne laisser aucune trace au-delà d'une erreur d'extraction. L'absence de shell ou de connexion ne prouve pas que l'archive était inoffensive.

Chronologie

• 2026-11-06 : 7-Zip 26.06 est publié avec le commit d3296e39e1f1f92c7b41c0c3848e65640428d42d, qui remet _pos et _overDict à zéro lors de l'allocation de la fenêtre.
• 2026-11-10 11:57 UTC : VulnCheck réserve CVE-2026-125742.
• 2026-11-10 12:00 UTC : VulnCheck publie l'enregistrement CVE et son avis.
• 2026-11-10 : Nguyễn Trần Thanh Lâm publie l'analyse technique et la démonstration d'exploitation.

FAQ

CVE-2026-125742 est-elle exploitée dans la nature ?

Aucune exploitation n'est connue. L'enregistrement CVE, l'avis VulnCheck et l'analyse du chercheur décrivent une preuve de concept fonctionnelle, pas des attaques. La CVE ne figure pas au catalogue Known Exploited Vulnerabilities de la CISA au 10 novembre 2026.

Existe-t-il un exploit public ?

Oui, une analyse technique publique décrit la chaîne complète et inclut des vidéos de démonstration. Elle ne renvoie pas vers un dépôt de code d'exploit. L'enregistrement CVE classe l'analyse comme référence d'exploit, et l'analyse rapporte des taux de réussite mesurés.

La faille touche-t-elle 7-Zip sous Windows, Linux et macOS ?

Le décodeur vulnérable est un code source partagé. La démonstration publiée tourne sous Linux x86-64, et l'analyse indique que les décalages doivent être calibrés pour chaque version de 7-Zip, de glibc et de disposition du tas. Windows utilise une autre bibliothèque C, donc la chaîne glibc exacte ne se transpose pas, mais l'écriture hors limites dans le décodeur reste. Mettez à jour chaque plateforme.

Est-ce l'ouverture de l'archive qui déclenche la faille, ou seulement l'extraction ?

Le déclencheur démontré est l'extraction. Le décodeur traite le volume de continuation pendant qu'il écrit les fichiers extraits. Lister l'archive est un autre chemin, qui n'a pas été démontré comme déclencheur.

7-Zip 26.06 est-il sûr ?

Oui pour cette CVE. 26.06 contient le commit de correction et c'est la version que l'enregistrement CVE donne comme corrigée. Vérifiez séparément les copies embarquées, car une application qui livre son propre code 7-Zip n'est pas mise à jour par l'installation de 26.06.

Et si je ne peux pas mettre à jour immédiatement ?

N'extrayez pas d'archives CAB multi-volume de sources non fiables, et bloquez-les à la passerelle de messagerie. Si vous devez en inspecter une, utilisez une machine virtuelle ou un conteneur jetable avec un utilisateur non privilégié. Ces mesures réduisent l'exposition ; elles ne corrigent pas le décodeur.

Références

• Enregistrement CVE-2026-125742, VulnCheck comme CNA, publié le 10 novembre 2026, avec les vecteurs CVSS v4.0 8.5 et v3.1 7.8, CWE-787 et la plage concernée avant 26.06 : https://www.cve.org/CVERecord?id=CVE-2026-125742 (vérifié le 10 novembre 2026)
• Avis VulnCheck, « 7-Zip before 26.06 Heap Out-of-Bounds Write via LZX Decoder in CAB Extraction », 10 novembre 2026, avec le crédit à 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 (vérifié le 10 novembre 2026)
• Commit d3296e39e1f1f92c7b41c0c3848e65640428d42d de 7-Zip, le correctif qui remet _pos et _overDict à zéro dans Set_DictBits_and_Alloc() : https://github.com/ip7z/7zip/commit/d3296e39e1f1f92c7b41c0c3848e65640428d42d (vérifié le 10 novembre 2026)
• Version 26.06 de 7-Zip, indiquée par le vendeur au 6 novembre 2026 (l'objet de version GitHub a été créé le 7 novembre 2026) : https://github.com/ip7z/7zip/releases/tag/26.06 (vérifié le 10 novembre 2026)
• Le code vulnérable Code_WithExceedReadWrite() et Set_DictBits_and_Alloc() dans CPP/7zip/Compress/LzxDecoder.cpp à l'étiquette 26.05 : https://github.com/ip7z/7zip/blob/26.05/CPP/7zip/Compress/LzxDecoder.cpp#L1444-L1513 (vérifié le 10 novembre 2026)
• Nguyễn Trần Thanh Lâm, « 7-Zip Cabinet Window Desync: From Heap OOB Write to Remote Code Execution », 10 novembre 2026, l'analyse de la cause racine, la chaîne d'exploitation et les taux de réussite mesurés : https://potion-brew.pages.dev/posts/7zip-cab-lzx-window-desync-rce (vérifié le 10 novembre 2026)
• Page du paquet communautaire Chocolatey pour 7zip, 35 677 761 téléchargements au total et 6 087 téléchargements de la version 26.6.0, vérifiée le 10 novembre 2026 : https://community.chocolatey.org/packages/7zip (vérifié le 10 novembre 2026)
• Flux JSON du catalogue Known Exploited Vulnerabilities de la CISA, recherché pour CVE-2026-125742 sans correspondance au 10 novembre 2026 : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 10 novembre 2026)