// HEISE ONLINE — CYBERSECURITY
curl: Konzentration auf hochriskante und kritische Sicherheitslücken
Das curl-Projekt will sich auf dem HackerOne-Bugtracker auf hochriskante und kritische Sicherheitslücken beschränken.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Das curl-Projekt passt das Schwachstellen-Veröffentlichungsprogramm (Vulnerability Disclosure Program) zum 26. Oktober 2026 an. Ab dann bestehen die Entwickler darauf, dass Sicherheitslücken, die mit dem Bedrohungsgrad „niedrig“ oder „mittel“ eingestuft werden, nur noch über das GitHub-Repository eingereicht werden. Nur Schwachstellen, die als Risiko „hoch“ oder „kritisch“ eingestuft werden, werden privat im HackerOne-Tracker verwaltet.
Das hat der Projekt-Maintainer Daniel Stenberg im curl-Blog angekündigt. Die Entwickler sind jedoch gerne bereit, zu helfen, falls Melder von Lücken sich nicht sicher sind. Die können HackerOne weiterhin nutzen, allerdings bewerten die curl-Programmierer den Schweregrad. Sofern das Ergebnis ist, die Lücke sei lediglich von niedrigem oder mittlerem Bedrohungsgrad, werden die Melder gebeten, den Fehler über GitHub zu melden. Auf HackerOne werden die Fälle dann auf den Status „informativ“ gestellt und veröffentlicht. In den letzten Jahren seien mehr als 90 Prozent der Meldungen rasch als weniger gravierend als Risikostufe „hoch“ einsortiert worden.
Die Änderung geht darauf zurück, dass das curl-Projekt mit einer Lawine von Schwachstellenreports überrollt werde. Es sei kein Ende absehbar und nicht damit zu rechnen, dass das in den kommenden Monaten abflaue. Die Mitwirkenden am Projekt seien überlastet. Die Veröffentlichung der Schwachstellen auf Github soll die Öffentlichkeit zur Mitarbeit anregen und das Projekt entlasten.
Die Hoffnung bestehe, dass das Projekt mehr Hilfe erhalte, um sicherzustellen, dass eine Korrektur das Problem löst und jedes andere gleich gelagerte gleich mit, sodass keine verwandten Probleme bestehen bleiben. Sobald das Projekt einen neuen Schwung CVEs veröffentliche, ließen IT-Forscher derzeit ihre KI-Modelle zur Suche ähnlicher Lücken auf die Korrekturen los. Der öffentliche Prozess könne dazu führen, dass ähnliche Lücken schon vor dem Release gefunden und gleich mit gefixt werden.
Die Arbeitslast für die einzelnen Schwachstellenmeldungen sinke zwar nicht, wenn sie öffentlich bearbeitet würden, aber die Last verteile sich hoffentlich besser auf mehr Leute und führe dazu, dass man mehr aus der Analyse und Dokumentation lernen könne. Zudem könnten Distributionen sowie Nutzerinnen und Nutzer von curl so früher mit den Sicherheitskorrekturen Schritt halten.
Bedenken, dass IT-Forscher eine hochriskante Lücke auf GitHub fälschlicherweise mit mittlerem oder niedrigem Bedrohungsgrad einstufen, hält Stenberg für unbegründet. Es gebe so gut wie keine bekannten Fälle, dass IT-Sicherheitsforscher das Risiko eines Problems unterschätzen. Außerdem habe dieses Risiko zuvor auch bestanden.
Das neue Verfahren gebe jedoch bösartigen Akteuren ein wenig mehr Zeit, Schwachstellen zu missbrauchen, räumt Stenberg ein. Das sei unglücklich, aber auch der Grund dafür, dass nur Lücken unterhalb des Schweregrads „hoch“ betroffen sind – wenigstens seien diese Probleme nicht fürchterlich. Man habe auch darüber nachgedacht, Meldungen mit dem Risiko „niedrig“ ganz zu verwerfen. Nach CVE-Regularien gebe es dafür jedoch ein Berufungsverfahren, und wenn curl für eine echte Lücke keine CVE vergebe, tue es jemand anderes.
Stenberg beschwert sich noch mal darüber, dass viele der neu gemeldeten Schwachstellen mit KI-Modellen aufgespürt wurden, die verrückte Sequenzen oder Optionskombinationen nutzen, die in unerwarteten Reaktionen münden. Diese Sequenzen würden in der Realität eigentlich nie genutzt, oder die Reaktionen treten jedes Mal auf, sodass Apps, die das machen würden, das Problem sofort mitbekommen würden. Das Risiko, dass solche Probleme in der Realität ausgelöst würden, sei nahezu null; es helfe niemandem, für solche Probleme den C