cURL 8.23.0 veröffentlicht: Schwere HTTP/2-Sicherheitslücke behoben und SMB-Protokoll entfernt

cURL 8.23.0: Ein Sicherheitsupdate mit globaler Tragweite

Mit der Veröffentlichung der Version 8.23.0 hat das Open-Source-Projekt cURL ein umfangreiches Wartungs- und Sicherheitsupdate vorgelegt, das weitreichende Konsequenzen für die globale IT-Infrastruktur hat [1]. Die Aktualisierung schließt insgesamt 24 dokumentierte Sicherheitslücken, die sich in eine Schwachstelle mit hohem Schweregrad und 23 Schwachstellen mit niedrigem Schweregrad aufteilen [1]. Parallel zu diesen Fehlerbehebungen vollzieht das Projekt einen angekündigten architektonischen Schnitt und entfernt die Unterstützung für das Server Message Block Protokoll (SMB) sowie dessen verschlüsselte Variante SMBS vollständig aus dem Codebestand [1, 2].

Die Relevanz dieses Releases ergibt sich unmittelbar aus der enormen Verbreitung der Software [1]. Sowohl das Kommandozeilenwerkzeug curl als auch die zugrunde liegende Programmbibliothek libcurl gehören zu den am häufigsten eingesetzten Softwarekomponenten weltweit [1, 2]. Da die Bibliothek für den Datentransfer über URLs praktisch auf jedem vernetzten System installiert ist, betrifft die Aktualisierung Milliarden von Endgeräten und Servern [1, 3]. Das Einsatzspektrum reicht von mobilen Endgeräten wie Smartphones über vernetzte Fahrzeuge bis hin zu zentralen Unternehmensservern und Automatisierungsumgebungen [1, 3]. Selbst in schadhaften Kontexten, wie etwa bei im Mai 2026 dokumentierten Clickfix-Malware-Kampagnen unter macOS, greifen Akteure auf die allgegenwärtigen Systemwerkzeuge zurück [1].

Für Ihre IT- und Sicherheitsorganisation berührt das Update auf Version 8.23.0 somit zwei zentrale Handlungsfelder: Einerseits erfordert die Behebung einer potenziell zur Codeausführung nutzbaren HTTP/2-Schwachstelle eine zeitnahe Aktualisierung exponierter Systeme [1]. Andererseits zwingt die endgültige Entfernung des SMB-Protokolls Administratoren und Entwickler dazu, bestehende Integrationen auf veraltete Protokollaufrufe zu überprüfen, um Betriebsunterbrechungen nach dem Einspielen der neuen Version zu vermeiden [1, 3].

Detailanalyse von CVE-2026-92392: Use-After-Free ermöglicht Codeausführung über HTTP/2

Im Zentrum des aktuellen Sicherheitsupdates steht die Schwachstelle mit der Kennung CVE-2026-92392, die vom cURL-Projekt mit dem Schweregrad hoch eingestuft wird [1]. Projektgründer und Hauptentwickler Daniel Stenberg bezeichnet diesen Fehler als eine der schwersten Sicherheitslücken in cURL seit langer Zeit [1]. Technisch handelt es sich hierbei um einen sogenannten Use-After-Free-Fehler (UAF) in der Speicherverwaltung, der im Zusammenspiel mit dem Protokoll HTTP/2 auftritt [1]. Entdeckt und gemeldet wurde diese kritische Schwachstelle durch das KI-Unternehmen Anthropic [1].

Das Bedrohungsszenario von CVE-2026-92392 wiegt schwer: Ein böswillig präparierter oder kompromittierter HTTP/2-Server kann den Speicherfehler gezielt ausnutzen, um auf dem anfragenden Client-System eigenen Schadcode auszuführen (Remote Code Execution, RCE) [1]. In der Praxis bedeutet dies, dass nicht der Server durch einen Client angegriffen wird, sondern umgekehrt eine Anwendung, ein Skript oder ein Dienst, der mittels cURL eine Verbindung zu einem nicht vertrauenswürdigen HTTP/2-Endpunkt aufbaut, kompromittiert werden kann [1].

