zlib 1.4 : deux CVE corrigées dont un débordement de tampon dans gzwrite(), mettez à jour vos serveurs Linux

Le 4 novembre 2026, Mark Adler a publié zlib 1.4, la nouvelle version de la bibliothèque de compression la plus répandue du monde Linux. Ses notes de version contiennent une section « Security fixes » inhabituellement longue : un débordement de tampon dans gzwrite() en mode non bloquant (CVE-2026-85091), une écriture pouvant atteindre 8 Mo au-delà du tampon fourni par l'appelant dans inflateGetDictionary(), une arithmétique de pointeur hors limites dans le code optionnel contrib/infback9 (CVE-2026-4738), et une série de corrections dans minizip, inflateSync(), inflatePrime() ou deflatePrime(). Trois jours plus tard, Debian publiait le bulletin DSA-6613-1 pour Debian 13, et son suivi de sécurité rattache au même correctif de gzwrite() un troisième identifiant, CVE-2026-76844, qui couvre toutes les versions depuis zlib 1.2.11. zlib est chargée, en statique ou en dynamique, par OpenSSH, nginx, PHP, Python, Java, Git, les serveurs de jeu et quasiment toutes les images Docker. Pour qui administre un VPS Linux ou un serveur dédié, la question n'est pas « suis-je concerné » mais « où est ma copie de zlib, et quand arrive le paquet corrigé ».

Sources : zlib.net, notes de version de zlib 1.4, 4 novembre 2026 ; dépôt madler/zlib sur GitHub ; bulletin DSA-6613-1 de Debian, 7 novembre 2026 ; fiches CVE-2026-85091 et CVE-2026-76844 publiées par VulnCheck sur cve.org ; notice USN-8954-1 d'Ubuntu, 22 octobre 2026 ; fiche CVE de Red Hat ; trackers de sécurité Debian et Ubuntu, consultés le 9 novembre 2026.

zlib : la bibliothèque que tout le monde charge sans le savoir

zlib est une bibliothèque C qui implémente l'algorithme de compression DEFLATE et les formats zlib et gzip. Écrite par Jean-loup Gailly (compression) et Mark Adler (décompression), elle existe depuis 1995, et la dernière version avant la 1.4 était la 1.3.2 du 17 février 2026. Sur un serveur Linux, elle prend la forme d'une bibliothèque partagée, libz.so.1, fournie par le paquet zlib1g sur Debian et Ubuntu, zlib sur AlmaLinux 8 et 9 et Rocky Linux 8 et 9, zlib-ng-compat sur les versions 10 de ces distributions, et zlib sur Alpine. Tout programme qui compresse ou décompresse du gzip, lit un fichier PNG, ouvre une archive ZIP ou négocie la compression HTTP la charge. Le paquet openssh-server de Debian 13, par exemple, dépend explicitement de zlib1g.

Le point qui compte pour un administrateur : il n'y a pas une copie de zlib sur un serveur, il y en a souvent plusieurs. La bibliothèque partagée du système, mise à jour par apt ou dnf. Les copies embarquées dans les images Docker, une par image. Et les copies liées statiquement ou livrées avec un logiciel téléchargé hors des dépôts, que seule une nouvelle version de ce logiciel remplacera.

Les failles corrigées par zlib 1.4

Les notes de version de zlib 1.4 listent les corrections de sécurité suivantes. Deux portent un identifiant CVE, les autres sont référencées par les identifiants des audits de sécurité qui les ont signalées (préfixes TOB et THM). Nous y ajoutons les deux CVE que la DSA-6613-1 de Debian associe au même paquet : CVE-2026-76844, qui désigne le même défaut de gzwrite() sur une plage de versions plus large, et CVE-2026-27171, corrigée dès zlib 1.3.2.

