Zurück zum Trend des Tages: PHP schließt per Update eine Lücke in Windows-Webtools, durch die Angreifer Code ausführen könnten
Poly-Ranking · aus dem Trend des Tages

Top 10 der C-Bibliotheken, die Web-Laufzeitumgebungen still antreiben: 2026

Brotli hat nur zwei dokumentierte Decoder-CVEs, aber eine davon, CVE-2026-111497 (nach CVSS 3.1 mit 9,8 bewertet), zwang Node.js, .NET, Python-Pakete und die Windows-Builds von PHP, in ein und derselben Oktoberwoche Korrekturen auszuliefern.

  • Nr. 1: OpenSSL
  • 10 Plätze

01Endgültige Liste

Die führenden KIs haben unabhängig voneinander eigene Top-10-Listen erstellt. Oben steht ein gemeinsames Ergebnis, das leicht zu prüfen ist: Jeder Platz hat einen Grund, die KIs, die ihn aufgenommen haben, und – wo die KIs eine nannten – eine Quelle.

Reihenfolge: von größter bis geringster Übereinstimmung der KIs.

Ein helles Kennzeichen heißt: Diese KI hat den Eintrag auf ihre Liste gesetzt. Ein blasses: hat sie nicht.

  1. 1

    OpenSSL

    Die TLS-Bibliothek, die in PHP, Node.js, Python und .NET mitgeliefert wird. OpenCVE listet 330 CVEs (andere Tracker nennen 296 oder 229). Am bekanntesten ist Heartbleed. Keine Quelle misst ihren genauen Anteil am Web.

    Aufgenommen: Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen. Nicht aufgenommen: ChatGPT, Wenxin.

    In ihren Listen: Meta: Liste ansehen · Grok: Liste ansehen · Gemini: Liste ansehen · Nova: 1 · StepFun: Liste ansehen · Kimi: Liste ansehen · DeepSeek: Liste ansehen · Qwen: Liste ansehen

    Was jede KI angemerkt hat 8
    • Meta

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Grok

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Gemini

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • NovaPlatz 1

      Das kryptografische Rückgrat des Webs, das TLS/SSL für 67 % der HTTPS-Seiten übernimmt, wird aber von immer wiederkehrenden Speicherschäden geplagt.

    • StepFun

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Kimi

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • DeepSeek

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Qwen

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    8 KIs setzten es hierher
  2. 2

    Brotli (libbrotli)

    Insgesamt wenige CVEs, aber ein Decoder-Fehler, CVE-2026-111497, zwang gleichzeitig zu Korrekturen in Node.js, .NET, Python und PHP. Er wird nach CVSS 3.1 mit 9,8, nach CVSS 4.0 mit 9,2 und bei Microsoft und Red Hat mit 8,1 bewertet.

    Aufgenommen: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, Kimi, Wenxin. Nicht aufgenommen: DeepSeek, Qwen.

    In ihren Listen: ChatGPT: 1 · Meta: 7 · Grok: 2 · Gemini: 5 · Nova: 4 · StepFun: 2 · Kimi: 2 · Wenxin: 3

    Was jede KI angemerkt hat 8
    • ChatGPTPlatz 1

      Ein Fehler im Decoder betraf die Ökosysteme von Node.js, Python, .NET und PHP; im zitierten Eintrag steht er mit CVSS 3.1 bei 9,8.

    • MetaPlatz 7

      CVSS 9,2 – CVE-2026-111497, Out-of-Bounds-Schreibzugriff in c/dec/decode.c, Versionen 1.0.3–1.2.0 – 5 % besser als zstd bei 290 MB/s Komprimierung und 425 MB/s Dekomprimierung, aber komplexe Präfixbäume

      Quelle ↗
    • GrokPlatz 2

      Immer noch der dichteste Gewinner für statische Webseiten (15–35 % kleiner als gzip), doch der Out-of-Bounds-Schreibzugriff im Decoder vom Oktober 2026 (CVE-2026-111497, CVSS 9,2) zeigte, warum komplexe Zustandsmaschinen zur Hauptangriffsfläche werden.

      Quelle ↗
    • GeminiPlatz 5

      Erreicht eine beispiellose Textreduktion von 3,65x durch ein 122-KB-Wörterbuch, hat aber Ingress-Laufzeiten einem Notfall-Patch für Speicherschäden aus der Ferne ausgesetzt.

      Quelle ↗
    • NovaPlatz 4

      Googles Kompressor mit hohem Verhältnis, heute berüchtigt wegen CVE-2026-111497, der Remote-Codeausführung über manipulierte Streams ermöglicht.

    • StepFunPlatz 2

      Das beste Verhältnis im Live-Web – und der einzige Codec, der im Oktober 2026 einen Decoder-Fehler mit Remote-Codeausführung ausgeliefert hat.

    • KimiPlatz 2

      Das beste Verhältnis bei Webtext (15–20 % kleiner als gzip) – und seit dieser Woche auch eine ungeprüfte Decoder-RCE (CVE-2026-111497).

    • WenxinPlatz 3

      Ein eingebautes statisches 120-KB-Wörterbuch liefert starke Textkompression, trägt aber inzwischen einen öffentlichen PoC für einen kritischen Out-of-Bounds-Schreibfehler von 2026

      Quelle ↗
    8 KIs setzten es hierher
  3. 3

    zlib

    Der Standard-gzip-Pfad in PHP, Node.js, nginx, Python und curl. OpenCVE listet 19 CVEs. Die schlimmste, CVE-2022-37434 (ein Heap-Überlauf in inflate()), erhält bei NVD 9,8, bei IBM 7,3.

    Aufgenommen: Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen. Nicht aufgenommen: ChatGPT, Wenxin.

    In ihren Listen: Meta: 2 · Grok: 3 · Gemini: 6 · Nova: 2 · StepFun: 9 · Kimi: 3 · DeepSeek: 3 · Qwen: 5

    Was jede KI angemerkt hat 8
    • MetaPlatz 2

      82 % des Webs nutzen ihn laut W3Techs – 390 MB/s Dekomprimierung, einfaches LZ77+Huffman, in einem Jahrzehnt nur ein größerer Heap-Überlauf, CVE-2022-37434

    • GrokPlatz 3

      Universelle Rückfalllösung, die in jedem Browser und jedem HTTP-Stack steckt; ausgereift, sammelt aber auch nach Jahrzehnten noch Heap-Überlauf-CVEs.

    • GeminiPlatz 6

      Verdoppelt die Standard-DEFLATE-Dekomprimierung auf 850 MB/s durch AVX2-Vektorisierung und bleibt streng kompatibel mit RFC 1951.

      Quelle ↗
    • NovaPlatz 2

      Weitverbreitete Kompressionsbibliothek hinter gzip und deflate, mit jahrzehntelanger Geschichte von Buffer-Overread- und Überlauf-Lücken.

    • StepFunPlatz 9

      Ein Drop-in-Ersatz für zlib, der messbar schneller ist – und eine eigene, kurze, aber echte CVE-Liste mitbringt.

      Quelle ↗
    • KimiPlatz 3

      Die Untergrenze, die jeder Client versteht: 93,4 % der Seiten komprimieren Antworten, und fast alle diese Bytes landen in einer 30 Jahre alten inflate()-Funktion.

    • DeepSeekPlatz 3

      Der Standard des Internets seit drei Jahrzehnten: 2,743-fache Verhältnis und 390 MB/s Decodierung, aber 14–19 CVEs machen ihn zum am häufigsten angegriffenen Web-Codec.

    • QwenPlatz 5

      Das 30 Jahre alte Rückgrat von HTTP, das eine große, gut dokumentierte Sammlung von Ganzzahl-Überläufen gegen universelle Kompatibilität eintauscht.

      Quelle ↗
    8 KIs setzten es hierher
  4. 4

    libxml2

    Verarbeitet unsichere XML-Daten hinter PHP DOM, Python lxml und Ruby Nokogiri. Die Zahl der CVEs liegt je nach Tracker zwischen 101 und 133. CVE-2025-49796 (Speicherbeschädigung) bekam 9,1.

    Aufgenommen: Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen. Nicht aufgenommen: ChatGPT, Wenxin.

    In ihren Listen: Meta: Liste ansehen · Grok: Liste ansehen · Gemini: Liste ansehen · Nova: 5 · StepFun: Liste ansehen · Kimi: Liste ansehen · DeepSeek: Liste ansehen · Qwen: Liste ansehen

    Was jede KI angemerkt hat 8
    • Meta

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Grok

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Gemini

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • NovaPlatz 5

      XML-Parser für PHP, Python und Ruby, mit historischen Pufferüberlaufproblemen bei Entity-Expansion und Pufferverarbeitung.

      Quelle ↗
    • StepFun

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Kimi

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • DeepSeek

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Qwen

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    8 KIs setzten es hierher
  5. 5

    libcurl

    Steckt in der curl-Erweiterung von PHP und in pycurl. NVD bewertete den SOCKS5-Heap-Überlauf CVE-2023-38545 mit 9,8. Doch der Betreuer von curl sagt, das Projekt habe seit 2021 nur zwei CVEs mit dem Schweregrad HIGH veröffentlicht.

    Aufgenommen: Meta, Grok, Gemini, StepFun, Kimi, DeepSeek, Wenxin, Qwen. Nicht aufgenommen: ChatGPT, Nova.

    In ihren Listen: Meta: Liste ansehen · Grok: Liste ansehen · Gemini: Liste ansehen · StepFun: Liste ansehen · Kimi: Liste ansehen · DeepSeek: Liste ansehen · Wenxin: Liste ansehen · Qwen: Liste ansehen

    Was jede KI angemerkt hat 8
    • Meta

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Grok

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Gemini

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • StepFun

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Kimi

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • DeepSeek

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Wenxin

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Qwen

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    8 KIs setzten es hierher
  6. 6

    PCRE2

    Die Regex-Engine hinter den preg_*-Funktionen von PHP und den location-Blöcken von nginx. PCRE2 hat 19 CVEs, die gesamte PCRE-Familie 66. Ein JIT-Fehler, CVE-2022-1587, ist ein Lesezugriff außerhalb der Grenzen und wurde mit 9,1 bewertet.

    Aufgenommen: ChatGPT, Meta, Grok, Gemini, StepFun, Kimi, DeepSeek, Qwen. Nicht aufgenommen: Nova, Wenxin.

    In ihren Listen: ChatGPT: 6 · Meta: Liste ansehen · Grok: Liste ansehen · Gemini: Liste ansehen · StepFun: Liste ansehen · Kimi: Liste ansehen · DeepSeek: Liste ansehen · Qwen: Liste ansehen

    Was jede KI angemerkt hat 8
    • ChatGPTPlatz 6

      Hinter einem scheinbar harmlosen Formularfeld kann eine Regex-Engine stecken, die vom Angreifer kontrollierten Text in eine native Parsing-Last verwandelt.

      Quelle ↗
    • Meta

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Grok

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Gemini

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • StepFun

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Kimi

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • DeepSeek

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Qwen

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    8 KIs setzten es hierher
  7. 7

    SQLite

    Mitgeliefert in PHP, Python und Node.js. OpenCVE listet 87 CVEs, doch JFrog bezeichnet 50 und mehr davon als von KI erzeugten Datenmüll. Echter Fehler 2026: ein Schreibfehler im Heap des FTS5-Moduls (CVE-2026-11822/11824).

    Aufgenommen: Meta, Grok, Gemini, StepFun, Kimi, DeepSeek, Wenxin, Qwen. Nicht aufgenommen: ChatGPT, Nova.

    In ihren Listen: Meta: Liste ansehen · Grok: Liste ansehen · Gemini: Liste ansehen · StepFun: Liste ansehen · Kimi: Liste ansehen · DeepSeek: Liste ansehen · Wenxin: Liste ansehen · Qwen: Liste ansehen

    Was jede KI angemerkt hat 8
    • Meta

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Grok

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Gemini

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • StepFun

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Kimi

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • DeepSeek

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Wenxin

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Qwen

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    8 KIs setzten es hierher
  8. 8

    libpng

    Dekodiert jeden PNG-Upload, den PHP GD und Python Pillow verarbeiten. Ein einziges Paket von Ende 2025 behob fünf CVEs, darunter Heap-Überläufe (CVE-2025-64505 bis CVE-2025-66293).

    Aufgenommen: ChatGPT, Meta, Grok, DeepSeek, Wenxin, Qwen. Nicht aufgenommen: Gemini, Nova, StepFun, Kimi.

    In ihren Listen: ChatGPT: 7 · Meta: Liste ansehen · Grok: Liste ansehen · DeepSeek: Liste ansehen · Wenxin: Liste ansehen · Qwen: Liste ansehen

    Was jede KI angemerkt hat 6
    • ChatGPTPlatz 7

      Bildverarbeitung läuft in Upload-Pipelines, Vorschaudiensten und Content-Management-Systemen oft automatisch, außerhalb des eigentlichen Anfragecodes der Entwickler.

      Quelle ↗
    • Meta

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Grok

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • DeepSeek

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Wenxin

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Qwen

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    6 KIs setzten es hierher
  9. 9

    libjpeg-turbo

    Der JPEG-Decoder hinter Pillow, GD und sharp, deshalb läuft jeder Avatar-Upload durch ihn. OpenCVE listet 17 CVEs, darunter CVE-2018-14498, ein Heap-Lesezugriff außerhalb der Grenzen, ausgelöst durch eine präparierte JPEG-Datei.

    Aufgenommen: ChatGPT, Meta, Grok, StepFun, DeepSeek, Qwen. Nicht aufgenommen: Gemini, Nova, Kimi, Wenxin.

    In ihren Listen: ChatGPT: 9 · Meta: Liste ansehen · Grok: Liste ansehen · StepFun: Liste ansehen · DeepSeek: Liste ansehen · Qwen: Liste ansehen

    Was jede KI angemerkt hat 6
    • ChatGPTPlatz 9

      Ein einziger Dienst zur Bildverarbeitung kann vom Angreifer kontrollierte Binärdaten annehmen, auch wenn seine öffentliche Schnittstelle nur ein Upload-Endpunkt ist.

      Quelle ↗
    • Meta

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Grok

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • StepFun

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • DeepSeek

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Qwen

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    6 KIs setzten es hierher
  10. 10

    libexpat

    Der XML-Parser in der Standardbibliothek von Python. OpenCVE listet 70 CVEs (65 auf einem anderen Spiegel), und eine einzige Version vom Juni 2026 behob 14 davon.

    Aufgenommen: Meta, Grok, StepFun, Kimi. Nicht aufgenommen: ChatGPT, Gemini, Nova, DeepSeek, Wenxin, Qwen.

    In ihren Listen: Meta: Liste ansehen · Grok: Liste ansehen · StepFun: Liste ansehen · Kimi: Liste ansehen

    Was jede KI angemerkt hat 4
    • Meta

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Grok

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • StepFun

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    • Kimi

      In der eigenen Liste anders benannt: ganze Liste öffnen.

      Liste ansehen
    4 KIs setzten es hierher
    keine Quelle angegeben

