Mythos entdeckt eine curl-Sicherheitslücke

• Anthropic Mythos meldete fünf curl-Sicherheitslücken, tatsächlich blieb aber nur eine übrig
• Die Prüfung durch das curl-Sicherheitsteam ergab, dass drei False Positives waren und eine als gewöhnlicher Bug eingestuft wurde
• Die bestätigte Schwachstelle wird als CVE mit niedrigem Schweregrad eingestuft und soll Ende Juni zusammen mit curl 8.21.0 veröffentlicht werden
• Der Bericht enthielt rund 20 Bugs, und das curl-Team behebt derzeit die Punkte, denen es zustimmt
• Daniel Stenberg sieht in den curl-Ergebnissen allein nur schwache Hinweise darauf, dass Mythos ein besonders gefährliches Niveau erreicht

---

Der Weg von Anthropic Mythos zu curl

• Anthropic sorgte für großes Aufsehen, als das Unternehmen im April 2026 zu dem Schluss kam, dass sein neues KI-Modell Mythos „gefährlich gut“ darin sei, Sicherheitslücken im Quellcode zu finden
• Anthropic veröffentlichte Mythos nicht sofort, sondern entschied sich dafür, es zunächst einigen Unternehmen eingeschränkt bereitzustellen, damit diese Zeit haben, wichtige Probleme zu beheben
• Als Teil von project Glasswing gab Anthropic über die Linux Foundation auch „Open-Source-Projekten“ Zugang zum neuesten KI-Modell
• Die Linux Foundation übertrug diesen Teil an Alpha Omega, und das Angebot wurde an Daniel Stenberg, den Lead-Entwickler von curl, weitergereicht
• Der Nutzungsvertrag wurde zwar abgeschlossen, der tatsächliche Zugang verzögerte sich jedoch, sodass schließlich eine andere Person mit Mythos-Zugang curl scannte, analysierte und den Bericht übermittelte

Bereits laufende KI-Sicherheitsanalyse bei curl

• curl wurde schon vor dem Mythos-Bericht mit mehreren KI-basierten Tools analysiert und nutzt weiterhin klassische statische Codeanalyse, anspruchsvolle Compiler-Optionen und seit Jahren laufendes Fuzzing
• Vor allem AISLE, Zeropath und OpenAI’s Codex Security prüfen den curl-Code per KI
• Die Analysen dieser Tools führten in den letzten etwa 8 bis 10 Monaten zu 200 bis 300 Bugfixes, die in curl gemergt wurden
• Einige von KI-Tools gemeldete Punkte wurden als echte Sicherheitslücken bestätigt und als CVEs veröffentlicht; davon gibt es „wahrscheinlich mehr als 12“
• Auch GitHub Copilot und Augment code werden für Pull-Request-Reviews verwendet und helfen dabei, gemeldete Probleme zu beheben und besseren Code zu mergen
• KI-Reviews ersetzen keine menschlichen Reviews, sondern dienen als zusätzliches Prüfmittel und tragen dazu bei, die Qualität beim Mergen zu erhöhen
• Auch Sicherheitsforscher nutzen KI umfassend und effektiv, sodass viele hochwertige Sicherheitsmeldungen eingehen
• Im curl-Projekt hat Sicherheit höchste Priorität, und es kommen verschiedene Software-Engineering-Richtlinien und Prozesse zum Einsatz, um Fehler zu reduzieren
• Das Scannen nach Fehlern ist nur einer von mehreren Schritten, um curl sicher zu halten, und es scheint schwer, ein Projekt zu finden, das bei Software-Sicherheit so viel tut oder noch weiter geht als curl

Erste Analyseergebnisse von Mythos am 6. Mai 2026

• Der erste mit Mythos erzeugte Bericht zur Quellcodeanalyse bot die Gelegenheit, Bereiche zur Verbesserung von curl und zu behebende Bugs zu finden
• Der erste Scan wurde auf das git-Repository von curl und einen bestimmten aktuellen Commit im master-Branch angesetzt
• Analysiert wurden 178.000 Zeilen Code in den Unterverzeichnissen src/ und lib/
• Der Bericht beschreibt detailliert, mit welchen Ansätzen und Methoden nach welchen Arten von Fehlern gesucht wurde
• Oben im Bericht stand, curl sei eine der am stärksten gefuzzten und auditierten C-Codebasen mit „OSS-Fuzz, Coverity, CodeQL und mehreren kostenpflichtigen Audits“, weshalb es schwierig sein dürfte, in den zentralen Pfaden von HTTP/1, TLS und URL-Parsing noch etwas zu finden
• In genau diesen Kernpfaden fand Mythos tatsächlich keine Probleme

Größe der curl-Codebasis und Sicherheitsgeschichte

• curl besteht derzeit, Leerzeilen ausgenommen, aus 176.000 Zeilen C-Code
• Der Quellcode umfasst 660.000 Wörter und damit 12 % mehr als die vollständige englische Ausgabe des Romans War and Peace
• Eine Zeile Produktions-Quellcode in curl wurde im Durchschnitt 4,14-mal nach ihrer ursprünglichen Erstellung umgeschrieben
• Der aktuell noch in git master vorhandene ältere Produktionscode wurde von 573 einzelnen Mitwirkenden geschrieben
• Insgesamt wurden bislang Änderungen von 1.465 Mitwirkenden in das curl-git-Repository gemergt
• curl hat bislang 188 CVEs veröffentlicht
• curl ist auf mehr als 20 Milliarden Instanzen installiert
• curl läuft auf mehr als 110 Betriebssystemen und 28 CPU-Architekturen
• curl läuft auf Smartphones, Tablets, Autos, Fernsehern, Spielkonsolen und Servern

