Înapoi la Noutăți
Amenințări

curl 8.23.0 corectează o vulnerabilitate use-after-free la upload-urile HTTP/2 care poate duce la execuție de cod (CVE-2026-92392)

O vulnerabilitate High de tip use-after-free în curl și libcurl 8.12.0–8.22.0 permite unui server rău-intenționat să corupă memoria clientului la upload-uri HTTP/2. Cel mai probabil rezultat este un crash, dar un PoC arată că execuția de cod este posibilă. Actualizați la 8.23.0.

curl 8.23.0 corectează o vulnerabilitate use-after-free la upload-urile HTTP/2 care poate duce la execuție de cod (CVE-2026-92392)

curl 8.23.0 corectează o vulnerabilitate use-after-free la upload-urile HTTP/2 (CVE-2026-92392)

Proiectul curl a lansat versiunea 8.23.0 pe 14 octombrie 2026. Aceasta închide o vulnerabilitate de tip use-after-free în modul în care curl și libcurl gestionează upload-urile prin HTTP/2. Problema este înregistrată ca CVE-2026-92392 și permite unui server rău-intenționat care primește un upload să corupă memoria clientului. Cercetătorul care a raportat-o a arătat că, în condiții foarte controlate, problema poate fi transformată în execuție de cod pe mașina care face upload-ul.

curl evaluează problema ca High pe propria scală cu patru niveluri. Este prima vulnerabilitate de severitate High de la heap overflow-ul SOCKS5 din octombrie 2023. Proiectul estimează că, într-un atac real, cel mai probabil rezultat ar fi doar blocarea (crash-ul) clientului, nu execuție de cod.

Ce s-a întâmplat

  • Versiuni afectate: curl și libcurl 8.12.0 până la 8.22.0, adică toate versiunile din februarie 2025 încoace. Sunt afectate atât utilitarul în linie de comandă, cât și biblioteca.
  • Direcția atacului: de la server către client. Victima trebuie să încarce date (aproximativ 135 KB sau mai mult) prin HTTP/2 către un server controlat de atacator, iar certificatul TLS al serverului trebuie să treacă verificările clientului.
  • Condiție: libcurl trebuie să fie compilat cu suport HTTP/2. În acest caz, libcurl negociază implicit HTTP/2 pentru adresele https:// atunci când serverul îl oferă.
  • Exploatare: nu au fost raportate atacuri reale. Raportul HackerOne al cercetătorului, cu un server proof-of-concept și o reproducere în Docker, a devenit public odată cu avizul.

Pe scurt, un server ostil poate bloca temporar upload-ul, poate reseta fluxul HTTP/2 și îl poate păcăli pe curl să reîncerce. Astfel rămâne în memorie un pointer către un obiect de transfer deja eliberat. Pentru execuție de cod, atacatorul trebuie să cunoască exact versiunea curl, arhitectura, alocatorul de memorie și structura heap-ului. De asemenea, trebuie să sincronizeze precis două transferuri paralele și să încapă cu payload-ul în aproximativ 23 de octeți. Din acest motiv curl a clasificat problema High, nu Critical. Corecția este o mică reordonare în lib/multi.c, astfel încât stratul HTTP/2 renunță la referințe abia după ce datele de upload rămase au fost trimise.

curl nu publică scoruri CVSS. La 14 octombrie, NVD nu analizase încă înregistrarea, deci evaluările altor surse pot diferi.

Vulnerabilitatea a fost raportată pe 15 septembrie, iar curl o atribuie lui „Luna with Claude, Anthropic”. Maintainerul curl spune că descoperirea a venit prin noul serviciu OSS Scanner al Anthropic, un program de identificare a bug-urilor asistat de AI pentru proiecte open-source. Cazul este relevant în dezbaterea despre rapoartele de vulnerabilități generate cu AI, pe care echipa curl le-a criticat anterior ca fiind în mare parte zgomot.

De ce contează

curl și libcurl sunt prezente într-o gamă uriașă de software: pipeline-uri CI/CD, agenți de backup și sincronizare, manageri de pachete, sisteme de actualizare firmware, dispozitive IoT și nenumărate aplicații care folosesc libcurl pentru transferuri HTTP. Multe dintre acestea încarcă date automat către servere externe. Oricare dintre ele poate fi expus dacă comunică prin HTTP/2 cu un server devenit ostil, fie prin compromitere, printr-un domeniu preluat sau printr-un endpoint malițios. Impactul cel mai probabil este o întrerupere a serviciului (crash). Execuția de cod este posibilă teoretic, dar greu de obținut în mod fiabil.

Aceeași versiune corectează în total 24 de CVE-uri. Celelalte 23 sunt evaluate Low.

Ce trebuie să faceți

  1. Actualizați la curl/libcurl 8.23.0. Dacă folosiți o ramură mai veche, instalați versiunile corectate 8.14.3, 8.16.2 sau 8.20.2. Clienții cu contract de suport curl primesc versiuni LTS echivalente.
  2. Actualizați și copiile pe care nu le vedeți. Inventariați libcurl inclus static sau împachetat în containere, echipamente, SDK-uri și software de la terți, și verificați SBOM-urile pentru versiuni afectate.
  3. Distribuții Linux: aplicați actualizarea furnizorului. Pe Debian 13 (trixie), pachetul corectat este 8.14.1-2+deb13u7 (DSA-6558-1). Debian 12 (bookworm) nu conține codul vulnerabil.
  4. Dacă nu puteți actualiza încă, evitați HTTP/2 pentru upload-uri. Folosiți --http1.1 în linia de comandă sau setați CURLOPT_HTTP_VERSION la CURL_HTTP_VERSION_1_1 în aplicații. Rețineți că setarea este doar o cerere, iar o conexiune existentă pe altă versiune de protocol poate fi refolosită. Versiunile compilate fără suport HTTP/2 nu pot ajunge la codul vulnerabil.
  5. Limitați destinațiile upload-urilor automate. Permiteți doar endpoint-uri cunoscute și de încredere și păstrați validarea strictă a certificatelor.

Evaluările de vulnerabilități 4Tify identifică versiunile învechite de curl/libcurl din infrastructura expusă și din inventarul software. Contactați-ne dacă vreți ajutor să aflați unde se ascunde libcurl în mediul dumneavoastră.


Acest material se bazează pe informații publicate inițial de The Hacker News și pe avizul de securitate al proiectului curl.

DISTRIBUIE