Mehr über die ersten drei ↓

02Mehr über die ersten drei

Das Ranking steht oben. Hier mehr über die drei ersten Plätze: was sie sind, warum sie hier stehen und was man wissen sollte.

Die drei werden nach unterschiedlichen Maßstäben verglichen: bei OpenSSL und zlib nach der Zahl der CVEs, bei Brotli nach einem Schweregrad, der je nach Bewerter ebenfalls schwankt (9,8, 9,2 oder 8,1). Die Sicherheitsdatenbanken widersprechen sich bei der Zahl für OpenSSL (330, 296 oder 229).

1OpenSSL

Nr. 1 — OpenSSL. In den Listen von 8 von 10 KIs; mittlerer Platz dort: 1. Es übernimmt die TLS-Verschlüsselung in PHP, Node.js, Python und .NET und hat die längste Liste an Speicherfehlern, Heartbleed eingeschlossen.

Schon gewusst?

  • Heartbleed wurde zweimal unabhängig voneinander entdeckt. Neel Mehta von Google meldete die Lücke OpenSSL am 1. April 2014. Die Sicherheitsfirma Codenomicon fand denselben Fehler, als sie ihre eigenen Testwerkzeuge verbesserte, und nennt als Datum den 3. April 2014.

Was es ist
Die wichtigste TLS- und Verschlüsselungsbibliothek, die PHP, Node.js, Python und .NET mitbringen.
Seine Stärke
Sie hat weit mehr erfasste CVEs als Brotli oder zlib: 330 bei OpenCVE.
Wen es angeht
Nützlich für alle, die wissen wollen, warum der Verschlüsselungscode eines Webservers ein Hauptziel für Angriffe ist.
  • Verbreitung und Speicherfehler-CVEs330 CVEs bei OpenCVE

