senn-techcurl 8.23.0: eine Lücke mit HIGH, 24 Advisorys und die Revision, die bei uns noch fehlt
Am 14. Oktober 2026 hat das curl-Projekt die Version 8.23.0 veröffentlicht, vier Wochen früher als der eigene Plan vorsah. Auslöser war ein Bericht über eine Lücke, die dem Projekt schwerwiegend genug war. Am selben Tag wurden 24 Advisorys veröffentlicht, 21 davon behebt 8.23.0, drei waren mit der Vorgängerversion 8.22.0 bereits gefixt und wurden nur jetzt öffentlich. Das Projekt stuft eine einzige der 24 mit HIGH ein, die übrigen 23 mit LOW. Wir haben am 15. Oktober unseren eigenen Bestand gelesen, 19 Hosts mit curl und 23 Container mit curl, dazu die Paketstände von Debian, Ubuntu und Alpine. Das Ergebnis der Messung: Auf drei Hosts und in zwölf Containern fehlt genau eine Paketrevision, auf acht Alpine-Hosten gibt es noch gar kein Update.
Was CVE-2026-92392 kann und was sie braucht
Die Lücke sitzt im HTTP/2-Upload. Ein Server bremst den Sendefluss, indem er das HTTP/2-Fenster auf null setzt, schickt einen Teil der Antwort und setzt den Stream mit RST_STREAM zurück, ohne die Verbindung zu kündigen. curl baut den Transfer daraufhin sauber ab, lässt dabei aber einen Zeiger auf das bereits freigegebene Easy-Handle stehen. Beim Aufräumen des Multi-Handles erkennt die Bibliothek die Lage nicht, lädt Daten des Servers in die soeben freigegebene Struktur und benutzt am Ende einen Funktionszeiger, den genau diese Daten überschrieben haben. Damit läuft Code des Servers auf der Maschine, die hochgeladen hat.
Damit daraus tatsächlich Codeausführung wird, müssen nach Stenbergs Beschreibung mehrere Bedingungen gleichzeitig passen. Der Upload muss auf einen Server mit gültigem Zertifikat gehen. Die Upload-Größe muss ungefähr 135 KB treffen. Das Speichermuster unterscheidet sich zwischen Distributionen, libc-Versionen, CA-Bundles und Anwendungen, der Angreifer muss es für sein Ziel treffen. Der Platz für die Nutzlast ist klein, rund 23 Bytes. Daniel Stenberg schreibt, das curl-Team halte das Zusammentreffen dieser Bedingungen in freier Wildbahn für extrem schwierig, und darum steht die Lücke auf HIGH und nicht auf CRITICAL.
Das Advisory nennt als Reporterin Luna with Claude von Anthropic, gemeldet am 15. September 2026, gefixt von Stefan Eissing nach 29 Tagen. Die drei Empfehlungen des Advisories sind kurz: auf 8.23.0 hochziehen, den Patch selbst anwenden, oder HTTP/2 meiden.
Zwei Zahlen aus der Advisory-Tabelle des Projekts ordnen das ein. Seit 2021 tragen dort genau drei Einträge die Stufe HIGH, neben diesem CVE-2021-22901 und CVE-2023-38545. Und 14 der 24 Titel vom 14. Oktober nennen schon im Wortlaut Verbindungs-Wiederverwendung, Herkunftsadresse, Zugangsdaten, Cookies oder HSTS-Zustände. Die alte curl-Geschichte von Zuständen, die ein wiederverwendeter Verbindungskanal aus dem früheren Transfer mitnimmt, bleibt damit die Hauptquelle der Meldungen.
Wer die Lücken gefunden hat
Den HIGH-Fall hat „Luna with Claude" von Anthropic gemeldet, laut Advisory am 15. September 2026. Für die Menge der Advisorys liefert das Projekt selbst eine zweite Erklärung. Daniel Stenberg schreibt am 14. Oktober, die Firma Aisle habe im vergangenen Jahr KI-gestützte Werkzeuge zusammen mit eigenen Ingenieuren auf den curl-Code angesetzt, das Ergebnis seien „nicht weniger als fünfunddreißig veröffentlichte curl-Schwachstellen mit CVE-Nummer". Es sei das fünfte externe Audit, der Bericht liegt auf der curl-Seite. Stenberg nennt die Zusammenarbeit durchweg positiv und sagt, Aisle habe mehr curl-CVEs gefunden als jede andere Gruppe oder Einzelperson.
Aisle beziffert den eigenen Anteil in seinem Blog vom selben Tag. Danach stammen 18 der 24 Funde in 8.23.0 von Aisle, sechs weitere aus 8.22.0. Aisle ordnet die 18 so ein: acht betreffen Zugangsdaten oder Identität, vier persistente Cookie- und HSTS-Zustände, vier Protokoll- und Kommandozeilen-Randfälle, zwei Speichersicherheit oder Verfügbarkeit. Das sind Herstellerangaben. Die Aisle-Seite enthält keine Schweregrade und erwähnt die HTTP/2-Lücke nicht, die HIGH-Meldung bleibt also bei der Reporterin aus dem Advisory.
Die Quellen müssen hier gegeneinander gerechnet werden. Der Wert „22" kursiert in einigen Berichten und stammt aus Stenbergs Beitrag vom 7. Oktober, der 22 ausstehende Meldungen ankündigte. Die Advisory-Tabelle des Projekts führt für den 14. Oktober 24 Einträge. Amazon Linux führt die HIGH-Lücke in seiner Datenbank mit CVSS 8.1. Das curl-Projekt vergibt selbst keine CVSS-Zahl, sondern die Stufen Low, Medium, High und Critical.
Eine Diskussion in Foren haben wir gesucht und kaum gefunden. Auf Hacker News stehen mehrere Einreichungen von Stenbergs Beiträgen, die größte mit 8 Punkten und ohne Kommentar (Beitrag). Die technische Debatte läuft auf der Sicherheitsliste oss-sec.
Was die Distributoren am Tag der Veröffentlichung geliefert haben
Debian hat am 14. Oktober DSA-6558-1 für trixie herausgegeben und fixt curl dort mit 8.14.1-2+deb13u7. Die vier CVEs der Meldung sind CVE-2026-8286, CVE-2026-8924, CVE-2026-8927 und der neue HIGH-Fall. Ubuntu hat am selben Tag zwei Notices geschickt. Für 26.04 LTS bringt USN-8927-1 die Version 8.18.0-1ubuntu2.8. Für 24.04, 22.04, 20.04, 18.04 und 16.04 bringt USN-8932-1 für noble 8.5.0-2ubuntu10.16, und auf der CVE-Seite zu CVE-2026-92392 stehen 24.04 und 22.04 ausdrücklich auf Not affected, weil deren curl mit Stand 8.5.0 die betroffene Code-Stufe 8.12.0 noch nicht mitbringt.
Bei Alpine haben wir am 15. Oktober auf zwei Alpine-3.23-Hosten nachgesehen. Dort meldet apk policy curl im Repo v3.23/main nur 8.22.0-r0, also die letzte betroffene Fassung, und in der secdb für 3.23 ist keiner der neuen CVEs verzeichnet. Stand der Messung existiert für Alpine 3.23 noch kein Update auf diese Advisorys, wer Alpine fährt hängt an diesem Zweig.
Der CERT-Bund hat am 14. Oktober um 14:09 Uhr MESZ die Meldung WID-SEC-2026-3904 mit der Einstufung hoch nachgezogen, mit Hinweis auf Codeausführung, Umgehen von Sicherheitsmaßnahmen, Offenlegen von Informationen, Manipulieren von Daten und Denial of Service. Einen Eintrag in der CISA KEV und einen Ausnutzungsbericht haben wir nicht gefunden.
Der Blick in unsere eigene Flotte
Nach Paketrevision aufgeteilt, gemessen am 15. Oktober: Vier Hosts haben das Distributor-Update schon drauf, drei Ubuntu-Systeme mit 8.18.0-1ubuntu2.8 und ein Debian-13-Host mit 8.14.1-2+deb13u7. Drei Hosts sind eine messbare Revision dahinter, zwei Ubuntu-26.04-Systeme mit 8.18.0-1ubuntu2.7 und unser pbs3 mit 8.14.1-2+deb13u5. Auf zwei Ubuntu-24.04-Systemen läuft 8.5.0-2ubuntu10.15, ein Stand vor dem Paket 8.5.0-2ubuntu10.16 aus USN-8932-1, wobei die High-Lücke dort nach Ubuntu-Status gar nicht greift. Acht Alpine-3.23-Hosts stehen auf 8.22.0-r0 und haben, wie oben gemessen, noch kein Update im Repo. Ein weiterer Host von 26.04 zeigt curl 8.18.0 im Programm, aber keinen dpkg-Eintrag, dazu können wir keine Paket-Aussage treffen.
Bei den Containern bringt die zweite Zeile von curl --version die Wahrheit, denn dort steht bei Debian-Bildern der Patchstand. Bei 18 der 23 gezählten Container ist sie lesbar und meldet zwölf mal 8.14.1-2+deb13u5, vier mal 7.88.1-10+deb12u15 und nur zwei mal das bereits gefixte 8.14.1-2+deb13u7. Die übrigen fünf Container sind Alpine-Bauten ohne jeden Patchstand-Vermerk, vier davon auf curl 8.22.0. Die hängen doppelt: kein Distributor-Patchstand zum Nachlesen und, wie oben gemessen, auch noch kein Update im Alpine-Zweig. Ein Update des Hosts ändert an allen diesen Dateien nichts, sie brauchen einen neuen Build aus dem aktualisierten Basisbild.
Das Ende von SMB kam in zwei Stufen
In den Changes von 8.23.0 steht SMB: drop support, dazu ein Vermerk in DEPRECATE.md. Wer das überraschend findet, hat den März überlesen. Daniel Stenberg hat am 22. März 2026 erklärt, dass curl ausschließlich SMB in Version 1 beherrschte, dieses Protokoll zur Anmeldung NTLM benutzt und beides ab 8.20.0 nur noch auf ausdrücklichen Wunsch im Build steckt. Im selben Text stehen sieben aufgezeichnete Sicherheitslücken in NTLM-abhängigem Code und der Hinweis, dass Microsoft NTLM selbst bereits deprecated hat. Die Entfernung im Oktober ist die zweite Stufe desselben Wegs, angekündigt sieben Monate zuvor.
Nachprüfen lässt das im Feature-Block von curl -V. Von fünf geprüften Host-Builds bieten vier smb und NTLM weiterhin an, der Alpine-Build unserer Blog-Box nicht und auch das Edge-Image der Transportleitung nicht. In den geprüften Skriptverzeichnissen, den Cron-Jobs und Hermes-Skripten auf .180.2 sowie dem Transportleitungszweig auf .200.11, fand grep keinen einzigen Aufruf mit smb://. Bei uns ändert der Wegfall nichts. Wer solche Aufrufe noch in Skripten liegen hat, spricht seit Jahren SMBv1.
Was wir jetzt tun und in welcher Reihenfolge
Offen sind drei Host-Updates im nächsten Wartungsfenster: zwei Ubuntu-Systeme auf 8.18.0-1ubuntu2.8 und pbs3 auf 8.14.1-2+deb13u7. Für die Alpine-Hosts gibt es Stand 15. Oktober nichts einzuspielen, der v3.23-Zweig muss beobachtet werden, bis dort ein Paket liegt. Die Container-Bilder auf deb13u5 brauchen einen neuen Build, sobald das Basisbild aktualisiert ist, sinnvoll in der Reihenfolge der Expositionsfläche: zuerst Edge und Proxy, dann die MCP-Dienste im internen Netz. In diesem Lauf ist gemessen und notiert, nichts installiert.
Zwei Prüfschritte nehme ich aus dem Lauf für jeden Bestand mit. Erstens: feststellen, ob die Container überhaupt ein curl mitbringen, und bei Debian-Bildern die zweite Zeile lesen, denn dort steht die Revision. Zweitens: die Alpine-Zweige mitzählen, denn ein Distributor, der am Tag nach der Veröffentlichung noch kein Paket hat, verschiebt das Problem um einige Tage.
So haben wir gemessen
Gemessen wurde am 15. Oktober 2026 per ssh auf den Hosts, die von der Arbeitsstation erreichbar waren, 19 von 29 angefragten. Je Host haben wir curl -V für Version und Protokolle gelesen und dpkg -l curl beziehungsweise apk policy curl für die Paketrevision. In Containern lief curl --version über docker exec, die zweite Zeile enthält bei Debian-Bildern den Patchstand. 23 Container hatten ein curl, bei 18 war die Zeile lesbar. Die Verteilungen stehen in den beiden Diagrammen, die Rohdaten liegen bei uns. Keine Messung konnte den Betrieb verändern, es wurde nichts installiert.
Weiterführende Quellen
Primärquellen
- curl-Projekt, Advisory zu CVE-2026-92392, 14.10.2026: curl.se/docs/CVE-2026-92392.html
- curl-Projekt, Advisory-Tabelle mit Stufen, Stand 15.10.2026: curl.se/docs/security.html
- curl-Projekt, Änderungen in 8.23.0: curl.se/ch
- Daniel Stenberg, A UAF turned RCE, 14.10.2026, mit den Bedingungen der Ausnutzung: daniel.haxx.se
- Daniel Stenberg, A curl audit by Aisle, 14.10.2026: daniel.haxx.se
- Daniel Stenberg, Twenty-two pending curl vulnerabilities, 7.10.2026: daniel.haxx.se
- Daniel Stenberg, NTLM and SMB go opt-in, 22.3.2026: daniel.haxx.se
- Ankündigung auf der Liste oss-sec zu curl 8.23.0: seclists.org
Distributoren
- Debian, DSA-6558-1: security-tracker.debian.org, CVE-Seite: CVE-2026-92392
- Ubuntu, USN-8927-1, USN-8932-1 und CVE-2026-92392
- Amazon Linux, CVE-Seite mit CVSS 8.1: explore.alas.aws.amazon.com
Unabhängige Berichte
- CERT-Bund, WID-SEC-2026-3904, 14.10.2026: wid.cert-bund.de
- heise online, 14.10.2026: Neue curl-Version entfernt SMB-Unterstützung und behebt 24 Sicherheitslücken
Herstellerangabe
- Aisle, One Aisle curl Audit Produced 24 CVEs, 18 Ship Today, 14.10.2026: aisle.com
Community
- Hacker News zu Stenbergs Beitrag, 8 Punkte, kein Kommentar am 16.10.2026: news.ycombinator.com
Muss ich wegen curl 8.23.0 diese Nacht die Firma stilllegen?+
Nein. Für CVE-2026-92392 braucht ein Angreifer einen Upload von uns auf seinen Server, eine Dateigröße von etwa 135 KB, ein gültiges Serverzertifikat und eine Speicherlayout-Kette, die zu unserer Distribution passt. Das curl-Team hält die Ausnutzung unter echten Bedingungen für extrem schwierig und hat deshalb HIGH und nicht CRITICAL vergeben. Das Einspielen ist trotzdem richtig, nur im normalen Fenster.
Reicht es, die Hosts zu patchen?+
Nein, und das ist der eigentliche Befund unseres Checks. In unseren Containern läuft ein eigenes curl, 19 von 23 gezählten meldeten eine Version aus der betroffenen Spanne. Ein apt upgrade oder apk update auf dem Host ändert an den Dateien im Image nichts, die Bilder brauchen einen neuen Build.
Betrifft das ausgefallene SMB noch irgendwen?+
Kaum jemanden. curl hat nie SMB2 gekonnt, der Code war ab 8.20.0 opt-in und damit in den meisten Distributionsbuilds seit März 2026 gar nicht mehr aktiv. Ein grep über unsere Skriptverzeichnisse fand keinen einzigen smb://-Aufruf, und der Alpine-Build stellte SMB ohnehin nicht bereit.