Allerdings unterliegt die praktische Ausnutzbarkeit einer wichtigen technischen Einschränkung, die das Risiko für reine Leseoperationen mindert [1]. Wie Stenberg in einer ausführlichen technischen Analyse darlegt, funktioniert ein entsprechender Angriff nicht vollautomatisch beim bloßen Abruf einer Webseite oder Ressource [1]. Stattdessen ist als zwingende Nebenbedingung ein aktiver Nutzer-Upload über die betroffene HTTP/2-Verbindung erforderlich [1]. Aus analytischer Sicht sollten Sie bei der Risikobewertung in Ihrem Unternehmen daher vorrangig solche Workloads, Backend-Dienste und CI/CD-Pipelines priorisieren, die über cURL oder libcurl automatisiert oder nutzergesteuert Daten per HTTP/2 an externe oder dynamisch konfigurierte Server hochladen [1].

Die 23 weiteren Sicherheitslücken und die Bewertungslogik von cURL

Neben der herausragenden HTTP/2-Schwachstelle adressiert cURL 8.23.0 insgesamt 23 weitere Sicherheitslücken, die vom Projekt allesamt mit einem niedrigen Schweregrad klassifiziert wurden [1]. Für jede einzelne dieser Schwachstellen hat das Entwicklerteam ein separates Sicherheits-Advisory auf seiner offiziellen Übersichtsseite veröffentlicht [1]. Trotz der niedrigen Einstufung dokumentiert die schiere Anzahl der behobenen Fehler eine intensive Überprüfung der Codebasis [1].

Bei der Einordnung dieser Schwachstellen in Ihr betriebliches Schwachstellenmanagement müssen Sie eine methodische Besonderheit des cURL-Projekts berücksichtigen: Das Projekt vergibt traditionell keine numerischen CVSS-Punktwertungen (Common Vulnerability Scoring System), sondern arbeitet ausschließlich mit eigenen qualitativen Schweregraden auf einer Skala von niedrig bis kritisch [1]. Diese projektspezifische Einschätzung bewertet die reale Ausnutzbarkeit im Kontext der Bibliothek oft deutlich konservativer als externe Schwachstellendatenbanken [1, 2, 5].

• Behobene Schwachstellen der Nummernkreise 864xx und 878xx: CVE-2026-86409, CVE-2026-86410, CVE-2026-86411, CVE-2026-86412, CVE-2026-86413, CVE-2026-86414, CVE-2026-86415 sowie CVE-2026-87861, CVE-2026-87862, CVE-2026-87863, CVE-2026-87864, CVE-2026-87865 und CVE-2026-87866 [1].
• Behobene Schwachstellen des Nummernkreises 923xx (neben der Hauptlücke CVE-2026-92392): CVE-2026-92386, CVE-2026-92387, CVE-2026-92388, CVE-2026-92389, CVE-2026-92390 und CVE-2026-92391 [1].
• Weitere behobene Schwachstellen mit niedrigem Schweregrad: CVE-2026-94265, CVE-2026-94266, CVE-2026-107928 und CVE-2026-107929 [1].

Diskrepanz zwischen Hersteller-Einstufung und CVSS-Werten

Wie stark die qualitative Einstufung durch das cURL-Team von den standardisierten Metriken kommerzieller Sicherheitsscanner und der National Vulnerability Database (NVD) abweichen kann, lässt sich exemplarisch an der bereits im April 2026 behobenen Schwachstelle CVE-2026-5773 nachvollziehen [2, 5]. Während das offizielle cURL-Advisory diesen Fehler bei der Wiederverwendung von SMB-Verbindungen ausdrücklich mit dem Schweregrad niedrig (Low) bewertete [2], wird dieselbe Lücke in den Plugin-Datenbanken von Tenable Nessus auf Basis von CVSS v3 mit einem Base Score von 7,5 (Schweregrad Hoch) und unter CVSS v2 sogar mit 7,8 (Hoch) geführt [5]. Gleichzeitig stuft Tenable selbst den Fehler in seinem internen Vulnerability Priority Rating (VPR) mit einem Wert von 3,0 wiederum als niedriges Risiko ein [5].

