Înapoi la Noutăți
Amenințări

Vulnerabilități QPACK: o singură conexiune poate bloca servere HTTP/3, cu amplificare de memorie de până la 4.000×

O slăbiciune în compresia antetelor, prezentă în șapte din zece implementări HTTP/3 testate, permite unui atacator neautentificat să epuizeze memoria serverului dintr-o singură conexiune. Există remedieri pentru quic-go, Cloudflare quiche și lsquic; Bun, h3 și aioquic sunt încă vulnerabile.

Vulnerabilități QPACK: o singură conexiune poate bloca servere HTTP/3, cu amplificare de memorie de până la 4.000×

O singură conexiune, memorie epuizată: vulnerabilități QPACK în șapte implementări HTTP/3

HTTP/3 a fost gândit să facă web-ul mai rapid. O nouă clasă de vulnerabilități în stratul său de compresie a antetelor arată că poate și să doboare unele servere — dintr-o singură conexiune neautentificată, fără cont și fără acces special.

Ce s-a întâmplat

Cercetătorii FoxIO au testat zece implementări HTTP/3 și au găsit aceeași slăbiciune în șapte dintre ele. Problema se află în QPACK, mecanismul prin care HTTP/3 comprimă antetele cererilor, înlocuind câmpurile repetate cu referințe scurte către un tabel comun.

Problema ține de locul în care se aplică limita de dimensiune. Un server ar trebui să limiteze cât de mare poate deveni setul de antete după decodare. Implementările afectate verifică doar octeții comprimați primiți sau aplică limita prea târziu. Astfel, un atacator poate trimite un pachet compact pe care serverul îl extinde în sute de mii de antete — toate păstrate în memorie.

Au fost demonstrate două tehnici:

  • Extindere în masă — în testele FoxIO pe quic-go cu setări implicite, ~1 MB de date comprimate s-a transformat în circa 160.000 de antete și ~15 MB de memorie (aproximativ 17×; avertismentul proiectului estimează un plafon teoretic de ~50×).
  • Amplificare prin referințe — un antet de ~4 KB este stocat o dată, apoi referit de mii de ori cu referințe de un octet. Serverul reconstruiește antetul complet de fiecare dată: aproximativ 4.000× pe Bun și 600–1.800× pe lsquic în teste.

Bun este cel mai grav caz. Serverul său HTTP/3 (încă marcat experimental) se bazează pe lsquic, dar înlocuiește codul care limitează memoria pentru antete: verifică fiecare antet în parte, dar niciodată totalul. Peste 2 GB de antete decodate, un contor de dimensiune revine la zero, iar serverul rămâne blocat la 100% CPU — declanșat de un singur flux de ~516 KB.

Cine este afectat

Situația la 22 octombrie 2026:

ImplementareStareRemediat înIdentificator
quic-goRemediat0.57.0CVE-2025-64702
Cloudflare quicheRemediat0.29.3CVE-2026-12523
lsquicRemediat4.9.0—
WiresharkRemediat4.6.2 / 4.4.12CVE-2025-13945
BunNeremediat——
h3 (Rust / hyperium)Neremediat——
aioquic / mitmproxyNeremediat——

Impactul real e mai larg decât arată tabelul, pentru că aceste biblioteci stau la baza unor produse populare: quic-go rulează în Caddy, Traefik și cloudflared; lsquic este inclus în LiteSpeed Web Server și OpenLiteSpeed.

Wireshark este un caz separat: eroarea blochează disectorul HTTP/3 la decriptarea unei capturi cu chei de sesiune — nu este un server accesibil din rețea, iar proiectul nu raportează exploatări cunoscute.

IIS, Envoy, ngtcp2/nghttp3 și quiche de la Google sunt raportate ca neafectate, deoarece aplică limita în timpul decodării, nu după.

De ce contează

  • Doar refuz de serviciu (DoS) — nu există indicii de furt de date sau execuție de cod și nici atacuri raportate în prezent.
  • Dar pragul este foarte jos: fără cont, o singură conexiune, iar pentru că HTTP/3 rulează peste UDP, traficul poate ajunge la server înainte de o mare parte din filtrarea obișnuită la nivel HTTP.
  • Codul de tip proof-of-concept este public, ceea ce de obicei scurtează timpul până la abuzuri oportuniste.

Ce trebuie făcut

  1. Inventariați expunerea HTTP/3. Verificați ce servicii publice anunță HTTP/3 (antet Alt-Svc: h3 sau UDP/443 deschis) și ce implementare le servește — inclusiv Caddy, Traefik, cloudflared și LiteSpeed.
  2. Actualizați acum acolo unde există remedieri: quic-go ≥ 0.57.0, Cloudflare quiche ≥ 0.29.3, lsquic ≥ 4.9.0, Wireshark 4.6.2 / 4.4.12. Apoi recompilați și redistribuiți tot ce include aceste biblioteci.
  3. Atenuați riscul acolo unde nu există remediere:
    • Bun — nu expuneți serverul său HTTP/3.
    • mitmproxy — dezactivați HTTP/3 cu --set http3=false.
    • h3 (Rust) — setați o valoare rezonabilă pentru max_field_section_size.
  4. Luați în calcul revenirea la HTTP/2 pe endpoint-urile critice până la actualizare; clienții fac trecerea automat.
  5. Monitorizați creșterile bruște de memorie și procesele blocate pe serverele HTTP/3 și configurați alerte.

Astfel de vulnerabilități stau adânc în dependențe pe care majoritatea echipelor nu le verifică direct. Scanarea continuă a vulnerabilităților pe suprafața externă este modul în care echipa noastră identifică serviciile care rulează versiuni HTTP/3 afectate — ca să știți ce servere trebuie actualizate înainte să le găsească altcineva.


Credit cercetare: FoxIO (foxio.io). Raportat inițial de The Hacker News.

DISTRIBUIE