Aus „5 bestätigten Sicherheitslücken“ wird tatsächlich 1

• Der Mythos-Bericht kam zu dem Schluss, fünf „Confirmed security vulnerabilities“ gefunden zu haben
• Nachdem das curl-Sicherheitsteam die Details mehrere Stunden lang geprüft hatte, blieb von den fünf nur eine tatsächlich bestätigte Sicherheitslücke übrig
• Drei der übrigen vier wurden als False Positives eingestuft, da sie auf in der API-Dokumentation beschriebene Einschränkungen hinwiesen
• Die verbleibende vierte wurde nicht als Sicherheitslücke, sondern als gewöhnlicher Bug bewertet
• Die einzige bestätigte Sicherheitslücke soll eine CVE mit niedrigem Schweregrad (severity low) werden
• Diese CVE soll Ende Juni zusammen mit der nächsten curl-Version 8.21.0 veröffentlicht werden
• Details zu dieser Sicherheitslücke werden bis zur Veröffentlichung nicht bekanntgegeben
• Der Mythos-Bericht enthielt auch mehrere Bugs, die am Ende nicht als Sicherheitslücken eingestuft wurden, und das curl-Team untersucht und behebt die Punkte, denen es zustimmt, einzeln
• Im Bericht waren rund 20 Bugs gut aufbereitet enthalten, mit nur sehr wenigen False Positives
• Dank dieses Berichts verbessert sich curl zwar weiter, aber gemessen an der Anzahl entdeckter Probleme führten die zuvor eingesetzten KI-Tools zu noch mehr Bugfixes
• Das spiegelt auch wider, dass frühere Tools die zahlreicheren und leichteren Bugs zuerst fanden und neue Fehler mit der Zeit immer schwerer aufzuspüren sind, weil Probleme bereits behoben wurden
• Bugs können klein oder groß sein, daher ist ein reiner Zahlenvergleich nicht immer fair

Mythos wirkt nicht besonders „gefährlich“

• Betrachtet man nur die Analyseergebnisse zu curl, kommt man zu dem Schluss, dass das große Interesse rund um Mythos vor allem Marketing zu sein scheint
• Es gibt keine Hinweise darauf, dass das Mythos-Setup Probleme auf einem besonders höheren oder ausgefeilteren Niveau findet als frühere Tools
• Möglich ist, dass Mythos etwas besser ist, aber nicht so viel besser, dass es bei der Codeanalyse einen grundlegenden Unterschied machen würde
• Diese Bewertung beschränkt sich allerdings auf die Ergebnisse aus einem einzelnen Quellcode-Repository, nämlich curl
• Es ist nicht ausgeschlossen, dass Mythos bei anderen Zielen deutlich besser abschneidet

KI-Codeanalyse bleibt dennoch sehr leistungsfähig

• KI-basierte Codeanalyse ist beim Finden von Sicherheitslücken und Fehlern im Quellcode deutlich besser als traditionelle Codeanalyse aus der Vergangenheit
• Moderne KI-Modelle sind für diese Aufgabe durchweg gut geeignet, und wer Zeit und Experimentierwillen mitbringt, kann Sicherheitsprobleme finden
• Hochwertiges Chaos findet tatsächlich statt
• Projekte, die ihren Quellcode noch nicht mit KI-basierten Tools gescannt haben, werden mit dieser Tool-Generation wahrscheinlich viele Fehler, Bugs und potenzielle Sicherheitslücken finden
• Das gilt nicht nur für Mythos, sondern auch für viele andere KI-Tools
• Wer im Projekt keine KI-Codeanalyse nutzt, lässt Angreifern und böswilligen Akteuren Zeit und Gelegenheit, unentdeckte Fehler zu finden und auszunutzen

Worin sich KI-Analysatoren von klassischen Analysatoren unterscheiden

• KI-Analysatoren können erkennen, wenn Kommentare etwas über den Code sagen, das nicht zum tatsächlichen Verhalten des Codes passt
• Sie können auch Code für Plattformen und Konfigurationen prüfen, auf denen sich klassische Analysatoren normalerweise nicht ausführen lassen
• Sie „kennen“ Details von Drittanbieter-Bibliotheken und APIs und können dadurch Missbrauch oder falsche Annahmen erkennen
• Sie „kennen“ auch die Protokolldetails, die curl implementiert, und können Stellen beanstanden, an denen der Code gegen Protokollspezifikationen zu verstoßen oder ihnen zu widersprechen scheint
• Sie sind in der Regel gut darin, Fehler zusammenzufassen und zu erklären, was bei klassischen Analysatoren mühsam und schwierig sein kann
• Sie können Patches für entdeckte Probleme erzeugen und vorschlagen, auch wenn diese Patches meist keine zu 100 % vollständige Behebung darstellen

Details aus dem Mythos-Bericht