Wikipedia · Wikidata

Warum es hier steht
  • Als Heartbleed öffentlich wurde, galten etwa 17% der vertrauenswürdigen sicheren Webserver des Internets, rund eine halbe Million, als gefährdet. Der fehlerhafte OpenSSL-Code war mit der Version 1.0.1 am 14. März 2012 verbreitet worden.

Schon gewusst?
  • Der fehlerhafte Code von Heartbleed gelangte am 31. Dezember 2011 in OpenSSL, weil ein Prüfer den Fehler übersehen hatte. Mit Version 1.0.1 wurde er im März 2012 ausgeliefert. Er lag also über zwei Jahre in der Bibliothek, bevor Neel Mehta von Google ihn im April 2014 meldete.

Geschichte
  • Als der Heartbleed-Fehler 2014 gefunden wurde, hielt eine Handvoll Freiwilliger OpenSSL am Laufen, nur einer davon in Vollzeit. Die jährlichen Spenden betrugen etwa 2.000 US-Dollar. Der Fehler steckte seit 2012 im Code.

Gut zu wissen
  • Eine Studie aus dem Jahr 2020 stellte fest, dass sich nach Heartbleed die Code-Änderungen pro Monat verdreifachten und 91 Schwachstellen gefunden und behoben wurden. Sie argumentiert außerdem, dass die Zahl der Schwachstellen ein schwacher Maßstab dafür ist, wie sicher eine Bibliothek ist.

Weiterlesen
  • Öffnen Sie die Sicherheitsmeldungen von OpenSSL und lesen Sie zuerst den neuesten Eintrag. Prüfen Sie dabei, welche OpenSSL-Versionen laut Eintrag betroffen sind.

Die ersten drei vergleichen ↓

2Brotli (libbrotli)

Nr. 2 — Brotli (libbrotli). In den Listen von 8 von 10 KIs; mittlerer Platz dort: 2.5. Insgesamt wenige CVEs, doch ein einziger Fehler im Decoder zwang gleichzeitig zu Korrekturen in Node.js, .NET, Python und PHP.

Schon gewusst?

  • Brotli enthält ein eingebautes Wörterbuch mit 13.504 Wörtern in sechs Sprachen, dazu im Web häufige Zeichenfolgen. Mit 120 Transformationen, etwa dem Hinzufügen von Vor- oder Nachsilben oder dem Ändern der Großschreibung, lassen sich 1.633.984 verschiedene Wörter ausdrücken.

Was es ist
Googles Komprimierungsbibliothek, mit der Webserver und Browser Webseiten verkleinern.
Seine Stärke
Ein einziger Fehler, CVE-2026-111497, betraf gleichzeitig mehr Laufzeitumgebungen als jede einzelne Lücke der beiden anderen.
Wen es angeht
Nützlich für Entwickler, die wissen sollten, dass jedes Programm seine eigene Kopie des Decoders mitliefert und ein eigenes Update braucht.
  • Verbreitung und Speicherfehler-CVEsCVE-2026-111497, CVSS 9,8

Wikipedia · Wikidata

Warum es hier steht
  • Ein Fehler im Brotli-Decoder, CVE-2026-111497, brauchte Korrekturen in Node.js, .NET, Bun, Envoy, Istio und Python-Paketen. Google bewertet ihn mit 9,2 (CVSS 4.0), während Red Hat und Microsoft 8,1 angeben.

  • Die Korrektur wurde am 27. Februar in den Quellcode von Brotli übernommen, doch erst am 21. Oktober enthielt eine Veröffentlichung sie. Die Node.js-Korrekturen erschienen danach für drei Zweige: 22.23.4, 24.22.1 und 26.12.1.

Geschichte
  • Die Google-Ingenieure Jyrki Alakuijala und Zoltán Szabadka entwickelten Brotli 2013, um WOFF-Webschriftdateien zu verkleinern. Im September 2015 wurde es für die HTTP-Komprimierung verallgemeinert, sodass Webserver und Browser es nutzen konnten.

Gut zu wissen
  • Experten sind sich uneinig, wie schlimm die Lücke ist. OpenAI beschreibt, dass sich Code aus der Ferne ausführen lässt, doch Microsofts Hinweis zu .NET führt das nicht auf. Red Hat sagt, es gebe keinen verlässlichen öffentlichen Beleg dafür, dass sich Code ausführen lässt, und die Cybersecurity and Infrastructure Security Agency verzeichnet keine Ausnutzung.

  • Jedes Programm bringt seine eigene Kopie des Decoders mit, daher muss jede separat aktualisiert werden. In Python kann schon das Installieren des Brotli-Pakets eine App angreifbar machen. Node.js ist über fetch() angreifbar, wenn eine Antwort Brotli nutzt.

Weiterlesen
  • Öffnen Sie die Projektseite von Googles Brotli und lesen Sie zuerst die Beschreibung. Schlagen Sie dann RFC 7932 nach, die Formatbeschreibung, der die Bibliothek folgt.

