curl behandelt Low- und Medium-Lücken künftig öffentlich auf GitHub

Das curl-Projekt nimmt Meldungen zu Schwachstellen mit geringer oder mittlerer Schwere aus der Vertraulichkeit: Laut Maintainer Daniel Stenberg landen ab dem 26. Oktober 2026 alle Meldungen der Schweregrade LOW und MEDIUM als öffentliche Issues im GitHub-Repository, nur HIGH und CRITICAL bleiben privat auf HackerOne. Für Admins und Distributionen bedeutet das: Probleme dieser Klassen werden früher sichtbar, aber nicht mehr zwingend zusammen mit einem fertigen Advisory.

Stenberg beschreibt den Prozess des Projekts und legt Nutzenden keine Pflichten auf. dm-Einordnung: Wer curl oder libcurl betreibt oder paketiert, nimmt die öffentlichen GitHub-Issues des Projekts sinnvollerweise ins Monitoring auf.

Ab 26. Oktober landen leichtere Meldungen auf GitHub statt HackerOne

HackerOne ist eine Plattform, über die Sicherheitsforschende Schwachstellen vertraulich an Projekte melden. Eine vertrauliche Meldung bleibt bis zur Veröffentlichung eines Fixes unter Verschluss. Diese Vertraulichkeit, im Fachjargon Embargo, soll verhindern, dass Angreifende eine Lücke ausnutzen, bevor ein Patch existiert.

Stenberg beschreibt in seinem Blogbeitrag vom 20. Oktober 2026 die Änderung so: Ab dem 26. Oktober 2026 werden Meldungen, die als LOW oder MEDIUM eingestuft sind, als Issues im öffentlichen GitHub-Repository des Projekts behandelt. Nur Meldungen der Stufen HIGH und CRITICAL bleiben privat auf HackerOne. Die Schweregrade sind die übliche Skala für die Einstufung von Sicherheitslücken, von gering bis kritisch; die Einstufung nehmen im Zweifel die Maintainer vor.

Wer bei Zweifel weiter vertraulich melden kann

Wer unsicher ist, ob ein Fund unter HIGH liegt, kann laut Stenberg weiterhin HackerOne nutzen und dort die Einstufung abwarten. Der private Kanal bleibt also bestehen, die Standardroute für leichtere Fälle ändert sich.

Bug-Bounty bereits eingestellt

Das Projekt hat sein Bug-Bounty-Programm, also die Geldprämien für gemeldete Lücken, zuvor beendet. Stenberg nennt als Vorteil des öffentlichen Wegs, dass mehr Menschen bei Bewertung, Fix und Advisory helfen können. Ein Advisory ist die offizielle Sicherheitsmitteilung eines Projekts mit Beschreibung, betroffenen Versionen und Korrektur. Außerdem sehen Distributionen Probleme früher, als es bisher möglich war.

Zum aktuellen Stand: Die jüngste Version ist laut der Änderungsliste auf curl.se curl 8.23.0 vom 14. Oktober 2026.

Was sich für Meldende ändert

Wer eine Auffälligkeit in curl findet, muss künftig selbst abschätzen, ob sie unter HIGH liegt. Bleibt der Zweifel, steht der private Weg über HackerOne weiter offen.

dm-Einordnung: Meldende sollten die Einstufung vor dem Absenden kurz begründen, damit das Team sie nachvollziehen kann. Bei begründetem Zweifel ist der private Weg über HackerOne die sichere Wahl, denn ein öffentliches Issue lässt sich nicht zurücknehmen.

Die „Lawine“ an Meldungen und das längere Zeitfenster

Stenberg begründet den Schritt mit der Menge der Einreichungen. The Register bestätigt den Ablauf und greift das Bild einer „avalanche“ auf, also einer Lawine.

Konkret nennt Stenberg eine Zahl: Laut Stenberg waren über 90 % der Einreichungen der vergangenen Jahre schnell als unter HIGH erkennbar. Der weitaus größte Teil des Aufwands betrifft also Fälle, bei denen Vertraulichkeit kaum Schutz bringt, aber Maintainer in einem geschlossenen Prozess bindet.