In der Analyse zeigt sich hier ein klassisches Dilemma für B2B-Sicherheitsteams: Wenn Ihre Compliance-Vorgaben oder Service-Level-Agreements (SLAs) starr an den CVSS-Basiswert gekoppelt sind, lösen viele der vom cURL-Projekt als niedrig eingestuften Fehler in automatisierten Scans dennoch hochpriorisierte Alarme aus [1, 2, 5]. Es empfiehlt sich daher, für eine präzise Risikobewertung stets die detaillierten Einzel-Advisories des cURL-Projekts heranzuziehen, da diese die notwendigen Vorbedingungen einer Ausnutzung exakt benennen [1, 2].

Endgültiges Aus für SMB und SMBS in cURL

Mit Version 8.23.0 setzt das cURL-Projekt eine strategische Bereinigung seiner Protokollunterstützung um: Das Server Message Block Protokoll (SMB) wird sowohl in seiner unverschlüsselten Klartext-Variante als auch in der über TLS abgesicherten Ausprägung SMBS vollständig aus der Bibliothek entfernt [1]. Nutzer und Anwendungen können über aktuelle cURL-Installationen somit keine direkten Dateitransfers mehr über URLs der Schemata smb:// oder smbs:// durchführen [1, 3].

Dieser Schritt kommt für aufmerksame Beobachter der Projektentwicklung nicht überraschend, sondern bildet den Schlusspunkt eines mehrstufigen Abschaltprozesses im Jahr 2026 [2, 4]. Bereits am 22. März 2026 hatte Daniel Stenberg in einem Blogbeitrag angekündigt, dass die Unterstützung für NTLM und SMB schrittweise abgekündigt wird [1, 4]. Als erste Maßnahme wurden beide Protokolle mit dem Release von cURL 8.20.0 Ende April 2026 auf ein reines Opt-in-Modell umgestellt [2, 4]. Ab diesem Zeitpunkt waren NTLM und SMB im Standard-Build deaktiviert und mussten beim Kompilieren der Bibliothek explizit über entsprechende Konfigurationsparameter eingeschaltet werden [2, 4].

Stenberg hatte diesen Schritt im März 2026 als erste Stufe auf einer Leiter beschrieben, an deren Ende die vollständige Entfernung der veralteten Protokolle stehen werde [4]. Auch im Sicherheits-Advisory zu CVE-2026-5773 vom 29. April 2026 wurde offiziell dokumentiert, dass cURL die Unterstützung für SMB im weiteren Jahresverlauf 2026 komplett einstellen wird [2]. Mit cURL 8.23.0 ist diese Ankündigung nun technisch vollzogen [1].

Technischer Hintergrund: Warum NTLM und SMBv1 zum Sicherheitsrisiko wurden

Die Entscheidung, ein etabliertes Netzwerkprotokoll aus einer universellen Bibliothek wie libcurl zu entfernen, gründet auf tiefgreifenden architektonischen und kryptografischen Defiziten [1, 4]. Das Kernproblem liegt dabei nicht allein im SMB-Code selbst, sondern vor allem in der untrennbar damit verbundenen Authentifizierungsmethode NTLM [1, 4]. Da cURL für die Authentifizierung bei SMB-Verbindungen zwingend auf NTLM angewiesen ist, führte bereits die Deaktivierung von NTLM automatisch zum Wegfall der SMB-Funktionalität [4].

Daniel Stenberg hatte die NTLM-Implementierung in cURL (und parallel dazu auch für das Werkzeug wget) bereits im Jahr 2003 programmiert [4]. Da es sich bei NTLM um ein proprietäres Protokoll von Microsoft handelt, basierte dieser Code auf einer Dokumentation, die zuvor durch Reverse Engineering gewonnen worden war [4]. Aus Sicht der Softwarearchitektur bricht NTLM jedoch fundamental mit dem Paradigma von HTTP: Während reguläre HTTP-Authentifizierungsverfahren stets einzelne Anfragen (Requests) authentifizieren, authentifiziert NTLM die gesamte zugrunde liegende Verbindung (Connection) [4].