• Der Mythos-Bericht kam zu dem Schluss, dass es 0 Memory-Safety-Sicherheitslücken gibt
• Methodisch war diese Prüfung eine manuell gesteuerte Analyse, die LLM-Subagenten für paralleles Lesen von Dateien einsetzte
• Vor der Aufzeichnung wurden alle potenziellen Funde in der Hauptsitzung nochmals durch direkte Prüfung des Quellcodes verifiziert
• Das Mapping von CVEs und Variantensuche wurde aus curls eigenem vuln.json aufgebaut
• Automatisierte SAST-Tools wurden nicht eingesetzt
• Diese Ergebnisse passen dazu, dass curl zu den am stärksten gefuzzten und auditierten C-Codebasen zählt
• Die Abwehrinfrastruktur von curl schließt systematisch Bug-Klassen, die in Codebasen dieser Größenordnung typischerweise leicht Erfolge bringen
• Zu den Abwehrmechanismen gehören begrenztes dynbuf, curlx_str_number mit expliziten Maximalwerten bei sämtlichem Zahlenparsing, curlx_memdup0 mit Overflow-Schutz, Durchsetzung von CURL_PRINTF-Formatstrings, protokollspezifische Antwortgrößenbegrenzungen und das pingpong-Zeilenlimit von 64 KB
• Die Abdeckung umfasst alle kleineren Protokolle, alle Dateiparser, alle Verifikationspfade sämtlicher TLS-Backends, HTTP/1·2·3, die volle FTP-Tiefe, mprintf, x509asn1, DoH, alle Authentifizierungsmechanismen, Content-Encoding, Verbindungswiederverwendung, Session-Cache, das CLI-Tool, plattformspezifischen Code sowie die CI- und Build-Supply-Chain

KI findet bekannte Fehlertypen in neuer Ausprägung

• KI-Tools finden bereits bekannte, allgemeine und etablierte Arten von Fehlern und entdecken davon lediglich neue Instanzen
• Bislang hat KI noch keine völlig neue Klasse von Sicherheitslücken oder einen zuvor unbekannten Typ von Schwachstelle gemeldet
• KI erfindet das Sicherheitsfeld in dieser Hinsicht also nicht neu
• Sie fördert allerdings mehr Probleme zutage als jedes frühere Tool

Die Fehlersuche ist noch nicht vorbei

• Diese Ergebnisse waren nicht die letzte Bug-Entdeckung oder Meldung
• Schon zu diesem Zeitpunkt gingen weitere Meldungen von Sicherheitsforschern zu mutmaßlichen Problemen ein
• KI-Tools werden sich weiter verbessern, und Forscher könnten neue und andere Prompt-Methoden finden, mit denen bestehende KI noch mehr Probleme entdeckt
• curl soll weiterhin wiederholt mit Mythos und anderer KI gescannt werden, bis wirklich keine neuen Probleme mehr auftauchen

[GN⁺]

Hacker-News-Kommentare

• Zitat: „Man kann eigentlich nur zu dem Schluss kommen, dass der große Hype um dieses Modell vor allem Marketing war. Ich habe keine Hinweise gesehen, dass dieses Setup Probleme auf einem besonders viel höheren Niveau oder auf deutlich ausgefeiltere Weise findet als frühere Tools vor Mythos. Vielleicht ist es etwas besser, aber nicht so gut, dass es einen bedeutenden Unterschied bei der Codeanalyse machen würde.“
  Eine Erinnerung für alle daran, dass der Wettbewerb in diesem Bereich hart ist und viel offenes wie auch subtileres Marketing beigemischt wird.

  • Es ist auch nicht überraschend, dass Anthropic Marketing einsetzt, um zu überzeugen, dass das eigene Modell fortschrittlicher und besser gebaut ist und dass KI eine Bedrohung sei, die Regulierung brauche und auf die nur sie selbst die Antwort hätten.
    Etwas ernster betrachtet habe ich bisher nur wenige Anzeichen gesehen, dass Mythos mehr ist als Opus mit einer auf Sicherheit fokussierten Codeanalyse-Vorrichtung. Trotzdem ist der wichtigere Punkt, abgesehen von der Übertreibung in der Werbung, dass man solche Bugs überhaupt automatisch finden kann.
    Ich frage mich, wie hoch die Fehlerrate bei der Erkennung ist. Wenn 90 % falsch sind und wir nur von den Fällen hören, die sich fürs Marketing eignen, bedeutet das nicht viel.
  • Das ist ungefähr das erwartete Ergebnis, aber der große Hinweis war schon, dass bestehende LLM-basierte Tools bereits auf breit auditierten Codebasen eingesetzt wurden.
    Deshalb kann Anthropics Marketing zwar übertrieben sein, aber es war von vornherein nicht mehr viel übrig, und der Artikel sagt das auch.
    Ob das ein großer Fortschritt für andere Arten von Projekten ist, lässt sich schwer beurteilen, aber es ist klar geworden, dass eigentlich heute schon alle KI-Code-Review-Tools für bestehende Code-Audits einsetzen sollten und in der Praxis eben nicht alle das tun.
  • curl ist kein guter Datenpunkt. Es ist eine der am stärksten durchleuchteten Codebasen überhaupt, und auch die Praktiken für Sicherheitstests sind sehr solide.
    Forschende, die Modelle nutzen, die Mythos ähneln, aber nicht identisch sind, hatten bisher ebenfalls genug Zeit, Bugs zu melden. Daniel hat vielleicht recht damit, dass Mythos für curl kein spielveränderndes Tool war, aber bei fast allen anderen Codebasen sind die Voraussetzungen anders. Das eigentliche Marketing könnte eher seine Bescheidenheit bezüglich des Reifegrads von curl sein.
  • Macht Mozilla hier Marketing für Anthropic?
    Im Rahmen einer laufenden Zusammenarbeit mit Anthropic hatten wir die Gelegenheit, eine frühe Version von Claude Mythos Preview auf Firefox anzuwenden. Die dieswöchige Firefox-150-Veröffentlichung enthält Korrekturen für 271 Schwachstellen, die in dieser frühen Bewertung identifiziert wurden.
    Während diese Fähigkeit mehr Verteidiger erreicht, erleben viele Teams denselben Schwindel, den wir hatten, als die ersten Ergebnisse klar wurden. Schon ein einzelner solcher Bug in einem gut abgesicherten Ziel wäre 2025 ein Alarmzeichen gewesen, aber wenn so viele auf einmal auftauchen, hält man unweigerlich inne und fragt sich, ob man überhaupt aufholen kann.
    https://blog.mozilla.org/en/privacy-security/ai-security-zer...
  • Gut möglich, dass der Hype vor allem Marketing war.
    Eine andere Möglichkeit ist, dass curl einfach sicher genug ist und es deshalb viel weniger zu finden gab als in anderen Projekten.

