Back to the trend of the day: PHP updates Windows web tools to fix a flaw that could let attackers run code
Poly Rating · from the trend of the day

Top 10 C Libraries Silently Powering Web Runtimes 2026

Brotli has only two decoder CVEs on record, but one of them, CVE-2026-111497 (rated 9.8 under CVSS 3.1), forced Node.js, .NET, Python packages and PHP's Windows builds to ship fixes in the same October week.

  • No. 1: OpenSSL
  • 10 places

01Final list

The leading AIs built their own top-ten lists independently. Above is one combined result that is easy to check: every place has a reason, the AIs that included it and, where the AIs gave one, a source.

Order: from most to least AI agreement.

A bright badge means this AI put the entry on its list. A dim badge means it did not.

  1. 1

    OpenSSL

    The TLS library bundled by PHP, Node.js, Python and .NET. OpenCVE lists 330 CVEs (other trackers say 296 or 229), with Heartbleed the best known. No source measures its exact web share.

    Included it: Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen. Did not include: ChatGPT, Wenxin.

    In their lists: Meta: see list · Grok: see list · Gemini: see list · Nova: 1 · StepFun: see list · Kimi: see list · DeepSeek: see list · Qwen: see list

    What each AI noted 8
    • Meta

      Named differently in its own list: open the full list.

      see list
    • Grok

      Named differently in its own list: open the full list.

      see list
    • Gemini

      Named differently in its own list: open the full list.

      see list
    • Novaplace 1

      The cryptographic backbone of the web, handling TLS/SSL for 67% of HTTPS sites but plagued by recurring memory-corruption flaws.

    • StepFun

      Named differently in its own list: open the full list.

      see list
    • Kimi

      Named differently in its own list: open the full list.

      see list
    • DeepSeek

      Named differently in its own list: open the full list.

      see list
    • Qwen

      Named differently in its own list: open the full list.

      see list
    8 AIs put it here
    Source ↗
  2. 2

    Brotli (libbrotli)

    Few CVEs overall, but one decoder flaw, CVE-2026-111497, forced fixes in Node.js, .NET, Python and PHP at once. It scores 9.8 under CVSS 3.1, 9.2 under 4.0 and 8.1 at Microsoft and Red Hat.

    Included it: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, Kimi, Wenxin. Did not include: DeepSeek, Qwen.

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

    What each AI noted 8
    • ChatGPTplace 1

      One decoder flaw reached Node.js, Python, .NET and PHP ecosystems, with CVSS 3.1 9.8 in the cited record.

    • Metaplace 7

      9.2 CVSS CVE-2026-111497 out-of-bounds write in c/dec/decode.c 1.0.3-1.2.0 – 5% better than zstd at 290 MB/s compress, 425 MB/s decompress but complex prefix trees

      Source ↗
    • Grokplace 2

      Still the densest static-web winner (15–35% smaller than gzip) but the October 2026 decoder OOB-write (CVE-2026-111497, CVSS 9.2) showed exactly why complex state machines become premier attack surfaces.

      Source ↗
    • Geminiplace 5

      Achieves an unmatched 3.65x text reduction via a 122 KB static dictionary, but exposed ingress runtimes to emergency remote memory-corruption patching.

      Source ↗
    • Novaplace 4

      Google's high-ratio compressor, now infamous for CVE-2026-111497 allowing remote code execution via malformed streams.

    • StepFunplace 2

      Best ratio on the live web - and the only codec that shipped a remote-code-execution decoder bug in October 2026.

    • Kimiplace 2

      Best ratio on web text (15-20% smaller than gzip) — and, as of this week, a live unauthenticated decoder RCE (CVE-2026-111497).

    • Wenxinplace 3

      120 KB built-in static dictionary delivers strong text compression but now carries a public PoC for a critical 2026 out-of-bounds write vulnerability

      Source ↗
    8 AIs put it here
    Source ↗
  3. 3

    zlib

    The default gzip path in PHP, Node.js, nginx, Python and curl. OpenCVE lists 19 CVEs. The worst, CVE-2022-37434 (a heap overflow in inflate()), scores 9.8 at NVD but 7.3 at IBM.

    Included it: Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen. Did not include: ChatGPT, Wenxin.

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

    What each AI noted 8
    • Metaplace 2

      82% of web uses it per W3Techs – 390 MB/s decompress, simple LZ77+Huffman, only 1 major heap overflow CVE-2022-37434 in decade

    • Grokplace 3

      Universal fallback that still ships in every browser and HTTP stack; mature but still accumulates heap-overflow CVEs decades later.

    • Geminiplace 6

      Doubles standard DEFLATE decompression to 850 MB/s through AVX2 vectorization while maintaining strict RFC 1951 backward compatibility.

      Source ↗
    • Novaplace 2

      Ubiquitous compression library powering gzip and deflate, with a decades-long history of buffer-overread and overflow vulnerabilities.

    • StepFunplace 9

      A drop-in zlib replacement that is measurably faster - and carries its own short but real CVE list.

      Source ↗
    • Kimiplace 3

      The floor every client understands: 93.4% of sites compress responses, and nearly all of those bytes end up in a 30-year-old inflate().

    • DeepSeekplace 3

      The internet's default for three decades: 2.743x ratio and 390 MB/s decode, but 14–19 CVEs make it the most historically attacked web codec.

    • Qwenplace 5

      The 30-year-old backbone of HTTP that trades a massive, well-documented catalog of integer wraparounds for universal compatibility.

      Source ↗
    8 AIs put it here
    Source ↗
  4. 4

    libxml2

    Parses untrusted XML behind PHP DOM, Python lxml and Ruby Nokogiri. Its CVE count runs from 101 to 133 depending on the tracker. CVE-2025-49796 (memory corruption) scored 9.1.

    Included it: Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen. Did not include: ChatGPT, Wenxin.

    In their lists: Meta: see list · Grok: see list · Gemini: see list · Nova: 5 · StepFun: see list · Kimi: see list · DeepSeek: see list · Qwen: see list

    What each AI noted 8
    • Meta

      Named differently in its own list: open the full list.

      see list
    • Grok

      Named differently in its own list: open the full list.

      see list
    • Gemini

      Named differently in its own list: open the full list.

      see list
    • Novaplace 5

      XML parser for PHP, Python, and Ruby, with historical buffer-overflow issues in entity expansion and buffer handling.

      Source ↗
    • StepFun

      Named differently in its own list: open the full list.

      see list
    • Kimi

      Named differently in its own list: open the full list.

      see list
    • DeepSeek

      Named differently in its own list: open the full list.

      see list
    • Qwen

      Named differently in its own list: open the full list.

      see list
    8 AIs put it here
    Source ↗
  5. 5

    libcurl

    Ships inside PHP's curl extension and pycurl. NVD scored the CVE-2023-38545 SOCKS5 heap overflow 9.8, yet curl's maintainer says the project has published only two HIGH-severity CVEs since 2021.

    Included it: Meta, Grok, Gemini, StepFun, Kimi, DeepSeek, Wenxin, Qwen. Did not include: ChatGPT, Nova.

    In their lists: Meta: see list · Grok: see list · Gemini: see list · StepFun: see list · Kimi: see list · DeepSeek: see list · Wenxin: see list · Qwen: see list

    What each AI noted 8
    • Meta

      Named differently in its own list: open the full list.

      see list
    • Grok

      Named differently in its own list: open the full list.

      see list
    • Gemini

      Named differently in its own list: open the full list.

      see list
    • StepFun

      Named differently in its own list: open the full list.

      see list
    • Kimi

      Named differently in its own list: open the full list.

      see list
    • DeepSeek

      Named differently in its own list: open the full list.

      see list
    • Wenxin

      Named differently in its own list: open the full list.

      see list
    • Qwen

      Named differently in its own list: open the full list.

      see list
    8 AIs put it here
    Source ↗
  6. 6

    PCRE2

    The regex engine behind PHP's preg_* functions and nginx location blocks. PCRE2 has 19 CVEs and the wider PCRE family 66. One JIT flaw, CVE-2022-1587, is an out-of-bounds read scored 9.1.

    Included it: ChatGPT, Meta, Grok, Gemini, StepFun, Kimi, DeepSeek, Qwen. Did not include: Nova, Wenxin.

    In their lists: ChatGPT: 6 · Meta: see list · Grok: see list · Gemini: see list · StepFun: see list · Kimi: see list · DeepSeek: see list · Qwen: see list

    What each AI noted 8
    • ChatGPTplace 6

      A regex engine may sit behind a seemingly harmless form field, turning attacker-controlled text into a native parsing workload.

      Source ↗
    • Meta

      Named differently in its own list: open the full list.

      see list
    • Grok

      Named differently in its own list: open the full list.

      see list
    • Gemini

      Named differently in its own list: open the full list.

      see list
    • StepFun

      Named differently in its own list: open the full list.

      see list
    • Kimi

      Named differently in its own list: open the full list.

      see list
    • DeepSeek

      Named differently in its own list: open the full list.

      see list
    • Qwen

      Named differently in its own list: open the full list.

      see list
    8 AIs put it here
    Source ↗
  7. 7

    SQLite

    Bundled in PHP, Python and Node.js. OpenCVE lists 87 CVEs, but JFrog calls 50+ of them LLM-generated noise. Real 2026 flaw: an FTS5 heap write (CVE-2026-11822/11824).

    Included it: Meta, Grok, Gemini, StepFun, Kimi, DeepSeek, Wenxin, Qwen. Did not include: ChatGPT, Nova.

    In their lists: Meta: see list · Grok: see list · Gemini: see list · StepFun: see list · Kimi: see list · DeepSeek: see list · Wenxin: see list · Qwen: see list

    What each AI noted 8
    • Meta

      Named differently in its own list: open the full list.

      see list
    • Grok

      Named differently in its own list: open the full list.

      see list
    • Gemini

      Named differently in its own list: open the full list.

      see list
    • StepFun

      Named differently in its own list: open the full list.

      see list
    • Kimi

      Named differently in its own list: open the full list.

      see list
    • DeepSeek

      Named differently in its own list: open the full list.

      see list
    • Wenxin

      Named differently in its own list: open the full list.

      see list
    • Qwen

      Named differently in its own list: open the full list.

      see list
    8 AIs put it here
    Source ↗
  8. 8

    libpng

    Decodes every PNG upload handled by PHP GD and Python Pillow. A single late-2025 batch fixed five CVEs, including heap overflows (CVE-2025-64505 through CVE-2025-66293).

    Included it: ChatGPT, Meta, Grok, DeepSeek, Wenxin, Qwen. Did not include: Gemini, Nova, StepFun, Kimi.

    In their lists: ChatGPT: 7 · Meta: see list · Grok: see list · DeepSeek: see list · Wenxin: see list · Qwen: see list

    What each AI noted 6
    • ChatGPTplace 7

      Image handling often occurs automatically in upload pipelines, thumbnail services and content-management systems, outside the developer's main request-handling code.

      Source ↗
    • Meta

      Named differently in its own list: open the full list.

      see list
    • Grok

      Named differently in its own list: open the full list.

      see list
    • DeepSeek

      Named differently in its own list: open the full list.

      see list
    • Wenxin

      Named differently in its own list: open the full list.

      see list
    • Qwen

      Named differently in its own list: open the full list.

      see list
    6 AIs put it here
    Source ↗
  9. 9

    libjpeg-turbo

    The JPEG decoder behind Pillow, GD and sharp, so every avatar upload passes through it. OpenCVE lists 17 CVEs, including CVE-2018-14498, a heap over-read triggered by a crafted JPEG.

    Included it: ChatGPT, Meta, Grok, StepFun, DeepSeek, Qwen. Did not include: Gemini, Nova, Kimi, Wenxin.

    In their lists: ChatGPT: 9 · Meta: see list · Grok: see list · StepFun: see list · DeepSeek: see list · Qwen: see list

    What each AI noted 6
    • ChatGPTplace 9

      A single image-processing service can accept attacker-controlled binary data even when its public API is only an upload endpoint.

      Source ↗
    • Meta

      Named differently in its own list: open the full list.

      see list
    • Grok

      Named differently in its own list: open the full list.

      see list
    • StepFun

      Named differently in its own list: open the full list.

      see list
    • DeepSeek

      Named differently in its own list: open the full list.

      see list
    • Qwen

      Named differently in its own list: open the full list.

      see list
    6 AIs put it here
    Source ↗
  10. 10

    libexpat

    The XML parser in Python's standard library. OpenCVE lists 70 CVEs (65 on another mirror), and a single June 2026 release fixed 14 of them.

    Included it: Meta, Grok, StepFun, Kimi. Did not include: ChatGPT, Gemini, Nova, DeepSeek, Wenxin, Qwen.

    In their lists: Meta: see list · Grok: see list · StepFun: see list · Kimi: see list

    What each AI noted 4
    • Meta

      Named differently in its own list: open the full list.

      see list
    • Grok

      Named differently in its own list: open the full list.

      see list
    • StepFun

      Named differently in its own list: open the full list.

      see list
    • Kimi

      Named differently in its own list: open the full list.

      see list
    4 AIs put it here
    no source given

