curl behebt schwerwiegende HTTP/2-Schwachstelle bei Uploads, die clientseitige Codeausführung ermöglicht

Das curl-Projekt hat am 14. Oktober Version 8.23.0 veröffentlicht, um eine Schwachstelle mit hohem Schweregrad zu beheben, die es bösartigen Servern ermöglicht, den Client-Speicher während HTTP/2-Uploads zu beschädigen. Die als CVE-2026-92392 verfolgte Sicherheitslücke wurde von Luna Tong von Anthropic entdeckt und betrifft alle curl- und libcurl-Versionen von 8.12.0 bis 8.22.0.

Was passiert ist

Diese Schwachstelle ermöglicht es einem von einem Angreifer kontrollierten Server, eine Remote-Code-Ausführung auf dem Client-Rechner zu initiieren, der Daten hochlädt. Der Angriff erfordert, dass der Client eine Datei von etwa 135 KB über HTTP/2 an einen bösartigen Server hochlädt, dessen Zertifikat die Standardvalidierungsprüfungen besteht. Während die theoretischen Auswirkungen eine vollständige Systemkompromittierung einschließen, weisen die curl-Maintainer darauf hin, dass eine erfolgreiche Ausnutzung schwierig ist und in den meisten realen Szenarien wahrscheinlich eher zu einem Absturz als zur Codeausführung führt.

Der Fehler war seit Version 8.12.0, die im Februar 2025 erschien, in jeder curl-Veröffentlichung vorhanden. Es handelt sich um die erste Hochschweregrad-Schwachstelle des Projekts seit dem Heap-Overflow in SOCKS5 im Oktober 2023. Als Reaktion auf die Entdeckung verkürzte das curl-Team seinen regulären achtwöchigen Veröffentlichungszyklus um zwei Wochen, um den Patch zeitnah bereitzustellen. Bislang wurden keine aktiven Exploits unter Verwendung dieser Schwachstelle gemeldet.

Der Fix adressiert insgesamt 24 CVEs in dieser Veröffentlichung, wobei die anderen 23 als geringfügig eingestuft werden. Das Projekt aktualisierte auch seine Langzeitunterstützungslinie, bekannt als Rock-solid-curl-Releases, um sie mit diesem Sicherheitspatch abzugleichen. Benutzer älterer unterstützter Zweige sollten auf spezifische gepatchte Versionen upgraden: 8.14.3 für den 8.14.x-Zweig, 8.16.2 für 8.16.x und 8.20.2 für 8.20.x.

Wie es funktioniert

Die Schwachstelle ist ein Use-after-Free-Fehler, der auf der Art zurückzuführen ist, wie libcurl HTTP/2-Transfers verwaltet. HTTP/2 erlaubt mehrere gleichzeitige Streams über eine einzelne Verbindung, und libcurl verfolgt jeden Transfer anhand eines Objekts namens Easy Handle. Während eines Uploads kann ein bösartiger Server den Transfer stoppen, indem er die HTTP/2-Fenstergröße auf null setzt, einen Teil der Antwort zurückgibt und dann den Stream zurücksetzt, während die zugrunde liegende Verbindung offen bleibt. Curl interpretiert dieses Zurücksetzen als Signal zum Wiederholen des Transfers.

In der Bereinigungsphase dieser Retry-Logik teilte curl der HTTP/2-Ebene zuvor mit, dass der Transfer abgeschlossen sei, bevor die verbleibenden ungesendeten Upload-Daten geleert wurden. Diese Reihenfolge bedeutete, dass Restbytes in eine Verbindung geschrieben wurden, für die kein Transfer registriert war. Wenn diese Bytes HTTP-Anforderungszeilen ähnelten, öffnete curl einen neuen Stream und speicherte einen Zeiger auf das Easy Handle. Wenn die Anwendung schließlich das Handle freigab, nachdem der Retry auf einer neuen HTTP/1.1-Verbindung abgeschlossen war, hielt die alte Verbindung weiterhin einen schwebenden Zeiger auf diesen freigegebenen Speicher.