Quelques précisions utiles pour évaluer l'urgence. CVE-2026-85091 ne se déclenche que sur un descripteur ouvert en mode non bloquant, quand une écriture interrompue est suivie d'un appel à gzprintf() ou gzvprintf() : le support des périphériques non bloquants dans les fonctions gz* n'est apparu qu'avec la version de développement 1.3.1.2 du 8 décembre 2025, d'où la plage étroite de la fiche CVE. CVE-2026-76844 décrit le même défaut sous un angle plus large : n'importe quel échec de write(), y compris un EPIPE sur un descripteur bloquant, suffit à laisser le pointeur obsolète en place, et sur les versions antérieures à 1.3.1.2 il faut en plus que le programme ait appelé gzclearerr() après l'échec. C'est ce second identifiant qui ramène Debian 12 (zlib 1.2.13) et les distributions restées en 1.2.11 dans le périmètre. Red Hat justifie sa note « Important » par le fait que zlib est liée dans d'innombrables services réseau et qu'une corruption mémoire dans une bibliothèque aussi partagée peut mener à l'exécution de code, tout en notant que les conditions de déclenchement élèvent la complexité de l'attaque. Le défaut d'inflateGetDictionary() n'a pas d'identifiant CVE mais concerne, lui, le code de décompression lui-même, présent dans toutes les versions 1.3.1 et 1.3.2. Quant à CVE-2026-4738, le code infback9 n'est pas compilé dans la bibliothèque partagée des distributions : il ne touche que les logiciels qui l'embarquent dans leurs sources, et le projet zlib précise que les pointeurs reviennent dans les limites avant d'être utilisés et qu'aucun compilateur connu ne gère mal ce cas, ce qui rend la note de 9,4 trompeuse en dehors des architectures à capacités de type CHERI.

