zlib 1.4: Mehr als ein Dutzend Sicherheitskorrekturen, auch für minizip
zlib 1.4 vom 4. November 2026 behebt mehr als ein Dutzend Sicherheitsfehler, darunter den Pufferüberlauf CVE-2026-85091 in gzwrite und mehrere Fehler in minizip. Für Server zählen vor allem die Updates der Distributionen, für Entwickler Änderungen an z_off_t und den Bibliotheksnamen. Berichte über Angriffe auf zlib selbst gibt es bisher nicht.
Mark Adler hat zlib 1.4 veröffentlicht. Die Release-Notes tragen das Datum 4. November 2026, auf GitHub erschien das Release am 5. November. Die neue Version der Kompressionsbibliothek enthält mehr als ein Dutzend Sicherheitskorrekturen, darunter einen Pufferüberlauf in gzwrite() mit der Kennung CVE-2026-85091 und mehrere Fehler in minizip, darunter Pfadfehler, über die präparierte ZIP-Archive Verzeichnisse außerhalb des Zielordners und unter Windows Dateien an beliebigen Orten anlegen konnten.
zlib steckt in nahezu jedem Linux-System, in Programmiersprachen, Datenbanken, Browsern und vielen Anwendungen, die die Bibliothek fest einbinden. Für die meisten Betreiber heißt das: Updates der Distribution abwarten und zeitnah einspielen. Berichte über Angriffe auf zlib selbst nennen die Quellen nicht. Mehr Aufmerksamkeit brauchen Entwickler und alle, die Software mit eigener zlib-Kopie oder mit minizip betreiben.
Was ist passiert?
Die Release-Notes nennen als Herkunft der Funde unter anderem Trail of Bits, Theorem und mehrere einzelne Melder. Einen Fehler in gzseek() führt das Projekt auf das KI-Modell Claude Opus 5.5 zurück. Behoben sind unter anderem:
gzwrite()im nicht blockierenden Modus mit Pufferüberlauf (CVE-2026-85091, im GitHub-Advisory mit CVSS 3.1 7.4 als hoch bewertet). Das Advisory ist seit dem 3. September 2026 öffentlich.inflateGetDictionary()konnte bis zu 8 MB hinter einen 32-KB-Puffer schreiben, laut Projekt betrifft das 1.3.1 und 1.3.2.- Fehler in
inflateSync(),inflatePrime(),deflatePrime(),inflateBack()unddeflateResetKeep(), die zu Schreib- oder Lesezugriffen außerhalb von Puffern oder zu nicht initialisiertem Speicher in der Ausgabe führten. - In minizip ein Double Free, eine NULL-Dereferenz, fehlerhafte Zip64-Auswertung sowie Pfade, mit denen miniunz Verzeichnisse außerhalb des Zielordners und unter Windows Dateien an beliebigen Orten anlegen konnte.
Wer ist betroffen?
Betroffen sind ältere zlib-Versionen, je nach Fehler unterschiedlich weit zurück. Für CVE-2026-85091 nennt das GitHub-Advisory die Stände 1.3.1.2 bis 1.3.2, wobei 1.3.1.2 ein Entwicklungsstand ist. Die CVE-2026-4738 betrifft nur den Zusatzcode contrib/infback9; das Projekt schreibt selbst, die Einstufung als kritisch überzeichne das Risiko. Die minizip-Fehler betreffen nur Software, die minizip nutzt, vor allem zum Verarbeiten fremder Archive.
Wie kritisch ist das?
Nach Einschätzung von S-EDV setzen die meisten Fehler eine bestimmte Nutzung der API oder präparierte Daten voraus, die eine Anwendung verarbeitet. Ob sich daraus in einer konkreten Software Codeausführung ergibt, hängt von deren Umgang mit zlib ab. Am ehesten von außen erreichbar sind die Archivfehler in minizip. Wichtig für Entwickler: 1.4 enthält Änderungen mit Bruchgefahr. z_off_t ist ohne weitere Vorgaben wieder long statt long long, Windows-Anwendungen mit Headern aus 1.3.2 sollen neu kompiliert werden, und unter MSVC heißen die Bibliotheken jetzt libz.
Was sollten Admins jetzt tun?
- Inventar: Paketstand von zlib auf den Servern erfassen und die Sicherheitsupdates der Distribution verfolgen.
- Anwendungen mit eigener, statisch eingebundener zlib oder minizip identifizieren, etwa mit einem SBOM- oder Image-Scanner, und auf Updates der Hersteller achten.
- Container-Images nach Erscheinen der Distributionspakete neu bauen.
- Software, die fremde ZIP-Archive mit minizip entpackt, vorrangig aktualisieren.
- Eigene Builds auf 1.4 umstellen und die Hinweise zu
z_off_t,deflateReset()und den CMake-Namen vorher testen.
Einordnung für Unternehmen
zlib 1.4 ist kein Notfall, aber ein Update mit großer Reichweite, weil die Bibliothek tief in Drittsoftware steckt. Der Aufwand liegt weniger beim Paketupdate als beim Auffinden versteckter Kopien in Anwendungen und Images. Wer ohnehin Software-Stücklisten pflegt, ist hier klar im Vorteil.
Passende Anleitungen auf S-EDV
- Automatische Sicherheitsupdates unter Debian/Ubuntu mit unattended-upgrades richtig konfigurieren
- Docker-Images auf Schwachstellen scannen mit Trivy: CVE-Check, SBOM und automatische Scans im KMU-Workflow