• Ich stimme der Formulierung „ein wirklich erstaunlich erfolgreiches Marketing-Event“ zu. Anthropic hat das gut gemacht.
  Es hat sogar die CISO einer kleinen halbstaatlichen Organisation in den Niederlanden erreicht, und sie geriet wegen der Ankündigung eines Tsunamis an Schwachstellen, der mit Mythos komme, leicht in Panik.
  Dadurch habe ich im Vorstand mehr Budget und Priorität bekommen. Gute Marketing-Angst sollte man nicht verschwenden.

  • Ich stimme „einen Tsunami sehe ich nicht“ nicht zu. In Firefox über 100 Bugs und weitere in mehr Open-Source-Projekten, zuvor ungesehene alte Remote-Code-Execution-Schwachstellen in OpenBSD/Linux und selbst im Linux-Kernel mehrere lokale Privilegieneskalationen innerhalb von nur 2–3 Wochen.
    Für mich sieht das nicht nach Marketing-Angst aus, sondern nach einem sprunghaften Anstieg hochwertiger Schwachstellenmeldungen mit geringer False-Positive-Rate. Es wirkt, als würde man in wenigen Wochen mehrere Jahre hochwertiger Bug-Reports im Schnelldurchlauf durchgehen.
  • Anthropic ruiniert mit immer demselben Trick schnell die Sympathie seiner Kunden. Für mich ist das persönlich schreckliches Marketing.
    Es ist etwas völlig anderes, ob ein Unternehmen die Cybersecurity-Bedrohungen allgemeiner LLMs untersucht oder ob es die Diskussion in Richtung „unser neues Modell ist so mächtig“ lenkt. Das ist schmierig und unangenehm.
  • Er erklärt ziemlich ausführlich, dass curl softwaretechnisch fast bis ans Limit poliert wurde. Glaubt wirklich jemand, dass der Großteil des Codes genauso hochgradig verfeinert ist?

• Wenn ein KI-Agent in einem Software-Utility 0 Bugs gefunden hat, warum sollte das bedeuten, dass dieser KI-Agent beim Bugfinden nicht besonders gut ist?
  Was, wenn es tatsächlich 0 Bugs gibt?
  Die Erwartung „Fünf Probleme fühlten sich wie nichts an für uns, die wir eine umfangreiche Liste erwartet hatten“ könnte schlicht nicht zur Realität gepasst haben. Aber der Grund dafür muss nicht zwingend sein, dass Mythos weniger kann als behauptet. curl könnte in seinem aktuellen Zustand einfach ein gut gehärtetes Tool mit nicht vielen Sicherheitslücken sein.

  • Der Autor hat denselben Punkt auch bei den verbliebenen Bugs bedacht.
    „Weitere Dinge zu finden. Dies sind ganz sicher nicht die letzten Bugs, die diese Tools finden oder melden werden. Schon während ich den Entwurf dieses Blogposts schrieb, bekam ich weitere Meldungen von Sicherheitsforschern über mutmaßliche Probleme. KI-Tools werden sich weiter verbessern, und Forschende könnten neue und andere Prompt-Methoden finden, mit denen heutige KI mehr entdeckt. Wir sind noch nicht am Ende angekommen. Ich hoffe, wir können curl immer wieder mit Mythos und anderer KI scannen und weitermachen, bis wir wirklich keine neuen Probleme mehr finden.“
    Das klingt plausibel. Anzunehmen, dass genau noch ein echter Fund übrig war, ausgerechnet Mythos ihn zum Zeitpunkt des Mythos-Launches als einziges gefunden hat und andere Projekte bis unmittelbar davor alle Funde rasch eingesammelt hatten, verlangt schon eine ziemlich große Zufälligkeit. Möglich ist es, aber als sicherster Ausgangspunkt für Zweifel taugt es nicht.