More about the top three ↓

02More about the top three

The ranking is above. Here is more about the three places at the top: what they are, why they are here, and what is worth knowing.

The three are compared on different measures: a CVE count for OpenSSL and zlib, and one severity score for Brotli, which also varies by scorer (9.8, 9.2 or 8.1). Trackers disagree on the OpenSSL count (330, 296 or 229).

1OpenSSL

No. 1 — OpenSSL. On the lists of 8 of 10 AIs; median place there: 1. It handles TLS inside PHP, Node.js, Python and .NET, and has the longest record of memory-corruption bugs, Heartbleed included.

Did you know

  • Heartbleed was found twice, independently. Neel Mehta of Google reported it to OpenSSL on 1 April 2014. The security firm Codenomicon found the same flaw while improving its own testing tools, and gives 3 April 2014 as its date.

    Source ↗
What it is
The main TLS and encryption library bundled by PHP, Node.js, Python and .NET.
Its edge
It has far more recorded CVEs than Brotli or zlib: 330 on OpenCVE.
Who should know
Useful for anyone who wants to know why a web server's encryption code is a top attack target.
  • Reach and memory-bug CVEs330 CVEs on OpenCVE

Wikipedia · Wikidata

Why it is here

  • When Heartbleed became public, about 17% of the internet's trusted secure web servers, roughly half a million, were believed to be exposed. The flawed OpenSSL code had spread with the 1.0.1 release on 14 March 2012.

    Source ↗
