curl öffnet Meldungen zu weniger schweren Sicherheitslücken

Der Zielkonflikt: Transparenz und zusätzliche Angriffszeit

Öffentliche Diskussionen zu Fehlern können auch Informationen zugänglich machen, die Angreifer für ihre eigene Analyse nutzen. Stenberg räumt ausdrücklich ein, dass das neue Verfahren böswilligen Akteuren bei den betroffenen Fällen etwas mehr Zeit zur Vorbereitung geben könnte. Das Projekt begrenzt die Umstellung deshalb auf Meldungen unterhalb der Kategorien „hoch“ und „kritisch“. [1]

Bedenken, Sicherheitsforscher könnten das Risiko einer schwerwiegenden Lücke fälschlich zu niedrig einstufen und sie dadurch öffentlich machen, hält Stenberg laut Bericht für unbegründet. Er verweist darauf, dass ihm nahezu keine Fälle bekannt seien, in denen Forscher das Risiko unterschätzt hätten. Das ist die Einschätzung des Maintainers und keine unabhängige Untersuchung der möglichen Fehlklassifizierungen. [1]

Stenberg erklärt außerdem, das Risiko einer Unterschätzung habe auch im bisherigen Verfahren bestanden. Zugleich erwog das Projekt dem Bericht zufolge, niedrig eingestufte Meldungen ganz abzulehnen. Dagegen spreche unter anderem, dass eine CVE-Einstufung angefochten werden könne und eine andere Stelle eine CVE vergeben könnte, falls curl für eine tatsächliche Schwachstelle keine ausstelle. [1]

Die Abwägung ist damit nicht risikofrei: Vertrauliche Bearbeitung kann Informationen bis zur Korrektur zurückhalten, bindet aber begrenzte Maintainer-Kapazitäten. Öffentliche Bearbeitung kann zusätzliche Prüfung ermöglichen, erhöht jedoch die Sichtbarkeit eines Problems. Die curl-Ankündigung setzt die Grenze anhand der eigenen Schweregradeinstufung des Projekts; eine quantitative Bewertung des verbleibenden Risikos enthält sie nicht. [1]

KI-gestützte Suche und die Frage nach der Relevanz

Stenberg kritisiert, dass viele neu eingereichte Meldungen auf ungewöhnlichen Sequenzen oder Kombinationen von Optionen beruhten. Solche Konstellationen könnten laut seiner Darstellung Reaktionen auslösen, die in realen Anwendungen kaum vorkämen oder bei denen ein Problem sofort auffiele. Er bewertet das praktische Risiko mancher dieser Fälle als nahezu null und stellt infrage, ob sie den vollständigen Prozess einer CVE-Behandlung rechtfertigen. [1]

Diese Kritik sollte nicht mit dem Nachweis gleichgesetzt werden, dass KI-gestützte Schwachstellensuche generell unzuverlässig oder nutzlos wäre. Der Bericht enthält weder eine systematische Prüfung der eingereichten Fälle noch eine Aufschlüsselung danach, wie viele Meldungen KI-generiert, technisch valide oder praktisch ausnutzbar waren. Belegt ist hier vor allem die Einschätzung des Maintainers, dass das Projekt mit vielen niedrig eingestuften Befunden und ungewöhnlichen Testkombinationen konfrontiert ist. [1]

Für Sicherheitsverantwortliche ist die Unterscheidung zwischen einem reproduzierbaren Fehler und einem praktisch relevanten Risiko wichtig. Eine Meldung kann eine unerwartete Reaktion aufzeigen, ohne dass daraus automatisch ein realistischer Angriffsweg folgt. Umgekehrt können auch schwer ausnutzbare Fehler für bestimmte Konfigurationen bedeutsam sein. Die neue Regelung verlagert einen Teil dieser Bewertung in eine öffentlichere Diskussion; sie ersetzt nicht die fachliche Prüfung des jeweiligen Falls. [1]

Warum curl für Unternehmensinventare relevant bleibt

Die organisatorische Bedeutung der Änderung ergibt sich auch aus der Verbreitung von curl und libcurl. Ein Beitrag von Outpost24 aus dem Jahr 2023 beschreibt curl als Bestandteil vieler Softwareprodukte, Automatisierungswerkzeuge, Skripte und Verwaltungsanwendungen sowie als eingebettete Abhängigkeit. Der Beitrag hebt hervor, dass solche Komponenten in Systemen stecken können, die seltener gewartet oder aktualisiert werden. Diese Quelle beschreibt den damaligen Kontext und belegt nicht den aktuellen Bestand einer konkreten Unternehmensumgebung. [4]

