curl: Unzureichende Prüfung der Cookie-Länge in Netscape-Cookie-Jar

Zusammenfassung

curl schreibt ein Cookie in eine Cookie-Datei im Netscape-Format, deren Name und Wert zusammen die Zeilenlängengrenze des Programms überschreiten. Ein entfernter HTTP-Server kann dies durch einen langen Cookie auslösen. Jeder spätere curl-Aufruf, der diese Datei mit --cookie liest, bricht die Auswertung an der zu langen Zeile ab und ignoriert alle gültigen Cookies danach. Der Hersteller stuft dies als niedrig ein: betroffen sind Integrität und Verfügbarkeit cookie-basierter Skripte und Automatisierungen, nicht Codeausführung oder Datendiebstahl.

Betroffen

• curl 8.7.0 bis 8.22.0 (libcurl und das Kommandozeilenwerkzeug curl)
• Nicht betroffen: curl-Versionen vor 8.7.0 sowie 8.23.0 und neuer
• Laut Advisory sind die Zweige 8.14.X, 8.16.X und 8.20.X ab 8.14.3, 8.16.2 bzw. 8.20.2 nicht betroffen
• Distributionen unterscheiden sich, zum Beispiel Ubuntu 26.04 LTS (behoben in 8.18.0-1ubuntu2.8) und Debian trixie (8.14.1-2+deb13u7 zum Zeitpunkt der Recherche noch verwundbar); Distributions-Advisory prüfen

Behoben in

• curl 8.23.0 (veröffentlicht am 14. Oktober 2026, Fix-Commit 445aa87)
• Zweig-Fixes laut Advisory: 8.14.3, 8.16.2, 8.20.2
• Backports der Distributionen: beim jeweiligen Hersteller prüfen

Umgehung

• Optionen des Herstellers: auf 8.23.0 aktualisieren, den Upstream-Patch in einen lokalen Build einspielen oder Cookies nicht verwenden
• Eigene Ableitung, nicht vom Hersteller: Cookie-Datei nicht zwischen Skripten oder Vertrauensbereichen teilen und keine Datei wiederverwenden, die ein Client von einem nicht vertrauenswürdigen Server erhalten hat

Ausnutzung

• Aktive Ausnutzung: Unbekannt. Keine Berichte gefunden.
• Öffentlicher Proof of Concept: bei der Recherche keiner gefunden. CISA SSVC führt die Ausnutzung als poc und die Automatisierbarkeit als nein.
• Entdecker: Joshua Rogers (Aisle Research); Meldung auf HackerOne.

Unsere Empfehlung

• Hosts und Container mit curl oder libcurl unter 8.23.0 finden, einschliesslich selbst kompilierter Builds und eingebetteter Kopien in Anwendungen.
• Sicherheitsmitteilungen der Distribution auf nachträglich eingespielte Fixes prüfen.
• Im normalen Update-Zyklus patchen, da der Hersteller das Risiko als niedrig einstuft.
• Hosts priorisieren, die Cookie-Datei-Automatisierung gegen nicht vertrauenswürdige Endpunkte betreiben, und Cookie-Dateien pro Job oder Vertrauensbereich trennen.
• Der im Datensatz genannte CVSS-Wert 8.1 weicht von anderen Quellen (5.4 und 5.9) und der Einstufung „niedrig“ des Herstellers ab; für die Priorisierung die Herstellereinstufung verwenden.

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• curl Security Advisory CVE-2026-92386 curl.se
• curl CVE metadata (JSON) curl.se
• HackerOne original report hackerone.com
• OSV entry CURL-CVE-2026-92386 osv.dev
• Ubuntu security notice CVE-2026-92386 ubuntu.com
• Debian security tracker CVE-2026-92386 security-tracker.debian.org
• Red Hat RHSA-2026:82895 via Vulners vulners.com
• VulDB entry 422996 vuldb.com

Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 01.11.2026 18:32.