Did you know

  • Heartbleed's faulty code entered OpenSSL on 31 December 2011, after a reviewer missed the bug. It shipped in version 1.0.1 in March 2012, so it sat in the library for over two years before Google's Neel Mehta reported it in April 2014.

    Source ↗
History

  • In 2014, when the Heartbleed bug was found, OpenSSL was kept going by a handful of volunteers, only one of them full time. Yearly donations were about US$2,000. The bug had been in the code since 2012.

    Source ↗
Keep in mind

  • A 2020 study found that after Heartbleed, commits per month tripled and 91 vulnerabilities were found and fixed. It also argues that a count of vulnerabilities is a weak way to judge how secure a library is.

    Source ↗
Where to go further

  • Open the OpenSSL security advisory list and read the newest entry first, checking which OpenSSL versions it says are affected.

    Source ↗
Compare the top three ↓

2Brotli (libbrotli)

No. 2 — Brotli (libbrotli). On the lists of 8 of 10 AIs; median place there: 2.5. Few CVEs overall, but one decoder flaw forced fixes in Node.js, .NET, Python and PHP at the same time.

Did you know

  • Brotli ships with a built-in dictionary of 13,504 words in six languages, plus strings common on the web. With 120 transforms, such as adding prefixes or suffixes or changing capitals, it can express 1,633,984 different words.

    Source ↗