Dieses zustandsbehaftete, verbindungsbasierte Konzept hat gravierende Auswirkungen auf moderne Netzwerkbibliotheken [4]. Um NTLM in HTTP-Code zu unterstützen, sind zahlreiche Sonderbehandlungen und Ausnahmeregeln im Verbindungsmanagement erforderlich, was indirekt immer wieder zu Sicherheitslücken führt [4]. Allein in cURL wurden in der Vergangenheit mindestens sieben Sicherheitslücken direkt im NTLM-bezogenen Code verzeichnet [4]. Zudem macht das verbindungsbasierte Design NTLM strukturell inkompatibel mit modernen Protokollen wie HTTP/2 und HTTP/3, sodass Dienste bei NTLM-Nutzung zwingend auf HTTP/1 beschränkt bleiben [4]. Hinzu kommt, dass NTLMv1 mit DES und MD5 extrem schwache kryptografische Algorithmen verwendet [4]. Selbst Microsoft hat NTLM inzwischen offiziell als veraltet (deprecated) eingestuft, und auch das wget-Projekt bewegte sich im Frühjahr 2026 in Richtung einer Opt-in-Beschränkung [4].

Für das darauf aufbauende SMB-Protokoll kam erschwerend hinzu, dass cURL seit der Einführung der Funktion in Version 7.40.0 ausschließlich die veraltete Protokollversion SMBv1 unterstützte und niemals um neuere Versionen wie SMBv2 oder SMBv3 erweitert wurde [1, 2, 4]. Da SMBv1 als unsicher und überholt gilt, ist es auf modernen Servern ohnehin standardmäßig deaktiviert und wurde von cURL-Anwendern in der Praxis kaum noch genutzt [2, 4]. Die Beibehaltung des Codes stand somit in keinem Verhältnis mehr zum Wartungsaufwand und zum resultierenden Sicherheitsrisiko [1, 4].

Rückblick auf jüngste SMB-Schwachstellen in libcurl

Wie fehleranfällig die SMB-Implementierung in cURL bis zuletzt war, belegen konkrete Schwachstellen, die allein im ersten Halbjahr 2026 vor der endgültigen Entfernung des Protokolls dokumentiert und behoben werden mussten [2, 3, 5]. Diese Fälle verdeutlichen anschaulich, warum das Projekt die Angriffsfläche nun komplett eliminiert hat [1, 2].

CVE-2026-5773: Fehlerhafte Wiederverwendung von SMB-Verbindungen

Am 5. April 2026 meldete der Sicherheitsforscher Osama Hamad einen logischen Fehler im Verbindungs-Pool von libcurl, der unter der Kennung CVE-2026-5773 (CWE-488: Exposure of Data Element to Wrong Session) erfasst wurde [2]. Um Netzwerk-Overhead zu vermeiden, hält libcurl kürzlich genutzte Verbindungen in einem Pool vor und verwendet diese bei nachfolgenden Anfragen wieder, sofern bestimmte Parameter übereinstimmen [2]. Beim Abgleich für SMB- und SMBS-Transfers prüfte der Code jedoch fälschlicherweise nicht den Namen der Netzwerkfreigabe (Share) als Kriterium [2, 5].

Führte eine Anwendung über denselben Server und mit denselben Zugangsdaten nacheinander Transfers auf unterschiedlichen SMB-Freigaben durch, konnte libcurl irrtümlich die bestehende Verbindung der vorherigen Freigabe wiederverwenden [2, 5]. Dies konnte dazu führen, dass falsche Dateien heruntergeladen oder Uploads in ein falsches Verzeichnis geschrieben wurden [2, 5]. Der Fehler existierte seit der Einführung von SMB in cURL 7.40.0 und betraf alle Versionen bis einschließlich 8.19.0 [2]. Daniel Stenberg behob das Problem in dem am 29. April 2026 veröffentlichten cURL 8.20.0 (sowie in den Langzeit-Branches 8.16.1 und 8.14.2) radikal, indem die Wiederverwendung von Verbindungen für SMB komplett unterbunden wurde [2].

