Für den Angriff muss der Client eine Datei von rund 135 KB per HTTP/2 an den Server des Angreifers hochladen, und dessen Zertifikat muss die Prüfungen des Clients bestehen. libcurl handelt HTTP/2 bei https://-URLs standardmäßig aus, sofern der Server es anbietet und die Bibliothek mit HTTP/2-Unterstützung gebaut wurde.
Es ist die erste als hoch eingestufte Lücke seit dem SOCKS5-Heap-Overflow vom Oktober 2023. curl verwendet eine eigene vierstufige Skala und veröffentlicht keine CVSS-Werte; die National Vulnerability Database hatte den Eintrag am 14. Oktober noch nicht analysiert. Der Fehler steckt in jeder curl-Version seit 8.12.0 vom Februar 2025. Angriffe, die ihn ausnutzen, sind nicht bekannt. Der HackerOne-Bericht des Melders — mit dem Skript für den bösartigen Server und einem Docker-Container, der die Codeausführung reproduzieren soll — wurde zusammen mit dem Sicherheitshinweis am 14. Oktober öffentlich.
Die Veröffentlichung behebt insgesamt 24 CVEs; die übrigen 23 sind als niedrig eingestuft. Das Projekt verkürzte seinen Release-Zyklus um zwei Wochen, um den Fix auszuliefern.
Empfohlen wird das Upgrade auf 8.23.0 oder das Einspielen des Fix-Commits in einen lokalen Build. Der maschinenlesbare Sicherheitshinweis nennt zudem korrigierte Versionen auf drei älteren Zweigen; parallel zu 8.23.0 will das Projekt aktualisierte Rock-solid-curl-Releases bereitstellen, seine Langzeit-Supportlinie für Kunden mit Supportvertrag:
- curl und libcurl 8.12.0 bis 8.22.0: Upgrade auf 8.23.0
- Zweig 8.14.x: 8.14.3
- Zweig 8.16.x: 8.16.2
- Zweig 8.20.x: 8.20.2
- Debian 13 (trixie): 8.14.1-2+deb13u7 über DSA-6558-1, laut Debians Security-Tracker. Debian 12 (bookworm) enthält den verwundbaren Code nicht.
Wer nicht sofort aktualisieren kann, soll nach Empfehlung des Projekts auf HTTP/2 verzichten. Die Option –http1.1 fordert für das Werkzeug HTTP/1.1 an, Anwendungen setzen CURLOPT_HTTP_VERSION auf CURL_HTTP_VERSION_1_1. Die Dokumentation bezeichnet diese Einstellung ausdrücklich als Wunsch, da eine bestehende Verbindung mit einer anderen Protokollversion wiederverwendet werden kann. HTTP/2-Unterstützung in libcurl ist eine Build-Option: Ein Build ohne sie kann HTTP/2 nicht aushandeln und damit den im Hinweis beschriebenen Upload-Pfad nicht erreichen.
Daniel Stenberg, Hauptentwickler von curl, hat den Fehler in einem zur Veröffentlichung erschienenen Beitrag erläutert; der öffentliche Bericht beschreibt den Codepfad. HTTP/2 überträgt mehrere Transfers über eine Verbindung, libcurl verwaltet jeden Transfer über ein Objekt, das es Easy Handle nennt. Während eines Uploads bringt der Server den Transfer zum Stillstand, indem er das HTTP/2-Fenster auf null setzt, einen Teil der Antwort zurückgibt und anschließend den Stream zurücksetzt, während die Verbindung offen bleibt. curl wertet das Reset als Anlass für einen erneuten Versuch.
Beim Aufräumen teilt curl zuerst der HTTP/2-Schicht mit, dass der Transfer beendet ist, und schiebt dann den Rest der noch nicht gesendeten Upload-Daten in dieselbe Verbindung. Da kein Transfer mehr registriert ist, werden diese übrigen Bytes als neue Anfrage gelesen. Das Zeilenmuster, das der Melder in die hochgeladene Datei einfügt, lässt sie wie Anfragezeilen aussehen. In diesem Fall wird ein neuer Stream geöffnet, der einen Zeiger auf das Easy Handle speichert. Der Wiederholungsversuch läuft über eine neue HTTP/1.1-Verbindung durch, und die Anwendung gibt das Handle frei. Die alte Verbindung hält den Zeiger weiterhin und nutzt ihn, sobald der Server einen Frame auf diesem Stream sendet — was auch beim Beenden des Programms geschehen kann.
Im Exploit des Melders landen vom Server gesendete Daten in dem Speicher, den das freigegebene Handle belegt hatte. Eine ausgehende Anfrage verrät lokale Adressen, die der Server benötigt, um die Adressraum-Zufallsanordnung (ASLR) zu umgehen. Ein Funktionszeiger in diesem Speicher wird mit Bytes vom Server überschrieben, und curl ruft ihn anschließend auf.
Laut Sicherheitshinweis muss ein Angreifer für Codeausführung die genaue curl-Version, die Architektur, den libc-Allokator und das Heap-Layout des Ziels kennen, zwei parallele Transfers im richtigen Timing halten und die Nutzlast in rund 23 Bytes unterbringen. „Das wahrscheinlichste Ergebnis eines Angriffsversuchs ist eher einfach ein Absturz“, schrieb Stenberg und bezeichnete die Erfolgsaussichten als gering. Deshalb stufte curl die Lücke als hoch und nicht als kritisch ein.
Der Fix besteht aus einer sechszeiligen Umsortierung in lib/multi.c von Stefan Eissing: Die HTTP/2-Schicht gibt ihre Referenzen auf das Handle nun erst auf, nachdem die restlichen Upload-Daten ausgeschrieben wurden, und nicht mehr davor.
Der Bericht erreichte curl nach Angaben Stenbergs am 15. September über HackerOne, das Sicherheitsteam bestätigte ihn binnen Stunden. Am 7. Oktober kündigte das Projekt vorab einen Fix mit hoher Schwere für die nächste Veröffentlichung an und verkürzte seinen Zyklus von acht auf sechs Wochen.
Als Finder nennt curl „Luna with Claude, Anthropic“. Stenberg benennt die Melderin als Luna Tong von Anthropic, führt den Fund auf den neuen OSS Scanner des Unternehmens zurück und geht davon aus, dass dessen KI-Modelle beteiligt waren. Anthropic hatte OSS Scanner am 8. Oktober als Opt-in-Dienst gestartet, der eingetragene Open-Source-Projekte mit seinen Modellen untersucht und die Ergebnisse ohne menschliche Prüfung per E-Mail versendet — jeder Bericht mit einem Reproducer und, sofern verfügbar, einem Patch-Vorschlag. Der curl-Bericht kam drei Wochen vor diesem öffentlichen Start. Im Startbeitrag von Anthropic wird Stenberg mit den Worten zitiert, der Scanner habe „eine der schlimmsten curl-Schwachstellen der letzten Jahre“ zutage gefördert, ohne dass eine konkrete genannt wurde.
Derselbe Maintainer hatte im Juli 2025 geschrieben, dass rund ein Fünftel der curl-Sicherheitsmeldungen jenes Jahres das war, was er als KI-Schrott bezeichnete, und nur etwa eine von zwanzig sich als echt erwiesen habe.
Curl arbeite seit mehreren Jahren daran, die Zahl interner Zeiger auf Handles zugunsten von Bezeichnern zu reduzieren, die bei Bedarf nachgeschlagen werden, schrieb Stenberg — eine Garantie gegen weitere Use-after-free-Fehler sei das nicht. Das Projekt bezeichnet den Fehler als einen, den eine speichersichere Sprache wahrscheinlich vermieden hätte, plant aber keine Neuimplementierung von curl in einer solchen Sprache.