What it is
Google's compression library that web servers and browsers use to shrink web pages.
Its edge
One bug, CVE-2026-111497, hit more runtimes at once than any single flaw in the other two.
Who should know
Useful for developers to know that every program ships its own decoder copy and needs its own update.
  • Reach and memory-bug CVEsCVE-2026-111497, CVSS 9.8

Wikipedia · Wikidata

Why it is here

  • One Brotli decoder bug, CVE-2026-111497, needed fixes in Node.js, .NET, Bun, Envoy, Istio and Python packages. Google scores it 9.2 (CVSS 4.0), while Red Hat and Microsoft give 8.1.

    Source ↗

  • The fix went into Brotli's source on Feb 27, but no release carried it until Oct 21. The Node.js fixes then shipped for three branches: 22.23.4, 24.22.1 and 26.12.1.

    Source ↗
History

  • Google engineers Jyrki Alakuijala and Zoltán Szabadka built Brotli in 2013 to shrink WOFF web font files. In September 2015 it was generalized for HTTP compression, so web servers and browsers could use it.

    Source ↗
Keep in mind

  • Experts disagree on how bad it is. OpenAI describes remote code execution, but Microsoft's .NET advisory does not list it. Red Hat says there is no reliable public proof of code execution, and CISA recorded exploitation as none.

    Source ↗

  • Each program ships its own copy of the decoder, so each must be updated separately. In Python, just installing the Brotli package can expose an app. Node.js is exposed through fetch() when a response uses Brotli.

    Source ↗
Where to go further

  • Open Google's Brotli project page and read the description first, then look up RFC 7932, the format specification the library follows.

    Source ↗
ChatGPT put it first. What they saw in it

  • ChatGPT: One decoder flaw reached Node.js, Python, .NET and PHP ecosystems, with CVSS 3.1 9.8 in the cited record.

Compare the top three ↓

3zlib

No. 3 — zlib. On the lists of 8 of 10 AIs; median place there: 3. It is the default gzip path in PHP, Node.js, nginx, Python and curl, but its record is shorter than OpenSSL's.

Did you know

  • Mark Adler wrote zlib's decompression code with Jean-loup Gailly, who wrote the compression. Adler also worked on NASA's Mars Exploration Rover mission, leading a study on the concept that was later selected for the 2003 mission.

    Source ↗
What it is
The old, universal library behind gzip compression in most web software.
Its edge
Its worst bug, CVE-2022-37434, is a single heap overflow, and its CVE list is far shorter than OpenSSL's.
Who should know
Useful for anyone wanting to know how much of the web rests on one 30-year-old library.
  • Reach and memory-bug CVEs19 CVEs on OpenCVE

Wikipedia · Wikidata

History

  • zlib's first public version, 0.9, came out on 1 May 1995. It was originally intended for the libpng image library, and Jean-loup Gailly and Mark Adler wrote it.

    Source ↗
Compare the top three ↓

The top three side by side

OpenSSLBrotli (libbrotli)zlib
In the AIs' lists8 / 108 / 108 / 10
Reach and memory-bug CVEs330 CVEs on OpenCVECVE-2026-111497, CVSS 9.819 CVEs on OpenCVE
Put first byNovaChatGPT—

Places with the same number of AIs are ordered by their average place in the AIs' own lists.

More ratings

03Worth knowing

What the AIs noticed while building the list.

A single PHP extension, php_curl.dll, loads five native C libraries: libcrypto, libssl, brotlidec, libzstd and nghttp2.

Noticed by:
Included it: Kimi. Did not include: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, DeepSeek, Wenxin, Qwen.
Source ↗

The Brotli bug is not reachable on every install. PHP says cURL's automatic response decompression is off by default, and .NET documents conditional exposure. One AI claims Guzzle turns it on by default.

Noticed by:
Included it: ChatGPT, Meta, Wenxin. Did not include: Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Qwen.
Source ↗

Severity scores depend on who grades the bug: zlib's CVE-2022-37434 is 9.8 at NVD and 7.3 at IBM.

Noticed by:
Included it: Kimi. Did not include: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, DeepSeek, Wenxin, Qwen.
Source ↗

PHP's share of sites with a known server-side language is quoted as 69.2%, 69.3%, about 73% and 75%, depending on the snapshot and the source.

Noticed by:
Included it: ChatGPT, Meta, Gemini, StepFun, Kimi. Did not include: Grok, Nova, DeepSeek, Wenxin, Qwen.
Source ↗

04How we counted

In plain words, no formulas.

1The question

Top 10 Shared C/C++ Libraries Silently Powering Modern Web Runtimes

2Where it applies

global web backend and application runtime security

3What we looked at

  • Global runtime footprint across web servers and backend language engines (PHP, Node.js, Python, .NET, Ruby)
  • Historical frequency and severity of unauthenticated memory-corruption vulnerabilities (CVSS 8.0+ buffer overflows, heap corruptions, out-of-bounds writes)
  • W3Techs Web Technology Surveys — Share of websites by server-side language (PHP 69.2% of sites with a known language, 27 Oct 2026) and by web server. It counts sites, not library installs.
  • OpenCVE — CVE records counted per vendor or product (OpenSSL 330, libxml2 116, SQLite 87, libexpat 70, zlib 19, libjpeg-turbo 17)
  • NIST National Vulnerability Database (NVD) — Individual CVE records with their CWE class (CWE-119/787/125) and CVSS score
  • Maintainer security pages (curl, SQLite, OpenSSL) — Each project's own CVE history and severity rating, which often disagrees with NVD scores