CVE-2026-3805: Speicherfehler bei wiederholten SMB-Anfragen

Eine weitere Schwachstelle im SMB-Protokoll-Handler wurde bereits im März 2026 unter der Kennung CVE-2026-3805 (CWE-416: Use After Free) in der NVD veröffentlicht [3]. Gemäß einer Datenbankanalyse von SentinelOne – bei der ausdrücklich zu beachten ist, dass der dortige Beschreibungstext laut Anbieterhinweis KI-generiert erstellt wurde und auf das offizielle cURL-Advisory sowie den HackerOne-Bericht #3591944 verweist – trat dieser Fehler bei wiederholten SMB-Anfragen an denselben Host innerhalb einer Sitzung auf [3].

Dabei gab libcurl nach einem ersten SMB-Transfer den verbindungsbezogenen Statusspeicher frei, setzte jedoch einen internen Datenzeiger (Pointer) für dasselbe Verbindungs-Handle nicht korrekt zurück [3]. Bei einer zweiten Anfrage an denselben SMB-Server griff der Code über diesen veralteten Zeiger (Dangling Pointer) auf bereits freigegebenen Heap-Speicher zu [3]. Dies führte zu Speicherkorruption und in den meisten beobachteten Fällen zu einem Programmabsturz (Denial of Service) durch Speicherzugriffsverletzungen (SIGSEGV) [3]. Mit der vollständigen Entfernung des SMB-Codes in Version 8.23.0 sind derartige Fehlerklassen im SMB-Stack von cURL nun dauerhaft ausgeschlossen [1, 3].

Die Debatte um Speichersicherheit, Rust und den Einsatz von KI

Das Release von cURL 8.23.0 berührt über die reinen Patch-Informationen hinaus zwei grundlegende strategische Debatten der modernen Softwareentwicklung: die Frage nach der Ablösung der Programmiersprache C durch speichersichere Alternativen sowie die Rolle künstlicher Intelligenz bei der Fehlersuche [1, 2].

Da es sich bei der gravierenden HTTP/2-Lücke CVE-2026-92392 erneut um einen klassischen Use-After-Free-Speicherfehler handelt, sah sich Daniel Stenberg veranlasst, in seinem Blogbeitrag zur Schwachstelle eine unmissverständliche Positionierung vorzunehmen [1]. Er stellte erneut klar, dass das Projekt cURL nicht neu schreiben werde – etwa in einer speichersicheren Programmiersprache wie Rust [1]. Dass nicht jede Sicherheitslücke in cURL auf die Eigenschaften der Sprache C zurückzuführen ist, hatte das Projekt zudem bereits im Frühjahr bei der logischen SMB-Schwachstelle CVE-2026-5773 betont: Im damaligen Advisory hieß es explizit, der Fehler sei kein C-spezifischer Fehler und wäre sehr wahrscheinlich auch bei Nutzung einer anderen Programmiersprache nicht vermieden worden [2]. Gleichwohl zeigt CVE-2026-92392, dass klassische Speicherverwaltungsfehler in C-Codebasen weiterhin zu kritischen RCE-Schwachstellen führen können [1].

Bemerkenswert ist zudem die ambivalente Rolle von KI-Systemen im Umfeld des cURL-Projekts [1]. Einerseits wurde die schwerwiegende Schwachstelle CVE-2026-92392 von Anthropic gefunden, was das Potenzial fortgeschrittener Analysen unterstreicht [1]. Andererseits äußerte sich Stenberg in der Vergangenheit wiederholt kritisch über Sinn und Unsinn von KI im Sicherheitsbereich, unter anderem im Kontext von Berichten, wonach das System Mythos lediglich eine einzige Sicherheitslücke in cURL gefunden habe [1]. Wie stark das Projekt zeitweise durch das Aufkommen von Fehlermeldungen belastet war, zeigte sich im Juli 2026: Damals pausierte das cURL-Projekt für einen gesamten Monat die Annahme jeglicher Bug-Reports und rief diesen Zeitraum als sogenannten Sommer der Glückseligkeit aus [1].