KI-erzeugte Optionskombinationen

Als Trend nennt Stenberg Meldungen, die mit KI-Unterstützung entstehen und „crazy sequences or option combinations“ beschreiben, also abwegige Abfolgen oder Kombinationen von curl-Optionen. Ihr Risiko in der Praxis sei gering. Betrieblich relevant ist: Solche Meldungen binden Prüfzeit, auch wenn kaum jemand betroffen ist.

Das benannte Risiko

Stenberg räumt ein Risiko ein: Angreifende bekommen ein etwas längeres Zeitfenster, weil ein Problem öffentlich sichtbar ist, bevor der Fix in Distributionen ankommt. Dieses Risiko habe das Projekt bewusst auf Fälle unterhalb von HIGH begrenzt. Für die Praxis heißt das: Die Lücken, die öffentlich werden, sind per Einstufung die weniger gefährlichen. Die Einstufung bleibt allerdings eine Einschätzung der Maintainer und kann im Einzelfall von der eigenen Bewertung abweichen.

dm-Einordnung: Für Betreibende heißt das, dass bei Low und Medium eher die Frühwarnung zählt als die Geheimhaltung. Wer eigene Builds pflegt, kann einen öffentlichen Fix früher einplanen, muss aber damit rechnen, dass die zugrunde liegende Beobachtung schon vor dem Release für alle lesbar ist. Bei der Bewertung hilft die Frage, ob die betroffene Option im eigenen Einsatz überhaupt vorkommt.

Monitoring für Admins und Distributionen

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptOpen-source maintainer at a home office reviewing an abstract issue tracker on a large monitor, stack of notes, evening light. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Bisher erfuhren Admins von curl-Lücken typischerweise über Advisories des Projekts oder ihrer Distribution. Künftig kann ein LOW- oder MEDIUM-Problem zuerst als Issue auftauchen. Das curl-Projekt macht Admins dazu keine Vorgaben, die Prüfpunkte sind dm-Einordnung.

Was Admins prüfen können

• Die installierte Version feststellen: curl --version zeigt curl- und libcurl-Version sowie die eingebundenen Bibliotheken. Bei Distributionspaketen sagt die Versionsnummer allein wenig, weil Korrekturen oft zurückportiert werden.
• Die Sicherheitsmeldungen der eigenen Distribution weiter als maßgebliche Quelle für verfügbare Updates behandeln.
• Das öffentliche Issue-Tracking des curl-Projekts auf GitHub beobachten, wenn curl in sicherheitsrelevanten Abläufen steckt, etwa bei automatisierten Downloads oder Webhooks.

Ein Issue ist keine bestätigte Schwachstelle. Es kann zurückgewiesen, anders eingestuft oder zusammengelegt werden. dm-Einordnung: Ein Eintrag verlangt zuerst eine Prüfung, ob die genannte Konstellation im eigenen Betrieb vorkommt, und selten einen sofortigen Eingriff. Exploit-Details gehören nicht in interne Tickets oder Weitergaben.

Was sich für Distributionen ändert

Stenberg nennt ausdrücklich die frühere Sicht für Distributionen als Vorteil. dm-Einordnung: Das erleichtert es, Backports vorzubereiten. Ein Backport überträgt eine Korrektur aus der aktuellen Entwicklungslinie auf die ältere Version, die eine Distribution ausliefert. Je früher das Team den Fix kennt, desto eher kann es ihn einplanen. Die Kehrseite ist mehr Beobachtungsarbeit, weil sich Maintainer von Paketen nicht mehr auf einen einzelnen Veröffentlichungstermin verlassen können.

Wer sich mit Meldepflichten und Lieferketten befasst, findet bei Open-Source-Projekten ähnliche Spannungen, etwa in der Debatte um Schwachstellenmeldungen unter dem Cyber Resilience Act. Auch dort geht es darum, wie schnell Informationen bei den Betreibenden ankommen.