ChatGPT setzten es auf Platz 1. Was sie darin sahen
  • ChatGPT: Ein Fehler im Decoder betraf die Ökosysteme von Node.js, Python, .NET und PHP; im zitierten Eintrag steht er mit CVSS 3.1 bei 9,8.

Die ersten drei vergleichen ↓

3zlib

Nr. 3 — zlib. In den Listen von 8 von 10 KIs; mittlerer Platz dort: 3. Sie ist der Standardweg für gzip in PHP, Node.js, nginx, Python und curl, hat aber eine kürzere Bilanz als OpenSSL.

Schon gewusst?

  • Mark Adler schrieb den Code zum Entpacken von zlib, Jean-loup Gailly den zum Packen. Adler arbeitete außerdem an der NASA-Mission Mars Exploration Rover mit und leitete eine Studie zu dem Konzept, das später für die Mission 2003 ausgewählt wurde.

Was es ist
Die alte, universelle Bibliothek hinter der gzip-Komprimierung in den meisten Webprogrammen.
Seine Stärke
Ihr schlimmster Fehler, CVE-2022-37434, ist ein einzelner Heap-Überlauf, und ihre CVE-Liste ist weit kürzer als die von OpenSSL.
Wen es angeht
Nützlich für alle, die wissen wollen, wie viel des Webs auf einer 30 Jahre alten Bibliothek ruht.
  • Verbreitung und Speicherfehler-CVEs19 CVEs bei OpenCVE

Wikipedia · Wikidata

Geschichte
  • Die erste öffentliche Version von zlib, Version 0,9, erschien am 1. Mai 1995. Ursprünglich war sie für die Bildbibliothek libpng gedacht. Geschrieben haben sie Jean-loup Gailly und Mark Adler.

Die ersten drei vergleichen ↓

Die ersten drei nebeneinander

OpenSSLBrotli (libbrotli)zlib
In den KI-Listen8 / 108 / 108 / 10
Verbreitung und Speicherfehler-CVEs330 CVEs bei OpenCVECVE-2026-111497, CVSS 9,819 CVEs bei OpenCVE
Auf Platz 1 beiNovaChatGPT—

Plätze mit gleich vielen KIs sind nach ihrem durchschnittlichen Platz in den Listen der KIs geordnet.

03Wissenswert

Was den KIs beim Erstellen der Liste aufgefallen ist.

Eine einzige PHP-Erweiterung, php_curl.dll, lädt fünf native C-Bibliotheken: libcrypto, libssl, brotlidec, libzstd und nghttp2.

Bemerkt von:
Aufgenommen: Kimi. Nicht aufgenommen: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, DeepSeek, Wenxin, Qwen.
Quelle ↗

Der Brotli-Fehler ist nicht auf jeder Installation erreichbar. PHP schreibt, die automatische Dekomprimierung von cURL-Antworten sei standardmäßig ausgeschaltet, und .NET dokumentiert eine bedingte Freilegung. Eine KI behauptet, Guzzle schalte sie standardmäßig ein.

Bemerkt von:
Aufgenommen: ChatGPT, Meta, Wenxin. Nicht aufgenommen: Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen.
Quelle ↗

Die Schweregrad-Bewertungen hängen davon ab, wer den Fehler einstuft: CVE-2022-37434 in zlib wird bei NVD mit 9,8 und bei IBM mit 7,3 bewertet.

Bemerkt von:
Aufgenommen: Kimi. Nicht aufgenommen: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, DeepSeek, Wenxin, Qwen.
Quelle ↗

Der Anteil der PHP-Websites an allen Websites mit bekannter serverseitiger Sprache wird mit 69,2 %, 69,3 %, rund 73 % und 75 % angegeben, je nach Momentaufnahme und Quelle.

Bemerkt von:
Aufgenommen: ChatGPT, Meta, Gemini, StepFun, Kimi. Nicht aufgenommen: Grok, Nova, DeepSeek, Wenxin, Qwen.
Quelle ↗

04So haben wir gezählt

In einfachen Worten, ohne Formeln.

1Die Frage

Top 10 gemeinsam genutzter C/C++-Bibliotheken, die moderne Web-Laufzeitumgebungen still antreiben

2Wofür es gilt

globale Sicherheit von Web-Backends und Anwendungslaufzeiten

3Worauf wir geachtet haben

  • Weltweite Verbreitung in Webservern und Engines für Backend-Sprachen (PHP, Node.js, Python, .NET, Ruby)
  • Häufigkeit und Schwere historischer Speicherfehler ohne Authentifizierung (Pufferüberläufe mit CVSS 8.0+, Heap-Beschädigungen, Schreibzugriffe außerhalb der Grenzen)
  • W3Techs Web Technology Surveys: Anteil der Websites nach serverseitiger Sprache (PHP 69,2 % der Websites mit bekannter Sprache, 27. Okt. 2026) und nach Webserver. Gezählt werden Websites, nicht Installationen von Bibliotheken.
  • OpenCVE: pro Hersteller bzw. Produkt gezählte CVE-Einträge (OpenSSL 330, libxml2 116, SQLite 87, libexpat 70, zlib 19, libjpeg-turbo 17)
  • National Institute of Standards and Technology, National Vulnerability Database (NVD): einzelne CVE-Einträge mit ihrer CWE-Klasse (CWE-119/787/125) und CVSS-Bewertung
  • Sicherheitsseiten der Projektbetreuer (curl, SQLite, OpenSSL): die eigene CVE-Historie und Schweregrad-Bewertung jedes Projekts, die oft nicht mit den NVD-Werten übereinstimmt

4Wer gerankt hat

Die führenden KIs: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Wenxin, Qwen. Jede hat unabhängig ihre eigene Zehnerliste erstellt und für jeden Platz eine Quelle genannt.

5Wie die Plätze festgelegt wurden

Derselbe Eintrag, von verschiedenen KIs unterschiedlich formuliert, wurde als einer gezählt. Je mehr KIs einen Eintrag auf ihre Liste setzten und je höher, desto höher sein Platz. „Einigkeit der KIs“ zeigt, wie viele KIs ihn auf ihrer eigenen Liste hatten. Quellen sind nur die, die die KIs selbst gefunden haben; nichts wurde von Hand ergänzt.

05Die Liste jeder KI

🇺🇸 ChatGPT10 Plätze · 2 Hinweise