• Man muss curl von seiner Natur her wohl als ein relativ einfaches und klar abgegrenztes Tool sehen. Verglichen mit Betriebssystemen, Webbrowsern, Datenbanken oder den Codebasen von Unternehmen mit Milliardenbewertung.
  Dass Mythos/ChatGPT 5.5 bei Komplexität, die curl nicht hat, deutlich besser abschneiden könnte, ergibt bis zu einem gewissen Grad Sinn. curl hat zwar sehr viele Funktionen als „Client für alles Mögliche“, aber die Komplexität liegt trotzdem um einige Größenordnungen unter anderer Software, von der wir abhängen.

  • curl ist viel komplexer, als man denkt. Die meisten kennen es nur als Kommandozeilen-Tool, das HTTP(S)-Endpunkte aufruft und die Ausgabe ausgibt, aber tatsächlich unterstützt es fast alle Dateiübertragungsprotokolle und ist eine Bibliothek, die für langlebige Prozesse ausgelegt ist.
    Weil es langlebige Prozesse im Blick hat, nutzt es alle möglichen Techniken, um Verbindungen und Ressourcen zu pipelinen und wiederzuverwenden. Es hat auch asynchrone APIs, damit es sich in bestehende Event-Loops integrieren lässt.
    Sind Webbrowser oder Datenbanken komplexer? Sehr wahrscheinlich ja. Sie lösen wirklich gewaltige Probleme. Aber curl ist ganz sicher komplexer als der Großteil des Anwendungscodes, der es benutzt.
  • Ich stimme zu, dass es ein ziemlich grundlegendes Tool ist, aber wie im Artikel gesagt, ist der Code länger als Krieg und Frieden. In einer Größenordnung wie dieser gibt es immer noch reichlich Raum für Sicherheitslücken.
  • Aus dem Artikel zitiert: „curl umfasst derzeit 176.000 Zeilen C-Code, wenn man Leerzeilen ausnimmt. Der Quellcode besteht aus 660.000 Wörtern, also 12 % mehr Wörtern als die gesamte englische Ausgabe des Romans Krieg und Frieden.“
    „curl ist auf mehr als 20 Milliarden Instanzen installiert. Es läuft auf über 110 Betriebssystemen und 28 CPU-Architekturen. Es läuft auf jedem Smartphone, Tablet, Auto, Fernseher, jeder Spielkonsole und jedem Server auf der Erde.“
    Das als einfach oder klar abgegrenzt zu bezeichnen, fällt schwer. Die meisten Betriebssysteme oder Webbrowser laufen schließlich nicht auch noch in Autos oder Fernsehern.

• Das Fazit „nicht besonders gefährlich“ scheint mir nicht wirklich zu folgen. Wie erwähnt wurde curl bereits mit allen verfügbaren Tools gründlich analysiert, und die meiste Software ist nicht auf diesem Niveau.

  • Aber Mythos wird nicht als Tool vermarktet, das das, was bestehende Tools schon können, nur ein bisschen besser macht, sondern als Revolution.
  • Mythos ist entweder gefährlich oder nicht. Gefährlich bedeutet hier: „findet weit mehr Schwachstellen als die mit verfügbaren Tools auffindbaren Bugs“.
    Mythos hat genau eine zusätzliche Schwachstelle gefunden, und x+1 ist nicht viel größer als x, also folgt aus dieser Definition, dass Mythos nicht gefährlich ist.
  • Stimmt, aber ist das nicht ein Urteil über Mythos im Vergleich zu anderen Modellen?
    Dann gilt das Fazit trotzdem. „Der Großteil der Software“ wurde nicht so analysiert wie curl, weder mit anderen Tools noch mit anderen Modellen. Wenn diese Tools fast dieselben Ergebnisse wie Mythos liefern können, ist es schwer, Mythos als besonders gefährlich zu sehen.
  • Bezog sich „nicht besonders gefährlich“ nicht auf die entdeckten Schwachstellen? Sie werden wohl am besten wissen, was sie als geringe Schwere einstufen.
  • curl erhält derzeit rekordverdächtig viele hochwertige Bug-/Schwachstellenmeldungen. Das ist ein ziemlich abrupter Wandel gegenüber den früheren minderwertigen Massenmeldungen und bedeutet nicht, dass nichts mehr zu finden wäre.
    Viele oder die meisten davon scheinen von menschlichen Experten mit Unterstützung von KI-Tools gefunden worden zu sein, aber wenn Mythos wirklich revolutionär wäre, müsste es solche Probleme auch eigenständig finden können.
    https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/, im Originalartikel verlinkt.

• Beeindruckend fand ich die Stelle: „Die bestätigte einzelne Schwachstelle wird eine CVE mit geringer Schwere sein und soll zusammen mit der nächsten curl-Veröffentlichung 8.21.0 Ende Juni offengelegt werden.“
  Es ist immer noch schwer zu begreifen, wie viel Qualität und Feinschliff in cURL steckt. Ein perfektes Beispiel für etwas, das so gut gebaut ist, dass die Leute kaum noch zweimal darüber nachdenken.

  • Ganz einfach. Es zeigt, was möglich ist, wenn man unabhängig von der Programmiersprache auf jede einzelne Codezeile, die committet, reviewt und gemergt wird, hohe Qualitätsstandards anlegt.
    Aber im Zeitalter des Rennens nach unten, billiger Offshoring-Modelle und jetzt LLM-basierter Codegenerierung wird sich die Mehrheit der Unternehmen für diese Qualität nicht interessieren, solange keine Verantwortlichkeit entsteht.
  • curl und SQLite sind meine Lieblingsbeispiele für „alles Mögliche“, das richtig technisch gebaut und streng getestet wurde. Das hat wirklich etwas Philosophisches.
    Die Anforderungen an Beiträge in diesen Projekten verlangen genau diese Strenge, und die Maintainer setzen sie durch. Möglich wird das durch Dokumentation, die keine Last trägt, also Dokumentation, die nicht der Projektcode selbst ist. Das erinnert mich an Einsteins Gedankenexperimente, die zu praktischen Projekten wie GPS führten, oder an Descartes’ Überzeugung, dass sich alle Probleme durch vernünftiges Denken lösen lassen.
  • Ironisch ist, dass alles so gut gebaut ist und die Leute am Ende trotzdem curl ... | bash ausführen, ohne dabei ein Problem zu sehen. Dann weichen sie mit Begriffen wie „Threat Model“ aus.
    Ich passe bei curl-bash, und nutze lieber einen kryptografisch signierten Paket-Installer.

