Kaum ein Werkzeug steckt so tief und so unauffällig in der eigenen Infrastruktur wie curl. Umso mehr Aufmerksamkeit verdient CVE-2026-92392, veröffentlicht am 14. Oktober zusammen mit curl 8.23.0 — der Fundort ist dabei fast spannender als die Lücke selbst: Entdeckt hat sie eine KI-gestützte Sicherheitsforscherin namens Luna, in Zusammenarbeit mit Claude von Anthropic.
DER FEHLER: Wenn der Server die Verbindung abwürgt
Die technische Beschreibung im Projekt-Advisory liest sich unscheinbar: curl behandelt ein HTTP/2-RST_STREAM-Signal vom Server — mit dem Grund HTTP_1_1_REQUIRED oder REFUSED_STREAM — in bestimmten Fällen falsch. Die Folge ist ein Use-after-free auf ein internes Curl_easy-Objekt (CWE-416): Der Speicherbereich wird freigegeben, curl greift danach aber trotzdem noch darauf zu.
Solche Fehler sind tückisch, weil sie meist „nur“ zu einem Absturz führen — unter den richtigen Umständen lässt sich daraus aber potenziell Code-Ausführung konstruieren. Das Problem tritt konkret beim HTTP/2-Upload auf, also wenn curl selbst Daten an einen Server hochlädt und dieser die Verbindung mitten im Upload abbricht.
EIN KI-MODELL ALS SICHERHEITSFORSCHERIN
Die Meldung kam laut curl-Projekt von „Luna mit Claude (Anthropic)“ — gemeldet bereits am 15. September, behoben hat den Fehler letztlich Entwickler Stefan Eissing. Es ist nicht die erste KI-gestützte Fund-Meldung in der Open-Source-Welt, aber ein weiteres Beispiel dafür, dass automatisierte Codeanalyse mit Sprachmodellen inzwischen echte Speicherfehler in jahrzehntealtem C-Code aufspürt, die klassisches Fuzzing offenbar übersehen hatte.
WER BETROFFEN IST — PRAKTISCH JEDER
Anfällig sind curl und libcurl von Version 8.12.0 bis 8.22.0. Nicht betroffen sind Versionen vor 8.12.0 sowie bereits gepatchte Zwischenversionen (8.20.2+, 8.16.2+, 8.14.3+). Weil libcurl in unzähligen Programmiersprachen, Container-Images und CLI-Werkzeugen mitgeliefert wird, lässt sich die tatsächliche Reichweite kaum seriös schätzen — von PHP über Python bis zu unzähligen Docker-Basisimages hängt praktisch alles irgendwo an curl.
SO AKTUALISIERST DU — in 5 MINUTEN
- Version prüfen:
curl --versionauf jedem Server und in jedem Container-Image. - Paketverwaltung nutzen: Die meisten Distributionen rollen den Fix über ihre regulären Sicherheitsupdates aus — ein manueller Build ist für die meisten Nutzer unnötig.
- Container-Images neu bauen, sobald die Basis-Images aktualisiert sind — ein altes Image bleibt sonst dauerhaft anfällig, egal wie aktuell der Host ist.
- Bei Eigenbau von curl/libcurl aus dem Quellcode: direkt auf 8.23.0 wechseln.
FAZIT: Unspektakulär, aber überall
Es gibt derzeit keine Hinweise auf aktive Ausnutzung, und die Einstufung HOCH statt KRITISCH zeigt, dass eine echte Codeausführung eher die Ausnahme als der Normalfall wäre. Trotzdem lohnt sich der Blick aufs eigene System — nicht wegen akuter Gefahr, sondern weil curl so allgegenwärtig ist, dass eine übersehene alte Version irgendwann garantiert wieder auftaucht. Und der Fundweg zeigt: KI-gestützte Codeanalyse wird für Open-Source-Projekte zunehmend zur ernstzunehmenden zusätzlichen Prüfinstanz.