Auswirkungen und Handlungsempfehlungen für Unternehmen

Für IT-Verantwortliche, DevOps-Teams und Sicherheitsarchitekten ergeben sich aus der Veröffentlichung von cURL 8.23.0 konkrete operative Aufgaben [1, 3]. Zwar ist zu erwarten, dass die aktualisierte Version in Kürze über die regulären Update-Mechanismen der Betriebssystemhersteller und Linux-Distributionen in nahezu jeder Soft- und Hardware ausgerollt wird, die cURL integriert [1, 3]. Wo eine rasche Risikominderung erforderlich ist, sollten Sie diese Aktualisierungsprozesse jedoch gezielt überwachen und bei Bedarf manuell anstoßen [1, 3].

Während ein händischer Austausch der cURL-Bibliothek und des Kommandozeilenprogramms auf Standard-Endgeräten nur in seltenen Ausnahmefällen notwendig ist [1], erfordert die Architektur moderner Unternehmensumgebungen in bestimmten Bereichen ein aktives Eingreifen [3]:

• Container-Images und statisch gelinkte Anwendungen: Prüfen Sie eigene Docker-Container, CI/CD-Runner und Softwarepakete, die eingebettete Versionen von curl oder libcurl mitführen, und erstellen Sie diese Images mit der gepatchten Version 8.23.0 neu [1, 3].
• Risikoprüfung für HTTP/2-Uploads (CVE-2026-92392): Identifizieren Sie Systeme und Skripte, die mittels cURL Datei- oder Daten-Uploads über HTTP/2 an externe Server durchführen, da hier die spezifische Vorbedingung für eine Ausnutzung der RCE-Schwachstelle erfüllt ist [1].
• Migration verbleibender SMB-Integrationen: Durchsuchen Sie Automatisierungsskripte, Batch-Jobs und Quellcodes nach Aufrufen von smb:// oder smbs:// sowie nach entsprechenden libcurl-Protokolloptionen [1, 3]. Da diese Funktion in Version 8.23.0 nicht mehr existiert, müssen entsprechende Workflows auf dedizierte SMB-Clients (mit Unterstützung für SMBv2/v3) oder alternative Transferprotokolle umgestellt werden [1, 2].
• Absicherung von Altsystemen ohne sofortiges Update: Falls auf einzelnen Bestands- oder Embedded-Systemen ein sofortiger Wechsel auf Version 8.23.0 oder mindestens 8.20.0 noch nicht möglich ist, sollte die SMB-Nutzung zur Laufzeit über den Parameter --proto -smb,-smbs beziehungsweise CURLOPT_PROTOCOLS_STR unterbunden und ausgehender SMB-Datenverkehr (TCP-Ports 445 und 139) an der Netzwerkperipherie blockiert werden [2, 3].

Quellen

[1] Neue curl-Version entfernt SMB-Unterstützung und behebt 24 Sicherheitslücken | heise online — https://www.heise.de/news/Neue-curl-Version-entfernt-SMB-Unterstuetzung-und-behebt-24-Sicherheitsluecken-11487340.html (abgerufen am 2026-10-14)

[2] curl - wrong reuse of SMB connection - CVE-2026-5773 — https://curl.se/docs/CVE-2026-5773.html (abgerufen am 2026-10-14)

[3] CVE-2026-3805: Haxx Curl Use-After-Free Vulnerability — https://www.sentinelone.com/vulnerability-database/cve-2026-3805 (abgerufen am 2026-10-14)

[4] NTLM and SMB go opt-in | daniel.haxx.se — https://daniel.haxx.se/blog/2026/03/22/ntlm-and-smb-go-opt-in (abgerufen am 2026-10-14)

[5] Curl 7.40.0 < 8.20.0 Wrong SMB Connection Reuse | Tenable® — https://www.tenable.com/plugins/nessus/311423 (abgerufen am 2026-10-14)