Gzip 1.15 corrige des bugs présents depuis l’origine, dont un débordement de tampon en décompression LZH
La version 1.15 de gzip, publiée le 20 septembre 2026, corrige 119 commits de bugs dont un débordement de tampon et un accès à de la mémoire non initialisée présents depuis le début des années 1990. Mettez à jour gzip et traitez la décompression d’archives comme une entrée non fiable.
20 septembre 2026. Jim Meyering annonce gzip 1.15, une version stable. Avril 2025. La précédente, 1.14, avait été publiée dix-sept mois plus tôt. 1992. Le projet naît, et plusieurs des bugs corrigés aujourd’hui étaient déjà dans le code. Pourquoi c’est important : l’outil de compression le plus ubiquitaire du monde Unix portait, depuis plus de trois décennies, un débordement de tampon en décompression LZH et un accès à de la mémoire non initialisée sur des entrées malformées.
gzip est l’un des logiciels les plus anciens encore en usage quotidien. Créé en 1992 par Jean-loup Gailly et Mark Adler pour remplacer librement l’utilitaire compress, son nom est la contraction de GNU zip. Ses fichiers .gz, son association .tar.gz avec tar et l’encodage HTTP gzip sont aujourd’hui si profondément tissés dans l’informatique que l’on ne les remarque plus — ce qui explique pourquoi un bug présent depuis 1992 compte : il tourne, non corrigé, à l’échelle planétaire depuis trente-quatre ans.
Des bugs présents depuis l’origine
Le communiqué de gzip 1.15 est une leçon d’humilité logicielle. Il énumère des correctifs, chacun suivi de la même mention : « bug present since the beginning » — présent depuis l’origine. Certains sont des curiosités, d’autres des défauts de sécurité silencieux.
Parmi les curiosités, gzip pouvait supprimer le mauvais fichier si un autre processus renommait simultanément le répertoire parent de la destination. Une course à l’aveugle, corrigée après des décennies. gzip -d rejetait aussi certaines signatures PKZIP, des en-têtes locaux et des descripteurs de données qui apparaissent pourtant dans des fichiers zip en flux correctement formés. Et les diagnostics ne mettaient pas entre guillemets les noms de fichiers contenant des caractères inhabituels — un détail qui complique la vie de quiconque automatise sur des noms exotiques.
Mais deux correctifs relèvent de la sécurité au sens strict. Le premier : un accès à de la mémoire non initialisée sur certaines entrées malformées. Le second, le plus grave : un débordement de tampon lors de la décompression d’un fichier .lzh après un fichier .Z. Deux défauts de sûreté mémoire dans un outil que l’on invoque sans y penser, des millions de fois par jour.
Le débordement de tampon en décompression LZH
Le format LZH est un héritage de LHarc, un format d’archive populaire à la fin des années 1980. gzip sait le décompresser en plus de ses formats natifs .gz et du .Z de l’ancien programme compress. C’est précisément dans ce chemin de compatibilité, moins testé que le cœur du produit, que le débordement de tampon se logeait.
Le scénario d’exploitation est exigeant mais réel : il faut qu’un fichier .lzh soit décompressé juste après un fichier .Z dans la même session. L’état interne laissé par le premier format corrompt le traitement du second, et un fichier .lzh soigneusement construit peut écrire au-delà d’un tampon. En pratique, cela signifie qu’un utilisateur qui décompresse une archive malveillante — reçue par e-mail, téléchargée, ou placée dans un pipeline de traitement — expose le processus à une écriture hors limites.
Deux autres correctifs touchent le même format : la sortie d’un .lzh pouvait être corrompue quand un tampon de bits interne n’était pas correctement vidé, ou quand un fichier .lzh en suivait un autre dont la table de décodage persistait. Autrement dit, le support LZH de gzip était à la fois buggé et fragile depuis l’origine, et personne ne l’avait remarqué parce que personne ne teste plus sérieusement du LHarc en 2026.
119 commits, cinq personnes, soixante-quinze semaines
Le communiqué donne la mesure exacte de l’effort : 119 commits par 5 personnes en 75 semaines. Les contributeurs sont Bruno Haible (2 commits), Collin Funk (2), Jim Meyering (24), Mark Adler (3) et Paul Eggert (88). Ce dernier porte à lui seul les trois quarts du travail.
C’est la réalité de la maintenance des outils fondamentaux de GNU. gzip est présent sur pratiquement toutes les distributions Linux, dans les conteneurs, les serveurs, les routeurs et les systèmes embarqués. Il compresse les journaux, les sauvegardes, les archives de paquets. Et pourtant, sa maintenance tient sur cinq personnes, dont une qui assume l’essentiel des correctifs, sur plus d’un an et demi.
Le contraste est instructif. Un éditeur annonce un correctif de sécurité avec fanfare ; un mainteneur de gzip publie une version stable qui élimine silencieusement un débordement de tampon vieux de trente ans, sans CVE, sans bulletin, sans urgence médiatisée. Le risque est réel, la discrétion totale.
Pourquoi la décompression reste une surface d’attaque
Le correctif de gzip 1.15 illustre une règle que les équipes de sécurité connaissent mais appliquent rarement jusqu’au bout : décompresser une archive, c’est exécuter du code non fiable. Les formats de compression sont des parseurs, et les parseurs sont des surfaces d’attaque. Le débordement LZH de gzip est de la même famille que les failles régulièrement découvertes dans zlib, libarchive, 7-Zip ou les décompresseurs intégrés aux navigateurs.
La conséquence pratique dépasse la mise à jour de gzip lui-même. Tout pipeline qui décompresse des données d’origine externe — un upload utilisateur, un artefact de build téléchargé, une sauvegarde restaurée — exécute potentiellement un parseur vulnérable sur une entrée contrôlée par un tiers. La défense passe par l’isolation de ces étapes (conteneur dédié, utilisateur sans privilège, limites de ressources) et par la mise à jour systématique de tous les décompresseurs, pas seulement du plus visible.
Pour les administrateurs, la mise à jour est simple mais à ne pas différer : gzip 1.15 arrive dans les dépôts des distributions dans les jours ou semaines qui suivent. Les serveurs qui décompressent des archives issues d’Internet doivent être prioritaires, tout comme les machines qui traitent des pièces jointes.
L’historique confirme le risque. En 2022, zlib — la bibliothèque qui se trouve sous le format même de gzip — corrigeait CVE-2022-37434, un débordement de tampon sur le tas dans inflate, atteignable via des données compressées malformées. Fin 2024, 7-Zip corrigeait CVE-2024-11477, un débordement d’entier dans son décompresseur Zstandard permettant une exécution de code à distance via une archive construite. Aucun des deux n’est exotique : ce sont les décompresseurs qui s’exécutent chaque fois qu’un système, un gestionnaire de paquets ou un utilisateur décompresse un fichier en supposant que la compression est sûre.
Ce qui change au-delà des bugs
Deux changements de comportement accompagnent les correctifs. D’abord, gzip ne suppose plus la locale C par défaut : il suit désormais la variable d’environnement de locale pour la façon dont il cite les noms de fichiers. Un changement mineur pour l’utilisateur, mais révélateur d’une attention portée aux environnements non anglophones.
Ensuite, la version abandonne le support de plateformes historiques : FreeBSD 4.11, HP-UX 11.00, Minix 3.1.8 et Windows 8.1 via MinGW sans UCRT. Alléger la matrice de support, c’est réduire la surface de code à maintenir et à tester — un choix de mainteneur cohérent avec un projet porté par cinq personnes.
Ces deux changements signalent une même direction : gzip se recentre sur ce qui compte, la fiabilité du format et des plateformes encore utilisées, plutôt que sur la compatibilité muséale.
Verdict
Si vous administrez des serveurs Linux, mettez à jour gzip dès que la 1.15 atteint vos dépôts, en priorité sur les machines qui décompressent des archives d’origine externe — serveurs de messagerie, pipelines de build, points de restauration. Si vous écrivez du code qui manipule des archives, traitez la décompression comme une frontière d’entrée non fiable : isolez-la, limitez ses ressources, et ne faites jamais confiance à un fichier sous prétexte qu’il est « juste compressé ». Si vous dépendez d’un outil GNU fondamental, rappelez-vous que sa maintenance repose sur une poignée de personnes, souvent bénévoles : financer ou contribuer à ces projets est une mesure de sécurité à part entière.