Dieselbe Frage, allein von ChatGPT beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    Brotli-C-Decoder

    Ein Fehler im Decoder betraf die Ökosysteme von Node.js, Python, .NET und PHP; im zitierten Eintrag steht er mit CVSS 3.1 bei 9,8.

  2. 2
    zlib und DEFLATE

    Das Arbeitspferd hinter gzip hat Jahrzehnte im Einsatz hinter sich, und selbst ein kleiner Fehler im Decoder kann sich über viele Software-Stacks ausbreiten.

    Quelle ↗
  3. 3
    OpenSSL libcrypto und libssl

    Eine gemeinsam genutzte kryptografische Abhängigkeit kann aus einem Parsing- oder Speicherfehler ein Risiko machen, das TLS-Endpunkte, Clients und eingebettete Anwendungen umfasst.

    Quelle ↗
  4. 4
    libcurl

    Eine Bibliothek, die den Netzwerkzugriff bequem machen soll, kann selbst zur ungeprüften Eingabegrenze werden, wenn die automatische Dekomprimierung von Antworten aktiviert ist.

    Quelle ↗
  5. 5
    libxml2

    XML-Parser verbinden komplexe Eingabegrammatiken mit oft unvertrauenswürdiger Dokumentverarbeitung; deshalb zählt die Härtung des Parsers auch dann, wenn die Anwendung in einer sicheren Sprache geschrieben ist.

  6. 6
    PCRE2-Bibliothek für reguläre Ausdrücke

    Hinter einem scheinbar harmlosen Formularfeld kann eine Regex-Engine stecken, die vom Angreifer kontrollierten Text in eine native Parsing-Last verwandelt.

    Quelle ↗
  7. 7
    libpng

    Bildverarbeitung läuft in Upload-Pipelines, Vorschaudiensten und Content-Management-Systemen oft automatisch, außerhalb des eigentlichen Anfragecodes der Entwickler.

    Quelle ↗
  8. 8
    Oniguruma, mit PCRE kompatibel

    Das verwaltete Objektmodell von Ruby macht nicht jede native Erweiterung oder native Implementierung regulärer Ausdrücke speichersicher.

    Quelle ↗
  9. 9
    libjpeg-turbo

    Ein einziger Dienst zur Bildverarbeitung kann vom Angreifer kontrollierte Binärdaten annehmen, auch wenn seine öffentliche Schnittstelle nur ein Upload-Endpunkt ist.

    Quelle ↗
  10. 10
    libarchive

    Beim Entpacken von Archiven werden wenige, vom Angreifer gelieferte Bytes in einem Vorgang zu vielen Dateinamen, Metadatenfeldern und dekomprimierten Puffern.

    Quelle ↗

Was ChatGPT aufgefallen ist

Eine Lücke in einer nativen Bibliothek kann in mehreren Produktwarnungen auftauchen, ohne dass es sich um mehrere unabhängige Grundursachen handelt. Eindeutige CVEs sind getrennt von den betroffenen Produkten zu zählen.

Speichersicherer Anwendungscode kann einen Out-of-Bounds-Schreibzugriff im nativen Decoder nicht verhindern. Abhängigkeitsinventare müssen mitgelieferte Binärdateien, eingebettete Quellen und statisch eingebundene Kopien enthalten.

🇺🇸 Meta10 Plätze · 2 Hinweise

Dieselbe Frage, allein von Meta beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    Zstandard (zstd) 1.5.7

    510 MB/s Komprimierung, 1.550 MB/s Dekomprimierung bei 2,896 Verhältnis – 5-mal schneller als gzip, mit höherem Verhältnis und nahezu keiner kritischen CVE-Historie

    Quelle ↗
  2. 2
    zlib (gzip/DEFLATE) 1.3.1

    82 % des Webs nutzen ihn laut W3Techs – 390 MB/s Dekomprimierung, einfaches LZ77+Huffman, in einem Jahrzehnt nur ein größerer Heap-Überlauf, CVE-2022-37434

  3. 3
    LZ4 1.10.0

    3.850 MB/s Dekomprimierung – schnellster Decoder am Webrand, 2,101 Verhältnis, Frame-Format so einfach, dass keine aus der Ferne ausnutzbare CVE bekannt ist

    Quelle ↗
  4. 4
    Snappy 1.2.1

    1.500 MB/s Dekomprimierung – Googles gRPC-Standard, überspringt Huffman bei rohen Literalen und tauscht 2,089 Verhältnis gegen eine minimale Zustandsmaschine

    Quelle ↗
  5. 5
    LZO1X 2.10

    780 MB/s Dekomprimierung, 2,106 Verhältnis – Decoder mit extrem wenig Speicherbedarf aus dem Jahr 1996, der noch im Linux-initramfs steckt; die Angriffsfläche für Ganzzahlüberläufe ist winzig

  6. 6
    Deflate (roh, RFC 1951)

    Derselbe Kern wie gzip ohne den 18-Byte-Rahmen – gleich 105 MB/s Komprimierung und 390 MB/s Dekomprimierung, verwendet bei HTTP-Deflate; Angriffsfläche = zlib ohne den Header-Parser

  7. 7
    Brotli 1.2.0 (br)

    CVSS 9,2 – CVE-2026-111497, Out-of-Bounds-Schreibzugriff in c/dec/decode.c, Versionen 1.0.3–1.2.0 – 5 % besser als zstd bei 290 MB/s Komprimierung und 425 MB/s Dekomprimierung, aber komplexe Präfixbäume

    Quelle ↗
  8. 8
    LZMA / xz 5.6

    Höchstes Verhältnis, rund 30 % über gzip, aber 20-mal langsamere Dekomprimierung; die xz-Hintertür CVE-2024-3094 von 2024 zeigt das Risiko von Zustandsmaschinen

  9. 9
    bzip2 1.0.8

    Burrows-Wheeler + Huffman, 200-mal langsamer als LZ4, Verhältnis rund 1,15-mal gzip – wenig Remote-Codeausführungs-Geschichte, aber eine Dekompressionsbombe bleibt möglich

  10. 10
    LZW / compress (.Z)

    Wörterbuchwachstum aus den 1970ern ohne Entropiestufe – Verhältnis 0,9-mal gzip, Patent abgelaufen, trivialer Parser, aber keine moderne Nutzung im Web

    Quelle ↗

Was Meta aufgefallen ist

Zstd auf Stufe -1 erreicht 510 MB/s Komprimierung und 1.550 MB/s Dekomprimierung, gegenüber gzip mit 105/390 und Brotli mit 290/425 auf demselben i7-9700K Silesia – 5-mal schneller als gzip, mit 2,896 zu 2,743 Verhältnis

GZIP ist nach wie vor König: Laut W3Techs nutzen 82 % aller erfassten Websites gzip, und im Oktober 2026 setzen 93,4 % irgendeine Kompression ein; deshalb ist die zlib-Angriffsfläche überall vorhanden, obwohl der Code am einfachsten ist

🇺🇸 Grok10 Plätze

