curl-Sicherheitslücke bei HTTP/2-Uploads in 8.23.0 behoben
Die als CVE-2026-92392 erfasste curl-Sicherheitslücke ermöglicht es einem böswilligen Server, der einen HTTP/2-Upload empfängt, den Speicher des sendenden Clients zu beschädigen. curl behob die schwerwiegende Sicherheitslücke am 14. Oktober in Version 8.23.0, nachdem die meldende Person code execution demonstriert hatte, was bedeutet, dass der Server den hochladenden Computer dazu bringen konnte, ausgewählte Anweisungen auszuführen. Das Projekt geht dennoch davon aus, dass die meisten realen Ausnutzungsversuche das betroffene Programm zum Absturz bringen würden, da zuverlässige code execution detaillierte Kenntnisse über das Ziel erfordert.
Die Sicherheitslücke betrifft curl und libcurl in den Versionen 8.12.0 bis 8.22.0. curl ist ein Kommandozeilenwerkzeug für Dateiübertragungen, während libcurl die zugrunde liegende Softwarebibliothek ist, die von vielen anderen Anwendungen verwendet wird. Bei der Sicherheitslücke handelt es sich um use-after-free. Dieser Fehler tritt auf, wenn Software einen Speicherbereich weiterverwendet, nachdem er für einen anderen Zweck freigegeben wurde. Sowohl das Kommandozeilenwerkzeug als auch Anwendungen, die mit der betroffenen Bibliothek erstellt wurden, können gefährdet sein.
Mehrere Bedingungen müssen erfüllt sein. Ein Client muss eine Datei von ungefähr 135 KB über HTTP/2, das Protokoll zur Abwicklung mehrerer Webübertragungen über eine Verbindung, auf einen vom Angreifer kontrollierten Server hochladen. Das Zertifikat des Servers muss die Prüfungen des Clients bestehen, und libcurl muss mit HTTP/2-Unterstützung erstellt worden sein. Bei Adressen, die mit https:// beginnen, handelt libcurl standardmäßig HTTP/2 aus, wenn der Server es anbietet. Der verwundbare Code ist in jeder curl-Version seit 8.12.0 enthalten, die im Februar 2025 veröffentlicht wurde. Keine Quelle berichtet von Angriffen, die diese Sicherheitslücke ausnutzen.
Der Fehler beginnt, wenn der feindliche Server den Upload anhält, indem er das HTTP/2 transfer window auf null reduziert. Er sendet einen Teil einer Antwort zurück, setzt den stream zurück und lässt die Verbindung geöffnet. curl interpretiert diesen Reset als Grund, die Übertragung erneut zu versuchen. Während der Bereinigung teilen die betroffenen Versionen zunächst der HTTP/2-Schicht mit, dass die Übertragung beendet sei, und schreiben anschließend die verbleibenden Upload-Daten in dieselbe Verbindung.
Da die Übertragung zu diesem Zeitpunkt nicht mehr registriert ist, können die übrig gebliebenen Daten als neue Anfrage interpretiert werden. Der proof of concept platziert ein bestimmtes Zeilenmuster in der hochgeladenen Datei, sodass diese Bytes wie Anfragezeilen aussehen. libcurl erstellt daraufhin einen weiteren stream und speichert einen pointer auf das easy handle der Übertragung, ein internes Objekt zur Verwaltung eines einzelnen Vorgangs. Der erneute Versuch wird über eine neue HTTP/1.1-Verbindung abgeschlossen, woraufhin die Anwendung dieses handle freigibt. Die ursprüngliche Verbindung behält den pointer jedoch weiterhin und kann ihn verwenden, wenn der Server einen weiteren frame sendet, auch während das Programm beendet wird.
Bei dem demonstrierten Exploit belegen vom Server kontrollierte Daten den Speicher, den zuvor das freigegebene handle verwendet hatte. Eine ausgehende Anfrage legt dann lokale Speicheradressen offen, die zur Umgehung von address space layout randomization (ASLR) benötigt werden, einer Schutzmaßnahme, die verändert, wo Programmdaten im Speicher abgelegt werden. Der Exploit ersetzt einen function pointer durch vom Server gelieferte Bytes, woraufhin curl diesen pointer aufruft. Laut der Sicherheitsempfehlung von curl erfordert ein Erfolg die exakte curl-Version, Prozessorarchitektur, den libc allocator und das heap layout. Zudem hängt er von präzisem Timing bei zwei parallelen Übertragungen und davon ab, dass der payload in ungefähr 23 Bytes passt. curl bewertete eine erfolgreiche Übernahme daher als unwahrscheinlich und erklärte, dass ein Absturz das wahrscheinlichere Ergebnis sei.
Benutzer sollten curl und libcurl 8.23.0 installieren. Die Sicherheitsempfehlung nennt außerdem korrigierte Versionen für drei ältere Entwicklungszweige: 8.14.3 für 8.14.x, 8.16.2 für 8.16.x und 8.20.2 für 8.20.x. Debian 13, auch als trixie bekannt, stellt laut dem Tracker von Debian über DSA-6558-1 die Version 8.14.1-2+deb13u7 bereit. Debian 12 beziehungsweise bookworm enthält den verwundbaren Code nicht. Das Projekt erklärte außerdem, dass aktualisierte Rock-solid curl-Versionen, seine langfristig unterstützte Produktlinie für Kunden mit Supportverträgen, zusammen mit 8.23.0 ausgeliefert würden. Die Veröffentlichung behebt insgesamt 24 CVEs; die übrigen 23 sind mit Low bewertet.
Wenn ein sofortiges Update nicht möglich ist, empfiehlt curl, HTTP/2 zu vermeiden. Benutzer der Kommandozeile können mit der Option --http1.1 HTTP/1.1 anfordern. Anwendungen, die libcurl verwenden, können CURLOPT_HTTP_VERSION auf CURL_HTTP_VERSION_1_1 setzen. curl weist darauf hin, dass dies eine Anforderung und keine absolute Garantie ist, da die Anwendung möglicherweise eine vorhandene Verbindung wiederverwendet, die eine andere Protokollversion nutzt. Ein libcurl-Build, der ohne HTTP/2-Unterstützung kompiliert wurde, kann den betroffenen Upload-Pfad nicht erreichen.
Die Korrektur besteht aus einer sechs Zeilen umfassenden Neuordnung in lib/multi.c. libcurl schreibt nun die verbleibenden Upload-Daten, bevor die HTTP/2-Schicht ihre Referenzen auf das transfer handle freigibt. Der Bericht ging am 15. September über HackerOne ein, und curl bestätigte ihn innerhalb weniger Stunden. Am 7. Oktober kündigte das Projekt eine bevorstehende Korrektur mit der Einstufung High an und verkürzte seinen Veröffentlichungszyklus von acht auf sechs Wochen. Dies war die erste mit High bewertete Sicherheitslücke von curl seit dem SOCKS5 heap overflow im Oktober 2023. curl verwendet vier Schweregradkategorien und veröffentlicht keinen Score nach dem Common Vulnerability Scoring System (CVSS). Die National Vulnerability Database hatte ihre Analyse mit Stand vom 14. Oktober noch nicht abgeschlossen.
curl schrieb die Entdeckung dem OSS Scanner von Anthropic zu, einem am 8. Oktober eröffneten opt-in-Dienst, der KI-Modelle verwendet, um angemeldete Open-Source-Projekte zu untersuchen. Laut Anthropic versendet der Dienst Ergebnisse ohne menschliche Prüfung per E-Mail und fügt einen reproducer sowie, sofern verfügbar, einen möglichen Patch bei. Dieser Bericht wurde drei Wochen vor dem öffentlichen Start des Dienstes eingereicht. Der öffentliche HackerOne-Eintrag, einschließlich eines bösartigen Serverskripts und eines Docker-Containers, der als reproducer für code execution beschrieben wurde, erschien am 14. Oktober zusammen mit der Sicherheitsempfehlung von curl.
Der Fund folgt außerdem auf Bedenken von curl hinsichtlich minderwertiger, von KI erzeugter Berichte. Im Juli 2025 schrieb ein curl-Maintainer, dass etwa ein Fünftel der Sicherheitseinsendungen des betreffenden Jahres als AI slop eingestuft worden sei und sich nur ungefähr eine von zwanzig als gültig erwiesen habe. Das Projekt reduziert außerdem interne pointer auf transfer handles zugunsten von Kennungen, die bei Bedarf nachgeschlagen werden, erklärt jedoch, dass dies nicht garantiert, dass kein weiterer use-after-free auftritt. Es betrachtet diese Sicherheitslücke als jene Art von Fehler bei der Speicherverwaltung, die eine memory-safe language wahrscheinlich verhindern würde, plant jedoch nicht, curl in einer solchen Sprache neu zu schreiben.
Websitebetreiber sollten ihren Hostinganbieter oder den Betreuer ihrer Anwendung fragen, ob betroffene libcurl-Pakete installiert sind, da Anwendungen die Bibliothek verwenden können, ohne sie direkt sichtbar zu machen. Organisationen, die die Systeme rund um betroffene Anwendungen überprüfen, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen an.