• Ich weiß, dass der Hype um Mythos Teil von Anthropics Marketing ist, aber wäre es bei einer hochgradig überprüften Codebasis nicht auch möglich, dass es im aktuellen Zustand einfach keine auffälligen Security-Exploits gibt?
  Dass nichts gefunden wurde, ist nicht zwingend belastende Evidenz. Besonders dann nicht, wenn andere Tools zuvor bereits Hunderte von Schwachstellen identifiziert hatten. Im Moment wirkt es einfach vollständig durchleuchtet.

• Marketing ist immer beigemischt, und die Leute sollten Marketing im Kontext betrachten können.
  Außerdem ist curl ein Open-Source-Projekt und relativ klein, aber kritisch, bekannt und überall im Einsatz. Abgesehen von Bildbibliotheken wären curl oder Tools wie sudo, su oder passwd auch für mich erste Ziele.
  Was Mythos tatsächlich kann, ist noch überhaupt nicht bekannt. Was bedeutet ein Modell mit 10 Billionen Parametern in Bezug auf Kosten und Benchmarks?
  Trotzdem: Wenn LLMs erst vor etwa einem halben Jahr begonnen haben, bei solchen Problemen viel besser als Menschen zu werden, dann muss man irgendwann der Realität ins Auge sehen, die alle ignoriert haben. Heute muss man LLMs zusätzlich für Security-Scans einsetzen und das ernst nehmen.
  Selbst im schlimmsten Fall kann man Anthropics Marketing nutzen, um zu sagen, dass das jetzt Pflicht ist und sich etwas verändert hat.

  • Zur Frage „Was bedeutet ein Modell mit 10 Billionen Parametern in Bezug auf Kosten und Benchmarks?“: Für mich bedeutet das, dass wir den oberen Teil der S-Kurve der Skalierungseffekte erreicht haben.
    Wenn das Tool in dieser Größenordnung nicht merklich besser ist, befindet man sich klar im Bereich abnehmender Erträge.
  • Dass „noch überhaupt nicht bekannt ist, was Mythos kann“, ist beabsichtigt. Man muss aber nur bedenken, was die Leute ihm bereits jetzt alles zutrauen.
  • Bei „LLMs sind beim Finden solcher Probleme viel besser geworden als Menschen“ rolle ich mit den Augen. Allgemeine statische Analyse-Tools waren bei bestimmten mechanischen Aufgaben schon seit Jahrzehnten besser als Menschen, und bei bestimmten mechanischen Aufgaben besser zu sein als Menschen bedeutet nicht viel.
    Neu und interessant sind die potenziellen Arten von „unscharfen Bugs“, die LLMs laut dem Artikel erkennen können. Zum Beispiel wenn Code nicht zu dem passt, was Kommentare beschreiben, wenn Third-Party-Bibliotheken auf ungewöhnliche Weise verwendet werden, wenn Code und das implementierte Protokoll auseinanderlaufen oder wenn Code einfach insgesamt seltsam aussieht und sich das jemand genauer ansehen sollte. Das füllt eine Lücke im klassischen Debugging-Werkzeugkasten, sollte diese Werkzeuge aber nicht ersetzen.

• Für mich ist die Botschaft rund um Mythos, dass es das Fachwissen der besten Security-Experten und der besten Experten für Sprachen, Protokolle und Code jedem mit Zugang verfügbar macht.
  Die Gefahr bestand darin, diese Zugriffsmöglichkeit der ganzen Welt zu geben, bevor Verteidiger Zugang zu genau diesem Niveau an Expertise hatten.
  curl steht im Zentrum von allem, deshalb wurde es seit Jahren von Security-, Protokoll- und Sprachexperten untersucht. Dass Mythos dort etwas gefunden hat, ist interessant, aber weder ein Zeichen dafür, dass es nur Marketing-Hype ist, noch dass es ungefährlich wäre.
  99,99 % der Projekte sind wahrscheinlich nicht so sicher wie curl. Egal ob Open Source oder Closed Source. LLMs werden Closed-Source-Projekte bereitwillig dekompilieren und untersuchen. Wenn ein Projekt nicht gefuzzt und von bestehenden KI-Tools sowie Experten geprüft wurde, sollte man bereits jetzt davon ausgehen, dass es kompromittierbar sein könnte. Das gilt schon mit den heutigen Tools, und etwas wie Mythos gibt einem breiteren Nutzerkreis mit weniger Expertise Zugang zu genau solchen Fähigkeiten.

  • Stimme zu. Anthropic hat nie übermenschliche Leistung behauptet, sondern nur Geschwindigkeit und Skalierung.
    Dass man in gut erforschter Software nicht viele neue Schwachstellen findet, sagt über das allgemeine Missbrauchspotenzial rein gar nichts aus.