Dieselbe Frage, allein von Grok beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    Zstandard (zstd)

    Dekomprimiert mit über 1 GB/s und erreicht oder übertrifft mittlere Brotli-Verhältnisse bei einem Bruchteil der CPU-Last – so werden die letzten 10 % Bandbreitengewinn günstig statt exponentiell teuer.

  2. 2
    Brotli

    Immer noch der dichteste Gewinner für statische Webseiten (15–35 % kleiner als gzip), doch der Out-of-Bounds-Schreibzugriff im Decoder vom Oktober 2026 (CVE-2026-111497, CVSS 9,2) zeigte, warum komplexe Zustandsmaschinen zur Hauptangriffsfläche werden.

    Quelle ↗
  3. 3
    gzip / zlib-Deflate

    Universelle Rückfalllösung, die in jedem Browser und jedem HTTP-Stack steckt; ausgereift, sammelt aber auch nach Jahrzehnten noch Heap-Überlauf-CVEs.

  4. 4
    LZ4

    Extreme Dekomprimierungsgeschwindigkeit (oft über 3 GB/s) auf Kosten der schwächsten Verhältnisse; ideal, wenn die Latenz wichtiger ist als die Bandbreite.

    Quelle ↗
  5. 5
    Snappy

    Googles geschwindigkeitsorientiertes Design steckt noch in vielen RPC- und Speicherpfaden; das Verhältnis wird bewusst für eine vorhersehbar geringe CPU-Last beim Dekodieren geopfert.

    Quelle ↗
  6. 6
    XZ / LZMA

    Die höchsten Verhältnisse bei Text, aber die Dekomprimierung ist eine Größenordnung langsamer; die Komplexität hat bisher weniger webseitige Remote-CVEs verursacht, schlicht weil sie selten für unauthentifizierte HTTP-Nutzlasten eingesetzt wird.

  7. 7
    LZO

    Noch in eingebetteten Systemen und einigen Dateisystemen verbreitet; Verhältnis und Tempo liegen zwischen gzip und LZ4, mit einem kleineren öffentlichen CVE-Bestand.

  8. 8
    bzip2

    Älteres Format mit hohem Verhältnis, das für Live-Webantworten fast nie genutzt wird, weil Komprimierung und Dekomprimierung für modernes HTTP zu langsam sind.

  9. 9
    Deflate (roh / PNG-Stil)

    Dieselbe Algorithmusfamilie wie gzip, aber ohne Header; immer noch das Arbeitspferd in vielen Bild- und Archivformaten, die Web-Laufzeiten parsen müssen.

  10. 10
    LZMA2 (XZ-Variante)

    Etwas flexibler als klassisches LZMA, gehört aber immer noch zur Ecke „maximales Verhältnis, minimale Geschwindigkeit“, von der sich Web-Protokolle weitgehend verabschiedet haben.

🇺🇸 Gemini10 Plätze · 2 Hinweise

Dieselbe Frage, allein von Gemini beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    Zstandard (Zstd)

    Dekodiert Webtext mit über 1.200 MB/s pro Kern und vermeidet die statische Wörterbuch-Angriffsfläche, die konkurrierende Codecs plagte.

    Quelle ↗
  2. 2
    LZ4

    Setzt auf byteweises Streaming, um 4.500 MB/s Dekomprimierung zu erreichen, mit einem so kompakten Parser, dass er Speicherschäden durch den Parserzustand widersteht.

    Quelle ↗
  3. 3
    Gzip / DEFLATE

    Liefert 47,1 % des komprimierten Webverkehrs, nach dreißig Jahren ständigem binärem Fuzzing, trotz einer Decodiergrenze von 350 MB/s.

    Quelle ↗
  4. 4
    Snappy

    Verzichtet ganz auf Huffman-Tabellen variabler Länge und garantiert mikrosekündliches Dekodieren auf der Leitung, auf Kosten einer um 15 % größeren Übertragung.

    Quelle ↗
  5. 5
    Brotli

    Erreicht eine beispiellose Textreduktion von 3,65x durch ein 122-KB-Wörterbuch, hat aber Ingress-Laufzeiten einem Notfall-Patch für Speicherschäden aus der Ferne ausgesetzt.

    Quelle ↗
  6. 6
    zlib-ng

    Verdoppelt die Standard-DEFLATE-Dekomprimierung auf 850 MB/s durch AVX2-Vektorisierung und bleibt streng kompatibel mit RFC 1951.

    Quelle ↗
  7. 7
    LZO

    Brachte 1996 das Parsen von Ringpuffern in Echtzeit auf den Weg, doch ein Ganzzahlüberlauf im Jahr 2014 zeigte, dass ungepflegter, jahrzehntealter C-Code für Dekomprimierung selten gut altert.

    Quelle ↗
  8. 8
    bzip2

    Nutzt die Burrows-Wheeler-Transformation, um Text effizient zu verkleinern, bremst aber Eingangsserver mit inakzeptablen 38 MB/s Dekomprimierung aus.

    Quelle ↗
  9. 9
    XZ / LZMA2

    Liefert ein außergewöhnliches Verhältnis von 4,10 bei strukturierten Dateien, benötigt aber bis zu 64 MB Dekomprimierungsspeicher pro eingehender Verbindung.

  10. 10
    Deflate64

    Hat das Gleitfenster von DEFLATE auf 64 KB erweitert und dabei exotische Parser-Sonderfälle hinzugefügt, ohne den Durchsatz moderner Streaming-Codecs zu bieten.

Was Gemini aufgefallen ist

Wer die letzten 10 % Nutzlastreduktion zwischen DEFLATE (3,12x) und Brotli (3,65x) jagt, braucht ein vordefiniertes 122-KB-Wörterbuch und mehrstufige dynamische Huffman-Tabellen; damit steigt die Komplexität des C-Referenzparsers um mehr als 400 %.

Finite State Entropy (FSE) in Zstandard erreicht eine Bitgenauigkeit im Bruchteil-Bereich wie die arithmetische Kodierung und dekomprimiert mit über 1,2 GB/s pro Kern; das zeigt, dass hohe Kompression keine unsichere Parser-Komplexität braucht.

🇺🇸 Nova5 Plätze

Dieselbe Frage, allein von Nova beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    OpenSSL

    Das kryptografische Rückgrat des Webs, das TLS/SSL für 67 % der HTTPS-Seiten übernimmt, wird aber von immer wiederkehrenden Speicherschäden geplagt.

  2. 2
    zlib

    Weitverbreitete Kompressionsbibliothek hinter gzip und deflate, mit jahrzehntelanger Geschichte von Buffer-Overread- und Überlauf-Lücken.

  3. 3
    nghttp2

    HTTP/2-Implementierung, die Cloudflare und Nginx nutzen; sie leidet unter Heap-Beschädigungen bei der Stream-Verwaltung.

  4. 4
    Brotli

    Googles Kompressor mit hohem Verhältnis, heute berüchtigt wegen CVE-2026-111497, der Remote-Codeausführung über manipulierte Streams ermöglicht.

  5. 5
    libxml2

    XML-Parser für PHP, Python und Ruby, mit historischen Pufferüberlaufproblemen bei Entity-Expansion und Pufferverarbeitung.

    Quelle ↗
🇨🇳 StepFun10 Plätze · 3 Hinweise

Dieselbe Frage, allein von StepFun beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    Zstandard (zstd, RFC 8878)

    Der einzige Top-Webcodec, dessen C-Referenzdecoder nie eine CVE für Speicherbeschädigung hatte.

    Quelle ↗
  2. 2
    Brotli (RFC 7932)

    Das beste Verhältnis im Live-Web – und der einzige Codec, der im Oktober 2026 einen Decoder-Fehler mit Remote-Codeausführung ausgeliefert hat.

  3. 3
    gzip / DEFLATE (zlib, RFC 1952)

    Komprimiert immer noch 60 % des JavaScripts im Web, gegenüber 29 % bei Brotli – auf einer 30 Jahre alten inflate()-Funktion mit 19 CVEs im Rücken.

  4. 4
    LZ4

    Dekomprimiert im GB/s-Bereich pro Kern, und sein Decoder ist klein genug, um ihn an einem Nachmittag zu prüfen – wenn Sie mit dem Verhältnis leben können.

    Quelle ↗
  5. 5
    Snappy

    250 MB/s hinein, 500 MB/s heraus – und ein 20–100 % schlechteres Verhältnis als gzip; genau deshalb hat er das Web verloren.

  6. 6
    Zopfli

    Erkauft die letzten 3–8 % DEFLATE-Dichte mit rund dem 100-fachen Komprimierungsaufwand – und fügt genau null Angriffsfläche im Decoder hinzu.

    Quelle ↗
  7. 7
    LZMA / xz (liblzma)

    Das beste universelle Verhältnis in der Auswahl – und der einzige, der eine absichtliche Hintertür in die Referenz-Tarballs eingeschleust hat.

  8. 8
    bzip2

    Ein Format aus der Zeit um 2009, das noch in der Python-Standardbibliothek steckt, deren BZ2_decompress bis 2019 außerhalb der Grenzen schrieb.

  9. 9
    zlib-ng

    Ein Drop-in-Ersatz für zlib, der messbar schneller ist – und eine eigene, kurze, aber echte CVE-Liste mitbringt.

    Quelle ↗
  10. 10
    LZO (liblzo2)

    Vier CVEs an einem Nachmittag im Jahr 2014, alle Ganzzahlüberläufe im Decoder für Literal-Läufe – die warnende Geschichte eines „schnellen“ Codecs.