Ein Angreifer konnte dann Daten auf dem alten Stream senden, die im kürzlich freigegebenen Speicherbereich landen. Durch das Leaken lokaler Adressen, um die Randomisierung der Adressraumstruktur (ASLR) zu umgehen, konnte der Angreifer einen Funktionszeiger in diesem Speicher überschreiben. Wenn curl anschließend diesen Zeiger aufrufte, würde es den Code des Angreifers ausführen. Der Fix, eine sechszeilige Umordnung in lib/multi.c durch Stefan Eissing, stellt sicher, dass die HTTP/2-Ebene ihre Referenzen auf das Handle erst freigibt, nachdem alle Restdaten geleert wurden.

Wichtige Details

• Betroffene Versionen: curl und libcurl 8.12.0 bis 8.22.0.
• Behobene Versionen: Upgrade auf 8.23.0 oder auf 8.14.3, 8.16.2 und 8.20.2 für ältere Zweige.
• Angriffsvektor: Bösartiger Server, der einen HTTP/2-Upload von etwa 135 KB empfängt.
• Schweregrad: Vom curl-Projekt als Hoch eingestuft; kein CVSS-Score veröffentlicht.
• Entdeckung: Gemeldet von Luna Tong von Anthropic über HackerOne am 15. September.
• Abhilfemaßnahme: Deaktivieren Sie HTTP/2 unter Verwendung von --http1.1 oder CURLOPT_HTTP_VERSION_1_1, wenn ein sofortiges Patching nicht möglich ist.

Warum es wichtig ist

Für Software-Ingenieure und DevOps-Teams hebt dieser Vorfall die Risiken hervor, die inhärent in weit verbreiteten Infrastruktur-Bibliotheken liegen. Curl ist in unzähligen Anwendungen eingebettet, von Kommandozeilen-Skripten bis hin zu komplexen Backend-Diensten. Da libcurl standardmäßig HTTP/2 für HTTPS-URLs aushandelt, wenn der Server dies unterstützt, können viele Anwendungen ohne explizite Konfigurationsänderungen anfällig sein. Die Tatsache, dass die Schwachstelle eine bestimmte Build-Umgebung und präzises Timing für die Ausnutzung erfordert, negiert das Risiko nicht, insbesondere bei gezielten Angriffen auf bekannte Infrastruktur.

Der Entdeckungsprozess signalisiert auch einen Wandel darin, wie Sicherheitslücken in Open-Source-Projekten gefunden werden. Der Melder nutzte Anthropics OSS Scanner, ein KI-gesteuertes Tool, das Open-Source-Projekte scannt und Ergebnisse ohne menschliche Überprüfung per E-Mail sendet. Dies wirft Fragen nach der Zukunft der Schwachstellenforschung auf, da KI-Modelle zunehmend in der Lage sind, komplexe Speicherkorruptionsfehler zu identifizieren, die traditionelles Fuzzing möglicherweise übersieht. Es führt jedoch auch zu Rauschen, da Maintainer einen Anstieg qualitativ minderwertiger, KI-generierter Berichte festgestellt haben.

Was Sie tun können

• Überprüfen Sie Ihre aktuelle curl-Version, indem Sie curl --version ausführen, und upgraden Sie sofort auf 8.23.0 oder eine gepatchte Branch-Version.
• Wenn Sie nicht sofort aktualisieren können, erzwingen Sie HTTP/1.1 in Ihren Anwendungen, indem Sie CURLOPT_HTTP_VERSION auf CURL_HTTP_VERSION_1_1 setzen.
• Prüfen Sie, ob Ihr libcurl-Build HTTP/2-Unterstützung enthält; wenn nicht, sind Sie gegen diese spezifische Schwachstelle nicht anfällig.
• Beobachten Sie Debian-Sicherheitstracker, wenn Sie Debian 13 (trixie) verwenden, das den Patch 8.14.1-2+deb13u7 via DSA-6558-1 erhalten hat.
• Überprüfen Sie alle benutzerdefinierten Docker-Container oder CI/CD-Pipelines, die ältere Versionen von curl für Dateitransfers bündeln.
• Erwägen Sie, HTTP/2 in internen Diensten zu deaktivieren, wo es nicht streng erforderlich ist, um die Angriffsfläche zu reduzieren.