Meldungen im Team triagieren

dm-Einordnung: Wenn Low- und Medium-Meldungen als Issues erscheinen, entsteht für Teams mit curl im Betrieb ein zusätzlicher Eingang, den jemand bewusst beobachten muss. Sinnvoll ist eine klare Zuständigkeit, etwa eine Person je Woche, die neue Issues sichtet und nicht jede Meldung an das gesamte Team weiterreicht. Die Triage bleibt dadurch klein und wird nicht nebenbei erledigt.

Der erste Prüfschritt ist der Abgleich mit dem eigenen Einsatz: Welche Protokolle und Optionen nutzen die eigenen Anwendungen tatsächlich? Stenberg beschreibt, dass KI-gestützte Meldungen oft ungewöhnliche Folgen von Optionen oder Kombinationen enthalten, deren Risiko in der Praxis gering ist. Solche Konstellationen lassen sich mit dem eigenen Einsatz schnell abgleichen. Das Ergebnis sollte kurz dokumentiert werden, etwa als Vermerk im Ticket mit Begründung, damit eine spätere Neubewertung nach dem Advisory oder dem Fix nachvollziehbar bleibt.

libcurl steckt in vielen Paketen

curl ist mehr als das Kommandozeilenwerkzeug. Die zugehörige Bibliothek libcurl wird von zahlreichen Programmen eingebunden, die Daten über Netzwerkprotokolle laden. Dass libcurl breit eingesetzt wird, ist der Grund, warum eine Prozessänderung im curl-Projekt über das Projekt hinaus wirkt.

Wo die Abhängigkeit im Betrieb sichtbar wird

Auf einem Server können mehrere libcurl-Instanzen liegen: die Systembibliothek, eine mitgelieferte Kopie in einer Anwendung oder eine statisch eingebundene Variante in einem Container-Image. curl --version zeigt nur das, was das aufrufende Kommando nutzt. dm-Einordnung: Für ein belastbares Inventar müssen Admins zusätzlich Paketlisten und Images prüfen. Wo eine Anwendung ihre eigene Kopie mitbringt, hilft das Distributions-Update nicht, dort muss der Hersteller nachziehen.

Für bekannte ausgenutzte Schwachstellen im Inventar gilt dasselbe Prinzip wie für libcurl: Erst wer weiß, wo die Bibliothek läuft, kann eine Meldung einordnen.

Kontext: Druck auch bei anderen Projekten

The Register stellt die Änderung in einen größeren Zusammenhang und erwähnt, dass auch Postgres und der Linux-Kernel durch KI-gestützte Reviews unter Druck stehen. Das ist Kontext, kein Beleg dafür, dass dort dieselben Maßnahmen geplant wären. Wer Kernel-Themen im Betrieb verfolgt, sieht ähnliche Prozessfragen etwa bei Kernel-Patches für KVM-Hosts, ohne dass sich daraus auf curl schließen ließe.

Folgen für Paketierende und Anwendungsherstellende

dm-Einordnung: Paketierende von Distributionen profitieren nach Stenbergs Darstellung von der früheren Sicht auf Meldungen. Sie können Fixes früher beobachten und Backports vorbereiten, bevor das Advisory erscheint. Dafür müssen sie die öffentlichen Issues allerdings aktiv verfolgen; ein Advisory als einziges Signal reicht dann nicht mehr für die frühe Planung.

Anwendungsherstellende, die libcurl fest einbinden oder mitliefern, tragen die Aktualisierung selbst. Sie sollten wissen, welche curl-Version in welchem Produkt steckt, und bei einem relevanten Issue entscheiden, ob ein eigener Release nötig ist. Eine gepflegte Liste der eingebetteten Versionen verkürzt diese Entscheidung deutlich.

dm-Einordnung: Konkret zu tun ist vor dem 26. Oktober wenig: prüfen, welche curl- und libcurl-Versionen im Bestand laufen, und festlegen, wer GitHub-Issues des Projekts im Blick behält und Meldungen mit der Distribution abgleicht.