• Es liest sich wie: „curl ist eine der am stärksten gefuzzten und auditierten C-Codebasen überhaupt. Es gab OSS-Fuzz, Coverity, CodeQL und mehrere bezahlte Audits. Im Hot Path von HTTP/1, TLS und dem URL-Parsing-Kern noch etwas zu finden, ist schwer.“
  Diese Formulierung klingt eher so, als hätte das LLM gar nicht erst wirklich versucht, statt es versucht und gescheitert wäre. Ich habe bei Claude oft gesehen, dass es sich so verhält, wenn man nicht nachhakt und es ausdrücklich zu einer Herausforderung drängt, und ich frage mich, was hier tatsächlich passiert ist.

[GN⁺]

Lobste.rs-Kommentare

• Für sich genommen vielleicht nicht allzu erstaunlich, aber dieses Ergebnis sollte man wohl eher als Folgendes sehen: „Seit dem Erscheinen früherer Modelle wurde fast täglich angegriffen, und in einer der am gründlichsten geprüften Anwendungen wurde mit nur einem einzigen Lauf ein Sicherheitsproblem gefunden.“

  • „Gewöhnliche statische Codeanalyse ständig laufen lassen, die strengsten Compiler-Optionen verwenden und über Jahre hinweg fuzzing betreiben“ ist etwas, das anderswo überraschend selten wirklich gemacht wird.
    Vielleicht müssen wir uns nun auf eine dunkle Phase einstellen, in der Sicherheit nachlässt oder verschwindet, bis alles neu geschrieben ist.
  • Dass LLMs immer besser darin werden, Schwachstellen zu finden, stimmt zwar, aber ich verstehe nicht, warum curl als eine der am häufigsten auditierten Anwendungen beschrieben wird.
    curl hatte ein Bug-Bounty-Programm und hat damit eine gewisse Forschung angezogen, was letztlich auch dazu führte, dass Daniel von AI-Müllmeldungen überflutet wurde. Aber als Ziel für Schwachstellenforschung, ob öffentlich oder privat, gehörte es nie zur absoluten Spitzenklasse der interessantesten Ziele.
    Es fällt nicht in die Kategorie „Hier findet man selbst mit viel Aufwand nichts“, besonders dann nicht, wenn man quasi subventionierte massive Rechenressourcen einsetzen kann.
  • Die Schwachstelle hat außerdem geringe Schwere.
    Laut Blogbeitrag heißt es: „Die eine bestätigte Schwachstelle wird eine CVE mit niedriger Schwere sein, die zusammen mit dem nächsten curl-8.21.0-Release veröffentlicht werden soll, das für Ende Juni geplant ist.“
    Außerdem soll es vier False Positives gegeben haben.

• „Am Ende bekam eine andere Person mit Modellzugang das Angebot, den curl-Scan und die Analyse mit Mythos stellvertretend für mich durchzuführen und mir den Bericht zu schicken. Für mich machte das keinen großen Unterschied. Ich hätte ohnehin nicht viel Zeit gehabt, verschiedene Prompts auszuprobieren und tief einzusteigen.“
  Genau so verhält man sich, wenn man eine Hype-Maschine betreibt, die weniger liefert als versprochen: „Probieren Sie unser Ding aus! Nein, also direkt selbst benutzen werden Sie es nicht. Wir machen das schon für Sie!“ Und im Hintergrund läuft dann die traditionelle und teure Methode.
  Ich weiß nicht, ob das hier auch so war, aber ich halte die Möglichkeit nicht für so gering, dass man sie ignorieren könnte. Ich frage mich, wer sonst noch angesprochen wurde, Mythos zu benutzen, es aber in Wirklichkeit gar nicht selbst benutzen konnte und nur Ergebnisse bekam.

  • Vielleicht haben sie einfach nur eine Schwachstelle vom Schwarzmarkt gekauft und dann so dargestellt, als hätte Mythos sie gefunden. Dann wäre das nur ein von AI ausgespuckter Datenpunkt.
    Es ist sogar möglich, dass viele dieser Funde Schwächen betreffen, die in dunklen Foren diskutiert werden, in die Maintainer selten schauen.
    Das heißt nicht, dass AI Software nicht sicherer machen kann. Aber wenn AI-Unternehmen ihre Karten zu sehr verdecken, kann man nicht mehr erkennen, was wirklich echt ist.
  • Ich frage mich, ob man auch nach alternativen Erklärungen gesucht hat, die die bisherigen Ansichten über Anthropic nicht bestätigen.

• Vor drei Monaten habe ich gesehen, wie diese Person auf einer Bühne ankündigte, ihr Bug-Bounty-Programm wegen AI-Müllmeldungen zu beenden.
  Ich frage mich, ob das Tool wirklich so viel besser geworden ist oder ob die Leute jetzt, da der finanzielle Anreiz weggefallen ist, einfach mehr Zeit darauf verwenden, echte Schwachstellen von Müll zu unterscheiden.

  • Unter https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/ steht etwas dazu. Jedenfalls scheinen die Müllmeldungen tatsächlich aufgehört zu haben.