4Who ranked

The leading AIs, each building its own list of ten independently and naming a source for every place: ChatGPT, Meta, Grok, Gemini, Nova, StepFun, Kimi, DeepSeek, Wenxin, Qwen.

5How the places were set

The same entry written differently by different AIs was counted as one. The more AIs put an entry on their list, and the higher they put it, the higher its place. "AI agreement" shows how many of the AIs had it on their own list. Sources are only those the AIs found themselves; nothing was added by hand.

05Each AI's own list

🇺🇸 ChatGPT10 places · 2 notes

The same question, answered by ChatGPT alone. The final list above combines all the AIs.

  1. 1
    Brotli C decoder

    One decoder flaw reached Node.js, Python, .NET and PHP ecosystems, with CVSS 3.1 9.8 in the cited record.

  2. 2
    zlib and DEFLATE

    The compression workhorse behind gzip has decades of deployment history, and even a small decoder defect can propagate across many software stacks.

    Source ↗
  3. 3
    OpenSSL libcrypto and libssl

    A shared cryptographic dependency can turn one parsing or memory-management defect into a risk spanning TLS endpoints, clients and embedded applications.

    Source ↗
  4. 4
    libcurl

    A library intended to make network access convenient can itself become the untrusted-input boundary when automatic response decompression is enabled.

    Source ↗
  5. 5
    libxml2

    XML parsers combine intricate input grammars with potentially untrusted document processing, so parser hardening matters even when the application is written in a managed language.

  6. 6
    PCRE2 regular-expression library

    A regex engine may sit behind a seemingly harmless form field, turning attacker-controlled text into a native parsing workload.

    Source ↗
  7. 7
    libpng

    Image handling often occurs automatically in upload pipelines, thumbnail services and content-management systems, outside the developer's main request-handling code.

    Source ↗
  8. 8
    PCRE-compatible Oniguruma

    Ruby's managed object model does not make every native extension or native regular-expression implementation memory-safe.

    Source ↗
  9. 9
    libjpeg-turbo

    A single image-processing service can accept attacker-controlled binary data even when its public API is only an upload endpoint.

    Source ↗
  10. 10
    libarchive

    Archive extraction turns compact, attacker-supplied bytes into many filenames, metadata fields and decompressed buffers in one operation.

    Source ↗

What ChatGPT noticed

A native library's vulnerability can be duplicated across product advisories without representing multiple independent root-cause defects. Count unique CVEs separately from affected products.

Source ↗

Memory-safe application code cannot prevent an out-of-bounds write inside a native decoder. Dependency inventories need to include bundled binaries, vendored sources and statically linked copies.

Source ↗
🇺🇸 Meta10 places · 2 notes

The same question, answered by Meta alone. The final list above combines all the AIs.

  1. 1
    Zstandard (zstd) 1.5.7

    510 MB/s compress, 1550 MB/s decompress at 2.896 ratio – 5x faster than gzip with higher ratio and near-zero critical CVE history

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

    82% of web uses it per W3Techs – 390 MB/s decompress, simple LZ77+Huffman, only 1 major heap overflow CVE-2022-37434 in decade

  3. 3
    LZ4 1.10.0

    3850 MB/s decompress – fastest web edge decoder, 2.101 ratio, frame format so simple it has zero remotely exploitable CVEs on record

    Source ↗
  4. 4
    Snappy 1.2.1

    1500 MB/s decompress – Google gRPC default, skips Huffman for raw literals, trading 2.089 ratio for minimal state machine

    Source ↗
  5. 5
    LZO1X 2.10

    780 MB/s decompress, 2.106 ratio – 1996-era ultra-low-memory decoder still in Linux initramfs, integer overflow surface tiny

  6. 6
    Deflate (raw RFC1951)

    Same core as gzip without 18-byte wrapper – identical 105 MB/s compress, 390 MB/s decompress, used in HTTP deflate, attack surface = zlib minus header parser

  7. 7
    Brotli 1.2.0 (br)

    9.2 CVSS CVE-2026-111497 out-of-bounds write in c/dec/decode.c 1.0.3-1.2.0 – 5% better than zstd at 290 MB/s compress, 425 MB/s decompress but complex prefix trees

    Source ↗
  8. 8
    LZMA / xz 5.6

    Highest ratio ∼30% over gzip but 20x slower decompress and 2024 xz backdoor CVE-2024-3094 shows state-machine risk

  9. 9
    bzip2 1.0.8

    Burrows-Wheeler + Huffman, 200x slower than LZ4, ratio ∼1.15x gzip – low RCE history but decompression bomb still viable

  10. 10
    LZW / compress (.Z)

    1970s dictionary growth without entropy stage – ratio 0.9x gzip, patent expired, trivial parser but no modern web use

    Source ↗

What Meta noticed

Zstd at level -1 hits 510 MB/s compress and 1550 MB/s decompress vs gzip 105/390 and brotli 290/425 on same i7-9700K Silesia – 5x faster than gzip with 2.896 vs 2.743 ratio

Source ↗

GZIP still king: W3Techs 82% of all tracked sites use GZIP, 93.4% use any compression per Oct 2026, so zlib attack surface is universal even though code is simplest

Source ↗
🇺🇸 Grok10 places