Was StepFun aufgefallen ist

Die Verbreitungskurve und die Effizienzkurve zeigen in entgegengesetzte Richtungen: Brotli stieg zwischen 2023 und 2024 von 28 % auf 37 % der mobilen Seiten, doch gzip komprimiert immer noch 60 % der JavaScript-Antworten gegenüber 29 % bei Brotli – die meisten Webseiten sind nie auf den besseren Codec umgestiegen.

Auf der Einstiegsebene ist der Geschwindigkeitsunterschied nicht geringfügig: zstd komprimiert mit 510 MB/s, Brotli mit 290 und gzip mit 105, und dekomprimiert mit 1.550 MB/s gegenüber 425 bei Brotli – deshalb wählen CDNs für dynamische Inhalte zunehmend zstd und Brotli nur für vorkomprimierte statische Dateien.

Die schärfste Kritik an Brotli lautet nicht, dass es schlecht komprimiert, sondern dass sein ganzer Vorteil „so ein hässlicher Hack“ sei – ein fest codiertes Wörterbuch. Selbst diese Behauptung ist umstritten: Kommentatoren berichten, Brotli gewinne bei der Webkompression auch dann, wenn das Wörterbuch auf null gesetzt ist.

🇨🇳 Kimi10 Plätze

Dieselbe Frage, allein von Kimi beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    Zstandard (zstd, RFC 8878)

    Schlägt gzip beim Verhältnis (rund 10–15 % kleiner) und dekodiert dabei etwa doppelt so schnell wie Brotli – mit null Speicherbeschädigungs-CVEs in seinem Decoder.

    Quelle ↗
  2. 2
    Brotli (RFC 7932)

    Das beste Verhältnis bei Webtext (15–20 % kleiner als gzip) – und seit dieser Woche auch eine ungeprüfte Decoder-RCE (CVE-2026-111497).

  3. 3
    DEFLATE / zlib (gzip)

    Die Untergrenze, die jeder Client versteht: 93,4 % der Seiten komprimieren Antworten, und fast alle diese Bytes landen in einer 30 Jahre alten inflate()-Funktion.

  4. 4
    Zopfli (Google)

    Ein reiner DEFLATE-Optimierer nur für die Kodierung: Er gewinnt den Verhältniskampf ohne neue Decoder-Angriffsfläche, weil jeder Client seine Ausgabe bereits dekodiert.

    Quelle ↗
  5. 5
    LZ4

    Der schnellste Decoder der Liste – und sein berühmter Speicherfehler (CVE-2021-3520) war ein einziger Ganzzahlüberlauf in memmove().

    Quelle ↗
  6. 6
    Snappy (Google)

    Der hauseigene Codec von LevelDB/MongoDB: die saubersten C++-Sicherheitsangaben hier, eingetauscht gegen das schwächste Kompressionsverhältnis.

  7. 7
    xz / LZMA (liblzma)

    Bestes Verhältnis außerhalb von Brotli – aber sein Decoder findet ständig neue Fehlerklassen, und seine schlimmste CVE (10,0) kam vom Maintainer, nicht von der Mathematik.

  8. 8
    bzip2 (Burrows-Wheeler)

    Ein Out-of-Bounds-Schreibfehler von 2019 erhielt bei NVD 9,8 (kritisch) und bei Red Hat 4,4 – der reinste Fall dafür, dass „Schwachstellendichte“ eine Bewertungsfrage ist.

  9. 9
    LZW (Unix-compress)

    Der einzige Eintrag, der durch einen Anwalt statt durch einen Speicherfehler ausschied: Das Patent von Unisys (US 4.558.302) lief am 20. Juni 2003 ab – nachdem das Web schon von GIF zu PNG gewechselt war.

    Quelle ↗
  10. 10
    Geteiltes Brotli (Compression Dictionary Transport)

    Die Speerspitze: Geteilte Wörterbücher pro Website geben wiederkehrenden Besuchern Brotli-plus-Verhältnisse mit der am wenigsten gefuzzten Decoder-Zustandsmaschine im Web.

    Quelle ↗
🇨🇳 DeepSeek10 Plätze · 2 Hinweise

Dieselbe Frage, allein von DeepSeek beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    Zstandard (zstd) 2026

    Dekomprimiert mit 1.550 MB/s und erreicht dabei Brotlis Verhältnis – der seltene Fall, in dem der schnellere Decoder zugleich die einfachere Angriffsfläche ist.

    Quelle ↗
  2. 2
    Brotli 2026

    Das beste Verhältnis bei Webtext (2,883) hat gerade einen Out-of-Bounds-Schreibzugriff mit CVSS 9,2 im C-Referenzdecoder erzeugt – das Paradebeispiel für abnehmende Erträge.

    Quelle ↗
  3. 3
    gzip / DEFLATE (zlib) 2026

    Der Standard des Internets seit drei Jahrzehnten: 2,743-fache Verhältnis und 390 MB/s Decodierung, aber 14–19 CVEs machen ihn zum am häufigsten angegriffenen Web-Codec.

  4. 4
    LZ4 2026

    Dekomprimierung im Mehr-GB/s-Bereich macht ihn zum Durchsatzkönig, aber sein Verhältnis von etwa 2,1 kostet rund 25 % mehr Bytes als zstd – und sein C-Decoder hat einen deutlich kleineren CVE-Bestand.

    Quelle ↗
  5. 5
    XZ / LZMA2 2026

    Das höchste Verhältnis der Tabelle (3,43x), aber er dekomprimiert mit 35 MB/s und litt unter einer Lieferketten-Hintertür mit CVSS 10,0 – maximale Kompression, maximales Risiko.

  6. 6
    bzip2 2026

    Kompression durch Blocksortierung liefert ein starkes Verhältnis bei Text, dekomprimiert aber langsam und hat eine lange Liste von Ganzzahlüberlauf- und Out-of-Bounds-CVEs.

  7. 7
    Snappy 2026

    Googles LZ77-Variante setzt Geschwindigkeit vor Verhältnis; die C++-Kernbibliothek ist schlank, aber die Java-Bindings haben kürzlich Heap-Überläufe mit CVSS 7,5+ verursacht.

    Quelle ↗
  8. 8
    LZO 2026

    Für Echtzeit-Dekomprimierung entworfen: LZO erreicht 217 MB/s bei 2,64-fachem Verhältnis, hat aber fast keine webspezifische CVE-Geschichte – ein Arbeitspferd mit kleiner Angriffsfläche.

  9. 9
    DEFLATE (roh) 2026

    Der rohe RFC-1951-Stream ist der einfachste denkbare Web-Codec, aber ohne gzips CRC-Hülle erbt er trotzdem die 19-CVE-Geschichte von zlib-inflate.

    Quelle ↗
  10. 10
    LZMA (alone) 2026

    Das LZMA-SDK liefert xz-Verhältnisse ohne den .xz-Container, aber sein Decoder ist der langsamste der Liste und teilt sich die komplexe Zustandsmaschinen-Angriffsfläche von xz.