• Auf Mastodon eignen sich solche Ergebnisse hervorragend dazu, Bestätigungsfehler auf Hochtouren laufen zu lassen.
  Wenn man den Bestätigungsfehler aber beiseitelässt, scheint mir das nicht geeignet, um es zu verallgemeinern. Trotzdem ist es gut, dass solche Datenpunkte veröffentlicht werden.

  • Ich weiß nicht, wie sehr das auf Mastodon insgesamt zutrifft, aber mein Umfeld ist so stark anti-AI, dass selbst erfahrene Leute einfach einen GitHub-Link in das Claude-Chat-Interface werfen und dann zeigen wollen, dass es nutzlos ist.
    Aber dafür ist das gar nicht das richtige Werkzeug. Und wenn man Leuten Ergebnisse zeigen will, ist es wirklich schwer, weil sie nur auf die Fehlbeispiele zeigen und darüber lachen wollen.

• Ich würde gern mehr solcher Beiträge sehen.
  Dass bei curl nur eine einzige Schwachstelle mit geringer Schwere herauskam, ist ermutigend, gleichzeitig ist es eben nur ein Einzelfall. Es könnte auch sein, dass curl einfach reifer ist als andere zentrale Bibliotheken.

• „Die ganze Welt schien den Verstand verloren zu haben. War das das Ende der Welt, wie wir sie kannten? Es war auf jeden Fall ein erstaunlich erfolgreicher Marketing-Stunt.“
  Dieser Stil interessiert mich nicht. Ich hätte lieber klares Denken und saubere Argumentation gesehen. Man sollte wohlwollend lesen.
  Ohne gute Belege und Argumente zu sagen, Glasswing sei ein „Marketing-Stunt“ gewesen, ist Spekulation. Gesunde Skepsis verstehe ich, aber gesunde Skepsis sollte sich auch nach innen richten. Worauf gründet sich diese Gewissheit?
  Und was bedeutet es überhaupt, wenn etwas ein Stunt ist? Wenn ich „Stunt“ lese, schwingt darin die Absicht mit, manipulieren zu wollen. Am direktesten über die Absicht sprechen können „die Leute, die in diesem Raum waren“. Alle anderen stellen bestenfalls Vermutungen an, aber zu viele Menschen behandeln ihre Vermutungen nicht einmal ernsthaft als Vermutungen, sondern behaupten sie wie Tatsachen.
  Wenn man nicht dabei war, ist es klüger, die eigene Schlussfolgerung zu erklären, statt apodiktisch zu urteilen.
  Die Anreize zeigen in viele Richtungen. Ich sehe das nicht naiv. Aber von jemandem, der einen ernsthaften Text schreibt, erwarte ich, dass er die Intelligenz der Leser und ihr Interesse daran respektiert, die Welt zu verstehen.
  Es kommt oft vor, dass Expertinnen und Experten aus einem Bereich mit zu viel Selbstvertrauen in einen anderen springen und Fehler machen. Worauf gründet sich die Annahme, dass ein curl-Maintainer im Allgemeinen und insbesondere in Bezug auf die Stellung des eigenen Projekts gute epistemische Maßstäbe hat? Menschen haben oft einen starken Anreiz, nicht zu wollen, dass Maschinen etwas besser können als sie selbst. Ich sage nicht, dass Mythos bereits an diesem Punkt ist. Dazu enthalte ich mich eines Urteils. Aber allein nach der Argumentation in diesem Text fällt es mir schwer, vom Autor beeindruckt zu sein.

  • Ich stimme nicht zu, dass es voreilig sei, Glasswing als Marketing-Stunt zu bezeichnen. Wenn man liest, was direkt auf den Satz „erfolgreicher Marketing-Stunt“ folgt, wirkt das auf mich wie faire Kritik.
    „Als Teil des Projekts Glasswing stellte Anthropic über die Linux Foundation auch ‚Open-Source-Projekten‘ Zugang zu aktuellen AI-Modellen zur Verfügung. Die Linux Foundation ließ diesen Teil vom Alpha-Omega-Projekt abwickeln, und deren Vertreter kontaktierten mich. Als Lead-Entwickler von curl wurde mir Zugang zu einem magischen Modell angeboten, und ich nahm das gerne an. Natürlich wollte ich sehen, was sich in curl finden ließe.“
    Mein Eindruck nach der Lektüre des gesamten Textes ist nicht, dass der Autor sagen wollte, Glasswing sei nur ein Marketing-Stunt gewesen, sondern eher, dass es als Marketing-Stunt ganz klar erfolgreich war und alles darüber hinaus noch offen ist.
    Der Rest des Textes nach dem Zitat besagt, dass da mehr war als bloßes Marketing, und kommt zu dem Schluss, es sei „immer noch sehr gut“. Die Stoßrichtung war, dass es wahrscheinlich hilfreich sein kann, auch wenn es nicht an den atemlosen Marketing-Hype heranreicht, den wir bisher gesehen haben.
  • OpenAI brachte kurz darauf im Rahmen seines regulären Upgrade-Musters eine neue Modellversion heraus und zeigte in diesem Bereich ähnliche Fähigkeiten, allerdings ohne großes Tamtam oder Aufsehen.
    Es war einfach GPT-5.5. Insofern halte ich es für möglich, dass man Mythos unter Verweis auf die angebliche Gefährlichkeit zurückgehalten hat, um die Aufmerksamkeit auf Security-Anwendungsfälle zu lenken und neue Nachfrage zu schaffen.