curl: Lesen ausserhalb des Speicherbereichs beim WebSocket-Upload mit GnuTLS-Backend

Zusammenfassung

Ein böswilliger WebSocket-Server kann curl dazu bringen, Speicher jenseits seines Sendepuffers zu lesen, wenn curl mit dem TLS-Backend GnuTLS gebaut wurde. Auslöser ist ein blockierter TLS-Sendevorgang, gefolgt von einer automatischen WebSocket-PONG-Antwort; im ungünstigsten Fall werden Daten aus einem benachbarten Heap-Puffer an den Server gesendet. Wahrscheinlicher ist ein Absturz, und der offizielle Schweregrad ist Low.

Betroffen

• curl 7.86.0 bis einschliesslich 8.22.0, wenn mit GnuTLS gebaut
• Nur das GnuTLS-Backend ist betroffen; Builds mit anderen TLS-Backends sind nicht betroffen
• Das Kommandozeilenwerkzeug und libcurl sind beide betroffen
• Nicht betroffen: 8.23.0 und neuer, 8.20.2 und neuer im Zweig 8.20.X, 8.16.2 und neuer im Zweig 8.16.X, 8.14.3 und neuer im Zweig 8.14.X
• Distributionspakete können abweichen; der CVSS-Wert 8.1 in den Eingangsdaten konnte nicht verifiziert werden

Behoben in

• curl 8.23.0 (veröffentlicht am 14. Oktober 2026)
• Upstream-Commit 64fb3e7a7b116f690966054f281624152d4a7651
• Ubuntu 26.10: curl 8.20.0-2ubuntu11.1 (USN-8927-2)
• openSUSE Tumbleweed: curl 8.23.0-1.1
• Debian: sid mit 8.23.0-1 behoben; bookworm und trixie werden noch als verwundbar geführt (trixie als no-dsa markiert)
• Red Hat, Alpine und Windows-/Herstellerbuilds: Unbekannt; bitte die Herstellerwarnung prüfen

Umgehung

• Bei selbst gebautem curl ein anderes TLS-Backend als GnuTLS für WebSocket-Verbindungen verwenden
• WebSocket-Nutzung auf vertrauenswürdige Endpunkte beschränken
• Den Upstream-Patch auf den lokalen Build anwenden, falls noch kein Update verfügbar ist

Ausnutzung

• CISA SSVC: Exploitation-Status poc, nicht automatisierbar, totale technische Auswirkung
• SUSE meldet, dass keine Ausnutzung bekannt ist
• Kein Eintrag im CISA-KEV-Katalog gefunden; EPSS etwa 0,0026 (sehr niedrig)
• Kein bestätigter öffentlicher Proof of Concept bekannt

Unsere Empfehlung

• Prüfen, ob curl oder libcurl in einem GnuTLS-Build installiert ist (zum Beispiel libcurl3t64-gnutls unter Ubuntu)
• Auf curl 8.23.0 oder das gefixte Paket der Distribution aktualisieren; bei fehlendem Fix den Tracker der Distribution für trixie oder bookworm prüfen
• Wo kein Update möglich ist, das TLS-Backend wechseln oder WebSocket-Verbindungen auf vertrauenswürdige Server beschränken
• Hosts und Build-Pipelines priorisieren, die curl-WebSocket gegen externe Endpunkte verwenden
• NVD nach Abschluss der Analyse erneut prüfen und die Priorität erhöhen, falls sich der Herstellerschweregrad ändert

Ö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-107928 curl.se
• curl CVE JSON metadata curl.se
• Original HackerOne report hackerone.com
• Debian security tracker security-tracker.debian.org
• Ubuntu USN-8927-2 ubuntu.com
• OSV CURL-CVE-2026-107928 osv.dev
• Vulners NVD CVE-2026-107928 vulners.com
• curl security policy curl.se

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:36.