The same question, answered by Grok alone. The final list above combines all the AIs.

  1. 1
    Zstandard (zstd)

    Decompresses at 1+ GB/s while matching or beating mid-level Brotli ratios at a fraction of the CPU, making the final 10% bandwidth gain cheap rather than exponential.

  2. 2
    Brotli

    Still the densest static-web winner (15–35% smaller than gzip) but the October 2026 decoder OOB-write (CVE-2026-111497, CVSS 9.2) showed exactly why complex state machines become premier attack surfaces.

    Source ↗
  3. 3
    gzip / zlib deflate

    Universal fallback that still ships in every browser and HTTP stack; mature but still accumulates heap-overflow CVEs decades later.

  4. 4
    LZ4

    Extreme decompression speed (often >3 GB/s) at the cost of the weakest ratios; ideal when latency dominates bandwidth.

    Source ↗
  5. 5
    Snappy

    Google’s speed-first design still appears in many RPC and storage paths; ratio is deliberately sacrificed for predictable low-CPU decode.

    Source ↗
  6. 6
    XZ / LZMA

    Highest ratios on text but decompression is an order of magnitude slower; complexity has historically produced fewer web-facing remote CVEs simply because it is rarely used for unauthenticated HTTP payloads.

  7. 7
    LZO

    Still present in embedded and some filesystem contexts; ratio and speed sit between gzip and LZ4 with a smaller public CVE footprint.

  8. 8
    bzip2

    Legacy high-ratio choice that is almost never used for live web response encoding because both compression and decompression are too slow for modern HTTP.

  9. 9
    deflate (raw / PNG-style)

    The same algorithm family as gzip but without the header; still the workhorse inside many image and archive formats that web runtimes must parse.

  10. 10
    lzma2 (XZ variant)

    Slightly more flexible than classic LZMA but still belongs to the “maximum ratio, minimum speed” corner that web protocols largely abandoned.

🇺🇸 Gemini10 places · 2 notes

The same question, answered by Gemini alone. The final list above combines all the AIs.

  1. 1
    Zstandard (Zstd)

    Decodes web text at over 1,200 MB/s per core while avoiding the static dictionary attack surface that plagued rival codecs.

    Source ↗
  2. 2
    LZ4

    Prioritizes byte-aligned streaming to achieve 4,500 MB/s decompression with a parser so compact it resists parser-state memory corruption.

    Source ↗
  3. 3
    Gzip / DEFLATE

    Powers 47.1% of compressed web traffic through thirty years of continuous binary fuzzing, despite a 350 MB/s decoding ceiling.

    Source ↗
  4. 4
    Snappy

    Rejects variable-length Huffman entropy tables entirely, guaranteeing microsecond wire decoding at the cost of a 15% larger transfer payload.

    Source ↗
  5. 5
    Brotli

    Achieves an unmatched 3.65x text reduction via a 122 KB static dictionary, but exposed ingress runtimes to emergency remote memory-corruption patching.

    Source ↗
  6. 6
    Zlib-ng

    Doubles standard DEFLATE decompression to 850 MB/s through AVX2 vectorization while maintaining strict RFC 1951 backward compatibility.

    Source ↗
  7. 7
    LZO

    Pioneered real-time ring-buffer parsing in 1996, but an integer overflow in 2014 proved that unmaintained decades-old decompression C code rarely ages safely.

    Source ↗
  8. 8
    Bzip2

    Employs the Burrows-Wheeler Transform to squeeze text efficiently, but bottlenecks ingress servers at an unacceptable 38 MB/s decompression rate.

    Source ↗
  9. 9
    XZ / LZMA2

    Yields an exceptional 4.10x ratio on structured assets, but requires up to 64 MB of decompression state memory per incoming connection.

  10. 10
    Deflate64

    Expanded DEFLATE's sliding window to 64 KB, adding esoteric parsing edge cases without providing the throughput benefits of modern streaming codecs.

What Gemini noticed

Chasing the final 10% payload reduction between DEFLATE (3.12x) and Brotli (3.65x) demands a 122 KB predefined dictionary and multi-level dynamic Huffman tables that expanded reference C parser state complexity by more than 400%.

Source ↗

Finite State Entropy (FSE) used in Zstandard reaches fractional bit precision like arithmetic coding while decompressing at over 1.2 GB/s per core, proving high compression does not necessitate unsafe parsing complexity.

Source ↗
🇺🇸 Nova5 places

The same question, answered by Nova alone. The final list above combines all the AIs.

  1. 1
    OpenSSL

    The cryptographic backbone of the web, handling TLS/SSL for 67% of HTTPS sites but plagued by recurring memory-corruption flaws.

  2. 2
    Zlib

    Ubiquitous compression library powering gzip and deflate, with a decades-long history of buffer-overread and overflow vulnerabilities.

  3. 3
    nghttp2

    HTTP/2 implementation used by Cloudflare and Nginx, suffering from heap-corruption flaws in stream management.

  4. 4
    Brotli

    Google's high-ratio compressor, now infamous for CVE-2026-111497 allowing remote code execution via malformed streams.

  5. 5
    libxml2

    XML parser for PHP, Python, and Ruby, with historical buffer-overflow issues in entity expansion and buffer handling.

    Source ↗
🇨🇳 StepFun10 places · 3 notes