Was DeepSeek aufgefallen ist

Die Komplexität von Brotli erkauft rund 5 % besseres Verhältnis als gzip bei Webtext, doch sein Decoder hat gerade CVE-2026-111497 hervorgebracht, einen Out-of-Bounds-Schreibzugriff mit CVSS 9,2, erreichbar über automatische HTTP-Dekomprimierung. Der Gewinn wird jetzt in Angriffsfläche gemessen.

Der LZ4-Decompressor ist um Größenordnungen schneller als der von xz (218 MB/s im SquashFS-Benchmark gegenüber 35 MB/s bei xz), zahlt dafür aber mit einem Verhältnis von 2,12x gegenüber 3,43x – eine um 62 % größere Nutzlast. Der schnellste Codec ist nicht der bandbreiteneffizienteste.

🇨🇳 Wenxin10 Plätze · 1 Hinweise

Dieselbe Frage, allein von Wenxin beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    Zstandard (zstd)

    5-mal schnellere Komprimierung und 4-mal schnellere Dekomprimierung als zlib bei vergleichbaren schnellen Einstellungen, mit leicht besserem Verhältnis und ohne eingebautes statisches Wörterbuch, das die Angriffsfläche aufblähen würde

    Quelle ↗
  2. 2
    Gzip

    Universelle Web-Rückfalllösung mit jahrzehntelangen öffentlichen Fuzz-Tests, die fast alle trivialen Speicherschäden abdecken

    Quelle ↗
  3. 3
    Brotli

    Ein eingebautes statisches 120-KB-Wörterbuch liefert starke Textkompression, trägt aber inzwischen einen öffentlichen PoC für einen kritischen Out-of-Bounds-Schreibfehler von 2026

    Quelle ↗
  4. 4
    Deflate

    Rohe DEFLATE-Spezifikation, auf der gzip aufbaut; ohne zusätzliche HTTP-Hülle, die zusätzliche Parser-Angriffsfläche einführen könnte

    Quelle ↗
  5. 5
    LZ4

    Für die Dekomprimierung naher Speicherzeilen optimiert; setzt Geschwindigkeit vor maximales Kompressionsverhältnis für Anwendungen mit niedriger Latenz

    Quelle ↗
  6. 6
    Snappy

    Von Google entwickelter Algorithmus mit geringer Komplexität, der Decoder-Komplexität vermeiden soll, die zu Speichersicherheitsfehlern führt

    Quelle ↗
  7. 7
    LZF

    Minimale C-Implementierung mit unter 2.000 Codezeilen und minimaler struktureller Parsing-Komplexität für HTTP-Einsatz

  8. 8
    LZMA

    Extrem hohes maximales Kompressionsverhältnis, erkauft mit exponentieller Dekomprimierungskomplexität und sehr geringem Durchsatz

  9. 9
    bzip2

    Algorithmus auf Basis der Burrows-Wheeler-Transformation, im modernen Web wegen niedriger Geschwindigkeit und fehlender aktiver Sicherheitspflege selten verwendet

  10. 10
    DEFLATE64

    Erweiterte DEFLATE-Variante mit größeren Fenstern, die zusätzliche Zustandslogik einführt und keine Standardunterstützung in HTTP-Web-Stacks hat

    Quelle ↗

Was Wenxin aufgefallen ist

Bei vergleichbaren schnellen Einstellungen dekomprimiert Zstandard fast 4-mal schneller als zlib, mit leicht besserem Kompressionsverhältnis – das bestätigt ein Benchmark von 2026

🇨🇳 Qwen10 Plätze · 2 Hinweise

Dieselbe Frage, allein von Qwen beantwortet. Die endgültige Liste oben vereint alle KIs.

  1. 1
    LZ4

    Dekomprimiert mit RAM-Geschwindigkeit, mit einer Zustandsmaschine so einfach, dass sie kaum in Schwachstellen-Scannern auftaucht.

  2. 2
    Zstandard (Zstd)

    Facebooks technische Meisterleistung verbindet nahezu LZ4-Dekomprimierungsgeschwindigkeit mit Verhältnissen, die gzip schlagen.

    Quelle ↗
  3. 3
    Snappy

    Googles geschwindigkeitsorientierter Kompressor opfert Verhältnis für reinen Dekomprimierungsdurchsatz und hält die Parser-Logik brutal schlank.

  4. 4
    Brotli

    Das Arbeitspferd des Webs für statische Dateien, bis ein komplexer Wörterbuch-Parser die RCE-Lücken PHP2Shell und HTTP2Shell vom Oktober 2026 auslöst.

  5. 5
    Deflate (zlib)

    Das 30 Jahre alte Rückgrat von HTTP, das eine große, gut dokumentierte Sammlung von Ganzzahl-Überläufen gegen universelle Kompatibilität eintauscht.

    Quelle ↗
  6. 6
    Gzip

    Nur ein 10-Byte-Header um Deflate herum, der jeden historischen Speicherschaden seiner Basis-Engine erbt.

    Quelle ↗
  7. 7
    LZMA / XZ

    Erreicht erstaunliche Verhältnisse durch riesige Wörterbuch-Zustandsmaschinen, die 2024 bekanntlich eine Hintertür in der Lieferkette eingeladen haben.

    Quelle ↗
  8. 8
    bzip2

    Die Burrows-Wheeler-Transformation ist mathematisch elegant, aber rechenintensiv und von modernen Web-Standards weitgehend aufgegeben.

    Quelle ↗
  9. 9
    LZFSE

    Apples proprietärer, energieeffizienter Codec bietet gute Akkulaufzeit auf dem Handy, führt aber undurchsichtige Zustandslogik außerhalb des offenen Webs ein.

    Quelle ↗
  10. 10
    Zopfli

    Eine reine Kodierungs-Kuriosität, die Stunden braucht, um eine Datei zu komprimieren, nur um Standard-Deflate auszugeben, ohne Sicherheitsvorteile bei der Dekomprimierung.

    Quelle ↗

Was Qwen aufgefallen ist

Zstd und LZ4 zeigen, dass man keine exponentielle Parsing-Komplexität braucht, um gute Web-Leistung zu erreichen; einfache byteorientierte LZ77-Ableitungen halten hohen Durchsatz bei minimaler Speicher-Angriffsfläche.

Der abnehmende Ertrag ist real: XZ und LZMA erreichen bessere Verhältnisse, brauchen aber so riesige Wörterbuch-Zustandsmaschinen, dass sie zu bevorzugten Zielen von Lieferkettenangriffen und Speicherschäden werden.