Damit reicht eine Suche nach einem eigenständig installierten curl-Programm nicht zwangsläufig aus. Wenn ein anderes Produkt die Bibliothek libcurl einbindet, kann die Abhängigkeit für Betriebsteams weniger sichtbar sein. Outpost24 empfahl Anbietern und Betreibern deshalb, Abhängigkeiten ihrer Produkte zu ermitteln und betroffene Systeme nach Sicherheitskorrekturen zu durchsuchen. [4]

Ein früherer Sicherheitsfall zeigt, warum der Schweregrad allein die Prüfung nicht ersetzt. Die 2023 bekannt gewordene CVE-2023-38545 betraf einen Heap-Pufferüberlauf im SOCKS5-Proxy-Handshake; laut Secure Code Warrior waren die Voraussetzungen für eine schwerwiegendere Ausnutzung ein seltener Anwendungsfall. IGEL führte die Schwachstelle für seine Produkte als hoch ein und nannte für damalige Versionen konkrete Aktualisierungen. Diese Angaben beziehen sich auf den historischen Fehler und sagen nichts über die Einstufung künftiger Meldungen aus. [2] [3]

Für Unternehmen folgt daraus keine pauschale Aufforderung, curl unabhängig von einer konkreten Meldung sofort zu aktualisieren. Analytisch spricht die breite Einbettung aber dafür, Abhängigkeiten nicht nur über Paketnamen auf Servern, sondern auch in ausgelieferten Anwendungen und verwalteten Geräten zu erfassen. Ob und wie weit das eigene Unternehmen betroffen ist, muss aus dem jeweiligen Software- und Komponentenbestand ermittelt werden. [4]

Was Sicherheits- und Entwicklungsteams beobachten sollten

Zum Start des neuen Verfahrens sollten Teams, die curl oder libcurl einsetzen oder in eigenen Produkten verteilen, ihre internen Melde- und Patchprozesse darauf abstimmen, dass niedrig und mittel eingestufte Fälle künftig öffentlich auf GitHub erscheinen können. Das bedeutet nicht, dass jede solche Meldung eine bestätigte Schwachstelle oder ein akutes Risiko darstellt. Entscheidend bleiben die technische Prüfung, die betroffene Version und die konkrete Nutzung der jeweiligen Funktion. [1]

Anbieter mit eigenen Softwareprodukten sollten zusätzlich klären, welche Komponenten sie an Kunden weitergeben und wer für deren Aktualisierung zuständig ist. Outpost24 betonte bereits 2023, dass Kunden eingebettete Abhängigkeiten häufig nicht selbst patchen können, wenn der Anbieter kein aktualisiertes Produkt bereitstellt. Das ist ein allgemeiner Hinweis aus dem damaligen Beitrag und kein Nachweis für die konkrete Lieferkette eines Unternehmens. [4]

Die Umstellung ist eine Reaktion auf begrenzte Wartungskapazitäten in einem weit verbreiteten Open-Source-Projekt. Ob die öffentliche Bearbeitung tatsächlich mehr Prüfer anzieht, die Qualität der Korrekturen erhöht oder Angriffsrisiken messbar verändert, lässt sich zum Zeitpunkt der Ankündigung noch nicht beurteilen. Für Unternehmen ist daher zunächst wichtig, den neuen Meldeweg und die öffentliche Verfügbarkeit von Informationen in die eigene Beobachtung von Sicherheitsmeldungen einzubeziehen. [1]

Quellen

1. [1] curl: Konzentration auf hochriskante und kritische Sicherheitslücken | heise online — https://www.heise.de/news/curl-Konzentration-auf-hochriskante-und-kritische-Sicherheitsluecken-11496792.html (abgerufen am 2026-10-22)
2. [2] Deep-Dive: Auffinden und Beheben kritischer Schwachstellen in libcurl/curl | Secure Code Warrior — https://www.securecodewarrior.com/de/blog/deep-dive-finding-and-fixing-high-severity-libcurl-curl-vulnerabilities (abgerufen am 2026-10-22)
3. [3] ISN 2023-23: Curl Vulnerability | IGEL Knowledge Base — https://kb.igel.com/de/security-safety/current/isn-2023-23-curl-vulnerability (abgerufen am 2026-10-22)
4. [4] Abhilfe für die schwerwiegende Schwachstelle in curl — https://outpost24.com/de/blog/schwerwiegende-schwachstelle-curl (abgerufen am 2026-10-22)