The same question, answered by StepFun alone. The final list above combines all the AIs.

  1. 1
    Zstandard (zstd, RFC 8878)

    The only top-tier web codec whose reference C decoder has never had a memory-corruption CVE.

    Source ↗
  2. 2
    Brotli (RFC 7932)

    Best ratio on the live web - and the only codec that shipped a remote-code-execution decoder bug in October 2026.

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

    Still compresses 60% of the web's JavaScript versus Brotli's 29% - on a 30-year-old inflate() with 19 CVEs behind it.

  4. 4
    LZ4

    Decompresses in the GB/s range per core and its decoder is small enough to audit in an afternoon - if you can live with the ratio.

    Source ↗
  5. 5
    Snappy

    250 MB/s in, 500 MB/s out - and a ratio 20-100% worse than gzip, which is exactly why it lost the web.

  6. 6
    Zopfli

    Buys the last 3-8% of DEFLATE density at roughly 100x the compression cost - and adds exactly zero decoder attack surface.

    Source ↗
  7. 7
    LZMA / xz (liblzma)

    Best general-purpose ratio in the set - and the only one that shipped a deliberate backdoor into the reference tarballs.

  8. 8
    bzip2

    A 2009-era format still inside Python's stdlib whose BZ2_decompress kept writing out of bounds until 2019.

  9. 9
    zlib-ng

    A drop-in zlib replacement that is measurably faster - and carries its own short but real CVE list.

    Source ↗
  10. 10
    LZO (liblzo2)

    Four CVEs in one 2014 afternoon, all integer overflows in the literal-run decoder - the cautionary tale of a 'fast' codec.

What StepFun noticed

The adoption curve and the efficiency curve point in opposite directions: Brotli went from 28% to 37% of mobile pages between 2023 and 2024, yet gzip still compresses 60% of JavaScript responses versus Brotli's 29% - most of the web never made the switch to the better codec.

Source ↗

At the entry level the speed gap is not marginal: zstd compresses at 510 MB/s against Brotli's 290 and gzip's 105, and decompresses at 1,550 MB/s against Brotli's 425 - which is why CDNs increasingly pick zstd for dynamic content and Brotli only for pre-compressed static assets.

Source ↗

The most pointed criticism of Brotli is not that it compresses badly but that its whole advantage is 'such an ugly hack' - a hardcoded dictionary - and even that claim is contested, with commenters reporting Brotli still wins on web compression with the dictionary zeroed out.

Source ↗
🇨🇳 Kimi10 places

The same question, answered by Kimi alone. The final list above combines all the AIs.

  1. 1
    Zstandard (zstd, RFC 8878)

    Beats gzip on ratio (~10-15% smaller) while decoding ~2x faster than Brotli — with zero memory-corruption CVEs in its decoder.

    Source ↗
  2. 2
    Brotli (RFC 7932)

    Best ratio on web text (15-20% smaller than gzip) — and, as of this week, a live unauthenticated decoder RCE (CVE-2026-111497).

  3. 3
    DEFLATE / zlib (gzip)

    The floor every client understands: 93.4% of sites compress responses, and nearly all of those bytes end up in a 30-year-old inflate().

  4. 4
    Zopfli (Google)

    An encoder-only DEFLATE optimizer: it wins the ratio battle with zero new decoder attack surface, because every client already decodes its output.

    Source ↗
  5. 5
    LZ4

    Fastest decoder on the list — and its one famous memory bug (CVE-2021-3520) was a single memmove() integer overflow.

    Source ↗
  6. 6
    Snappy (Google)

    LevelDB/MongoDB's house codec: the cleanest C++ vulnerability record here, traded for the weakest compression ratio.

  7. 7
    xz / LZMA (liblzma)

    Best ratio outside Brotli — but its decoder keeps finding new bug classes, and its worst CVE (10.0) came from the maintainer, not the math.

  8. 8
    bzip2 (Burrows-Wheeler)

    A 2019 out-of-bounds write scored 9.8 Critical at NVD and 4.4 at Red Hat — the purest case of 'vulnerability density' being a scoring decision.

  9. 9
    LZW (Unix compress)

    The only entry retired by a lawyer rather than a memory bug: Unisys's patent (US 4,558,302) expired June 20, 2003 — after the web had already fled GIF for PNG.

    Source ↗
  10. 10
    Shared Brotli (Compression Dictionary Transport)

    The frontier: per-site shared dictionaries give repeat visitors Brotli-plus ratios with the least-fuzzed decoder state machine on the web.

    Source ↗
🇨🇳 DeepSeek10 places · 2 notes

The same question, answered by DeepSeek alone. The final list above combines all the AIs.

  1. 1
    Zstandard (zstd) 2026

    Decompresses at 1,550 MB/s while matching Brotli's ratio — the rare case where the faster decoder is also the simpler attack surface.

    Source ↗
  2. 2
    Brotli 2026

    Best-in-class web-text ratio (2.883) just produced a CVSS 9.2 out-of-bounds write in its reference C decoder — the poster child for the diminishing-returns judgment.

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

    The internet's default for three decades: 2.743x ratio and 390 MB/s decode, but 14–19 CVEs make it the most historically attacked web codec.

  4. 4
    LZ4 2026

    Multi-GB/s decompression makes it the throughput king, but its ~2.1x ratio costs roughly 25% more bytes than zstd — and its C decoder has a far smaller CVE footprint.

    Source ↗
  5. 5
    XZ / LZMA2 2026

    Highest ratio on the board (3.43x) but decompresses at 35 MB/s and suffered a CVSS 10.0 supply-chain backdoor — maximum compression, maximum risk.

  6. 6
    bzip2 2026

    Block-sorting compression delivers strong ratio on text but decompresses slowly and has a long tail of integer-overflow and out-of-bounds CVEs.

  7. 7
    Snappy 2026

    Google's LZ77 variant prioritizes speed over ratio; the core C++ library is lean, but Java bindings have recently produced CVSS 7.5+ heap overflows.

    Source ↗
  8. 8
    LZO 2026

    Designed for real-time decompression, LZO hits 217 MB/s at a 2.64x ratio but has almost no web-native CVE history — a low-attack-surface workhorse.

  9. 9
    DEFLATE (raw) 2026

    The raw RFC 1951 stream is the simplest possible web codec, but without gzip's CRC wrapper it still inherits zlib's 19-CVE inflate history.

    Source ↗
  10. 10
    LZMA (alone) 2026

    The LZMA SDK delivers xz-class ratio without the .xz container, but its decoder is the slowest on this list and shares xz's complex state-machine attack surface.