Enfin, la version 1.4 apporte des changements incompatibles à connaître si vous compilez vous-même des logiciels : CMake 3.15 minimum, retour du type z_off_t à long par défaut (la 1.3.2 l'avait passé en 64 bits), nouveaux noms de bibliothèques sur MSVC, deflateReset() qui efface désormais l'en-tête gzip défini par deflateSetHeader(), et gzopen() avec le mode « x » qui échoue au lieu de tronquer le fichier quand O_EXCL n'est pas disponible. Les distributions gèrent ces points dans leurs paquets ; un administrateur qui installe zlib depuis les sources doit les lire avant de mettre à jour.

Quels services de votre serveur chargent zlib

Le tableau ci-dessous recense les logiciels les plus courants sur un VPS ou un serveur dédié ElypseCloud et la manière dont ils utilisent zlib. La colonne « comment se fait la mise à jour » est celle qui vous intéresse : elle dit si un simple apt upgrade suffit ou s'il faut attendre une autre livraison.

Un serveur de jeu est un cas typique : le processus Java d'un serveur Minecraft, lancé sous un hébergement Minecraft classique, charge libz.so.1 au démarrage et la garde en mémoire tant qu'il tourne. Mettre à jour le paquet sans redémarrer le serveur laisse l'ancienne bibliothèque chargée. Pour un serveur FiveM, la copie de zlib qui compte est celle de l'artifact FXServer, et non celle de la distribution hôte.

Vérifier la version de zlib installée

Commencez par repérer la bibliothèque partagée que le système charge réellement. Sur toutes les distributions, ldconfig liste les bibliothèques connues de l'éditeur de liens dynamique :

ldconfig -p | grep libz.so

La sortie donne le chemin de libz.so.1 ; un lien symbolique pointe vers le fichier réel, dont le nom contient la version compilée :

readlink -f /usr/lib/x86_64-linux-gnu/libz.so.1
# exemple de sortie : /usr/lib/x86_64-linux-gnu/libz.so.1.3.1

Le numéro de fichier n'est pas suffisant pour conclure : les distributions rétroportent les correctifs de sécurité dans la version existante sans changer ce nom. Debian 13 reste ainsi en libz.so.1.3.1 après la DSA-6613-1. Ce qui fait foi est la version du paquet, à comparer avec le bulletin de sécurité de votre distribution.

# Debian / Ubuntu
dpkg -l zlib1g
apt policy zlib1g

# AlmaLinux / Rocky Linux 8 et 9
rpm -q zlib

# AlmaLinux / Rocky Linux 10 (zlib-ng en mode compatible remplace zlib)
rpm -q zlib-ng-compat

# Alpine (hôte ou conteneur)
apk info zlib

Pour savoir quels processus en cours d'exécution ont chargé la bibliothèque, et surtout lesquels gardent en mémoire une ancienne copie après une mise à jour (le fichier apparaît alors marqué (deleted)) :

sudo lsof -n 2>/dev/null | grep 'libz.so' | awk '{print $1, $2}' | sort -u
sudo lsof -n 2>/dev/null | grep 'libz.so' | grep deleted

Dans une image Docker, répétez le contrôle à l'intérieur du conteneur, car l'hôte et le conteneur n'ont pas la même copie :

docker exec mon-conteneur sh -c 'apk info zlib 2>/dev/null || dpkg -s zlib1g 2>/dev/null | grep Version'

Pour un logiciel compilé à la main ou téléchargé en archive (un JDK, un binaire Go ou Rust, un serveur de jeu), ldd dit s'il charge la zlib du système ou s'il la transporte avec lui :

ldd /chemin/vers/le/binaire | grep libz
# aucune ligne : zlib est liée statiquement ou chargée depuis un répertoire privé

Où en sont Debian, Ubuntu, AlmaLinux, Rocky Linux et Alpine

Les distributions ne passent pas en zlib 1.4 du jour au lendemain : elles rétroportent les correctifs dans la version qu'elles livrent, à l'exception d'Alpine, qui a directement empaqueté la 1.4. Au 9 novembre 2026, voici l'état constaté sur les trackers et dépôts officiels. Il évoluera dans les jours qui viennent, et c'est précisément pour cela qu'il faut le suivre plutôt que de le supposer réglé.

Un détail à ne pas rater : la notice Ubuntu USN-8954-1 est sortie le 22 octobre, avant zlib 1.4, et ne cite que CVE-2026-85091. Le changelog du paquet Debian 13 corrigé ne mentionne que deux correctifs, celui de crc32_combine (CVE-2026-27171) et celui du gzwrite() non bloquant (CVE-2026-85091), que le suivi Debian considère aussi comme la correction de CVE-2026-76844. La correction d'inflateGetDictionary() n'y figure pas, et sans identifiant CVE elle n'apparaîtra dans aucun bulletin indexé par CVE tant qu'un n'aura pas été attribué. Suivre un seul numéro de CVE ne suffit donc pas ; abonnez-vous à la liste d'annonces de sécurité de votre distribution, ou vérifiez régulièrement :

# Debian / Ubuntu : mises à jour disponibles pour zlib
sudo apt update && apt list --upgradable 2>/dev/null | grep zlib

# AlmaLinux / Rocky Linux : errata liés à une CVE précise
sudo dnf updateinfo info --cve CVE-2026-85091
sudo dnf check-update zlib zlib-ng-compat

Si vous migrez une machine de Debian 12 vers Debian 13, le passage de zlib 1.2.13 à 1.3.1 corrigée se fait dans le même mouvement ; notre guide migrer un VPS de Debian 12 vers Debian 13 détaille la procédure. Et pour ne plus avoir à surveiller ces trackers à la main, automatiser les mises à jour de sécurité avec unattended-upgrades reste la réponse la plus simple sur Debian et Ubuntu.

Mettre à jour, puis redémarrer ce qui charge la bibliothèque

Une bibliothèque partagée n'est pas remplacée à chaud dans les processus qui l'ont déjà chargée. Après l'installation du paquet, chaque service qui utilisait l'ancienne libz.so.1 la garde en mémoire jusqu'à son redémarrage. Trois étapes, dans l'ordre.

1. Installer la mise à jour.

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade zlib1g

# AlmaLinux / Rocky Linux
sudo dnf upgrade zlib zlib-ng-compat

2. Lister les services à redémarrer. Sur Debian et Ubuntu, l'outil needrestart parcourt les processus et signale ceux qui chargent des bibliothèques obsolètes ; sur AlmaLinux et Rocky Linux, c'est dnf needs-restarting :

# Debian / Ubuntu
sudo apt install needrestart
sudo needrestart -r l

# AlmaLinux / Rocky Linux
sudo dnf needs-restarting

3. Redémarrer les services concernés, en commençant par ceux qui traitent des données venant du réseau :

sudo systemctl restart ssh        # sshd sur AlmaLinux / Rocky Linux
sudo systemctl reload nginx
sudo systemctl restart php8.3-fpm
sudo systemctl restart minecraft  # ou le nom de votre unité systemd

Redémarrer sshd ne coupe pas la session SSH en cours : les connexions établies restent gérées par leurs processus fils. Pour un serveur de jeu, prévenez les joueurs et choisissez une heure creuse, comme pour une mise à jour du noyau. Si votre serveur de jeu n'est pas encore déclaré en service systemd, c'est le moment de le faire : un service redémarre en une commande, un processus lancé dans un screen se perd.

Pour les conteneurs, la logique est différente : on ne met pas à jour un conteneur, on le remplace. Tirez les images de base mises à jour, reconstruisez vos propres images et recréez les conteneurs :

docker compose pull
docker compose build --pull
docker compose up -d

Sur un node Pterodactyl, les images de jeu (yolks) sont maintenues par le projet ; tirez leurs versions mises à jour avec docker pull, puis redémarrez les serveurs concernés pour qu'ils repartent sur la nouvelle image. Notre guide Docker Compose sur VPS Linux couvre le cycle de mise à jour des images, et nettoyer Docker avec prune évite de conserver des dizaines d'anciennes images vulnérables sur le disque.

Serveurs de jeu : trois cas concrets

Serveur Minecraft Java. Si Java vient du paquet openjdk-21-jre-headless de la distribution, il charge la zlib du système : mettez à jour zlib1g et redémarrez le serveur. Si vous avez installé un JDK depuis une archive, vérifiez avec ldd $JAVA_HOME/lib/libzip.so | grep libz : l'absence de ligne signifie que le JDK embarque sa propre zlib, et seule une nouvelle version du JDK la remplacera. Les serveurs Paper, Purpur, Forge et Fabric n'ont rien à mettre à jour eux-mêmes : ils s'appuient sur la zlib de Java.

Serveur FiveM ou RedM. L'artifact FXServer pour Linux est livré avec un environnement Alpine complet dans le répertoire alpine/, et run.sh lance le binaire avec ces bibliothèques. La zlib de l'hôte n'est pas celle que le serveur utilise. Surveillez les nouveaux artifacts recommandés et appliquez la procédure de notre guide sur les artifacts et le gamebuild FiveM.

Serveur Rust. Le serveur dédié Rust est installé par SteamCMD et embarque ses propres bibliothèques natives avec le moteur Unity. Là encore, le paquet de la distribution ne le concerne pas ; le correctif arrivera, s'il est nécessaire, dans une mise à jour du serveur, à installer en même temps que les mises à jour habituelles d'un serveur Rust.

Checklist pour l'administrateur

1. Identifiez la version du paquet zlib de chaque serveur (dpkg -l zlib1g, rpm -q zlib zlib-ng-compat) et comparez-la au bulletin de votre distribution.
2. Sur Debian 13, installez le paquet de la DSA-6613-1 (zlib1g 1:1.3.dfsg+really1.3.1-1+deb13u1). Sur Ubuntu 24.04, 26.04 et 26.10, vérifiez que le paquet de la USN-8954-1 est installé. Sur Debian 12, surveillez l'arrivée d'un bulletin. Sur AlmaLinux et Rocky Linux, interrogez dnf updateinfo.
3. Après chaque mise à jour, exécutez needrestart ou dnf needs-restarting et redémarrez sshd, le serveur web, PHP-FPM et vos serveurs de jeu.
4. Reconstruisez vos images Docker à partir d'images de base à jour (Alpine 3.21 à 3.23 livrent déjà zlib 1.4) et recréez les conteneurs ; sur Pterodactyl, tirez les yolks récents et redémarrez les serveurs.
5. Pour FiveM, RedM, Rust et les JDK installés en archive, mettez à jour le logiciel lui-même : la zlib qu'ils utilisent ne vient pas des dépôts.
6. Si vous compilez des logiciels contre zlib, lisez les changements incompatibles de la 1.4 (z_off_t, CMake 3.15, deflateReset()) avant de passer à cette version.
7. Profitez de l'occasion pour durcir SSH et appliquer les premiers réglages de sécurisation d'un serveur dédié : une faille de bibliothèque n'est exploitable qu'à travers un service qui reçoit des données non maîtrisées.

Conclusion

zlib 1.4 n'est pas une mise à jour à installer en urgence depuis les sources : c'est le signal que plusieurs défauts mémoire, dont le débordement de tampon de gzwrite() connu sous les identifiants CVE-2026-85091 et CVE-2026-76844, et une écriture hors limites dans inflateGetDictionary(), sont désormais publics et arrivent, correctif par correctif, dans les paquets de Debian, d'Ubuntu, d'Alpine, d'AlmaLinux et de Rocky Linux. Le travail de l'administrateur d'un VPS Linux ou d'un serveur dédié tient en trois gestes : savoir où sont ses copies de zlib, installer les paquets dès leur publication, et redémarrer ou recréer tout ce qui les charge. Une bibliothèque mise à jour sur le disque mais toujours chargée en mémoire protège exactement autant qu'avant, c'est-à-dire pas du tout.