What DeepSeek noticed

Brotli's complexity buys it roughly 5% better ratio than gzip on web text, but its decoder just produced CVE-2026-111497, a CVSS 9.2 out-of-bounds write reachable through automatic HTTP decompression. The marginal gain is now measured in attack surface.

Source ↗

LZ4's decompressor is orders of magnitude faster than xz's (218 MB/s in the SquashFS benchmark vs 35 MB/s for xz), but it pays with a 2.12x ratio vs 3.43x — a 62% larger payload. The fastest codec is not the most bandwidth-efficient one.

Source ↗
🇨🇳 Wenxin10 places · 1 notes

The same question, answered by Wenxin alone. The final list above combines all the AIs.

  1. 1
    Zstandard (zstd)

    5x faster compression, 4x faster decompression than zlib at comparable fast settings with slightly better ratio, no built-in static dictionary to inflate attack surface

    Source ↗
  2. 2
    Gzip

    Universal web fallback with decades of public fuzz testing covering nearly all trivial memory corruption flaws

    Source ↗
  3. 3
    Brotli

    120 KB built-in static dictionary delivers strong text compression but now carries a public PoC for a critical 2026 out-of-bounds write vulnerability

    Source ↗
  4. 4
    Deflate

    Raw DEFLATE specification that powers gzip, no extra HTTP wrapping logic to introduce additional parsing attack surface

    Source ↗
  5. 5
    LZ4

    Optimized for near-memory line decompression, prioritizes speed over maximum compression ratio for low-latency workloads

    Source ↗
  6. 6
    Snappy

    Google-developed low-complexity algorithm designed to avoid decoder-side complexity that leads to memory safety flaws

    Source ↗
  7. 7
    LZF

    Minimal C implementation with under 2000 lines of code, minimal structural parsing complexity for HTTP use cases

  8. 8
    LZMA

    Extremely high maximum compression ratio at the cost of exponential decompression complexity and very low throughput

  9. 9
    Bzip2

    Burrows-Wheeler transform based algorithm rarely used on modern web due to slow speeds and no active security maintenance

  10. 10
    DEFLATE64

    Extended DEFLATE variant with larger window sizes that introduces additional state logic with no standard HTTP web support

    Source ↗

What Wenxin noticed

At comparable fast performance settings, Zstandard decompresses nearly 4x faster than zlib with a slightly better compression ratio, a 2026 benchmark confirms

Source ↗
🇨🇳 Qwen10 places · 2 notes

The same question, answered by Qwen alone. The final list above combines all the AIs.

  1. 1
    LZ4

    Decompresses at RAM speeds with a state machine so simple it barely registers on vulnerability scanners.

  2. 2
    Zstandard (Zstd)

    Facebook's engineering marvel balances near-LZ4 decompression speeds with gzip-beating ratios.

    Source ↗
  3. 3
    Snappy

    Google's speed-first compressor sacrifices ratio for sheer decompression throughput, keeping parser logic brutally minimal.

  4. 4
    Brotli

    The web's heavy-lifter for static assets, until a complex dictionary parser triggers the October 2026 PHP2Shell and HTTP2Shell RCE flaws.

  5. 5
    Deflate (zlib)

    The 30-year-old backbone of HTTP that trades a massive, well-documented catalog of integer wraparounds for universal compatibility.

    Source ↗
  6. 6
    Gzip

    Just a 10-byte header wrapped around Deflate, inheriting every historical memory corruption flaw of its underlying engine.

    Source ↗
  7. 7
    LZMA / XZ

    Achieves miraculous ratios by building enormous dictionary state machines that famously invited a supply-chain backdoor in 2024.

    Source ↗
  8. 8
    Bzip2

    The Burrows-Wheeler transform is mathematically elegant but computationally heavy and largely abandoned by modern web standards.

    Source ↗
  9. 9
    LZFSE

    Apple's proprietary energy-efficient codec offers great mobile battery life but introduces opaque state logic outside the standard open web.

    Source ↗
  10. 10
    Zopfli

    An encoder-only curiosity that takes hours to compress a file just to output standard Deflate data, offering zero decompression security benefits.

    Source ↗

What Qwen noticed

Zstd and LZ4 show that you don't need exponential parsing complexity to achieve excellent web performance; simple byte-oriented LZ77 derivatives maintain high throughput with minimal memory attack surface.

Source ↗

The diminishing return is real: XZ and LZMA achieve better ratios but require such massive dictionary state machines that they become prime targets for supply-chain attacks and memory corruptions.

Source ↗