Ein klügerer Auditor findet mehr Bugs. Das ändert nichts daran, dass der Renderer ein 35-Millionen-Zeilen-Parser feindseliger Bytes bleibt. Die richtige Reaktion auf Mythos ist weder Erleichterung noch Schrecken — sondern weiter so zu entwerfen, als wäre der nächste Bug derjenige, der durchkommt.

Am 21. April hat Mozilla einen Beitrag veröffentlicht mit dem Titel „The zero-days are numbered" („Die Zero-Days sind gezählt"). Darin bestätigt die Foundation, dass Firefox 150 mit 271 Sicherheits-Fixes ausgeliefert wurde, die bei der Evaluierung einer frühen Version von Anthropics Claude Mythos entdeckt wurden – einem Grenzmodell, das auf Schwachstellenforschung abgestimmt ist und über ein kontrolliertes Partnerprogramm namens Project Glasswing verteilt wird. Ein früheres Firefox-Release, Version 148, hatte bereits 22 Bugs enthalten, die von Claude Opus 4.6 gefunden worden waren. Der Sprung von 22 auf 271 in einem einzigen Versionszyklus ist genau die Art von Zahl, bei der Menschen zu Superlativen greifen.

Mozilla hat das – anerkennenswerterweise – nicht getan. CTO Bobby Holley sagte The Register, dass die Ergebnisse seinem Team „Schwindel" bereiteten und die Frage aufwarfen, ob es „überhaupt möglich ist, Schritt zu halten". Aber er kombinierte das mit einem nüchternen Satz, der leicht zu überlesen und sehr wichtig ist: „Ermutigend ist, dass wir auch keine Bugs gesehen haben, die nicht ein Elite-Researcher hätte finden können."

Dieser Satz ist die ganze Geschichte und die ganze These dieses Beitrags.

Was die Ankündigung tatsächlich sagt

Zieht man die Schlagzeilen ab, meldet Mozilla drei Dinge.

Erstens: Eine Maschine kann jetzt in industrieller Taktung leisten, was eine kleine Zahl von Elite-Menschen bereits in menschlicher Taktung leisten konnte. Der Blog formuliert es direkt: „keine Kategorie und keine Komplexität einer Schwachstelle, die Menschen finden können, bleibt diesem Modell verschlossen." Das ist eine Fähigkeitsaussage. Sie ist keine Revolution darüber, was findbar ist; sie ist eine Revolution darüber, wie schnell das Findbare gefunden wird.

Zweitens: Es besteht die reale Möglichkeit, dass Bug-Komplexität die Entdeckungsfähigkeit überholt, sobald KI-Werkzeuge auch durch die Entwicklungs-Pipeline diffundieren. Mozillas eigene Formulierung: „Es besteht das Risiko, dass Codebasen beginnen, das menschliche Begreifen zu übersteigen, weil mehr KI in den Entwicklungsprozess einfließt." Menschliche Nachvollziehbarkeit sei, so der Beitrag, selbst eine Sicherheitseigenschaft.

Drittens – jenes, auf das alle projizieren werden – ist Mozilla optimistisch. „Licht am Ende des Tunnels", sagte Holley. „Verteidiger haben endlich die Chance zu gewinnen, und zwar entscheidend."

Wir halten die erste Aussage für richtig, die zweite für weit aufmerksamkeitsbedürftiger, als sie Aufmerksamkeit bekommen wird, und die dritte für richtig in Bezug auf das Auditing-Wettrüsten und falsch in Bezug darauf, was dieses Wettrüsten tatsächlich löst.

Die letzten beiden Firefox-Releases, mit und ohne maschinengestütztes Auditing. Die 22 Bugs in Firefox 148 wurden einem früheren Claude-Modell zugeschrieben; die 271 Bugs in Firefox 150 stammen aus der Evaluierung eines frühen Mythos. Mozilla betont, dass keiner der 271 ein Bug war, den ein Elite-Researcher nicht hätte finden können – nur dass sie schneller gefunden wurden.

Die guten Nachrichten, schlicht gesagt

Es wäre unehrlich, die guten Nachrichten zu vergraben, also hier: Ein Werkzeug, das die Kapazität von Elite-Schwachstellenforschung in etwas verwandelt, das mit GPU-Stunden skaliert, gehört zu den nützlichsten Dingen, die der Browser-Sicherheit in einem Jahrzehnt passiert sind. Ein Sprung von 22 auf 271 über genau einen Versionszyklus, gegen eine Codebasis von einigen Millionen Zeilen C++, ist die Art Signal, das andere Browser-Hersteller ernst nehmen werden. Chromium-Engineers werden. WebKit-Engineers werden. Die Teams, die libxml2, ICU, HarfBuzz, libwebp und die hundert weiteren Parser pflegen, die jeder Browser mitbringt, werden es – wenn sie die Zeit bekommen.

Mehr vor Release behobene Bugs ist schlicht besser als weniger vor Release behobene Bugs. Alle 271 waren interne Funde, niemandem vor dem Patch offengelegt, ohne Hinweis darauf, dass einer von ihnen in freier Wildbahn ausgenutzt worden wäre. In der alten Formulierung der Sicherheitsforschung waren das wandelnde Tote. Mozilla hat sie erlegt, bevor sie jemandem etwas kosten konnten.

Also: echter Fortschritt. Echter Kredit für Mozilla, dass sie das Volumen offen bekannt gegeben haben, statt es still zu begraben. Echter Kredit für Anthropic, dass sie Mythos hinter einem Partnerprogramm halten, statt es allen, die sich ein Abo leisten können, allgemein verfügbar zu machen.

Und dann die härtere Frage

Wenn der Effekt erster Ordnung lautet „viel mehr Bugs werden vor dem Ausliefern behoben", dann lautet der Effekt zweiter Ordnung „dieselbe Fähigkeit steht jetzt jedem anderen zur Verfügung, dem Anthropic Zugang gewährt, und eine ungefähr gleichwertige Fähigkeit wird innerhalb weniger Quartale allen zur Verfügung stehen". Dieser zweite Effekt ist das, was der vorhergehende Beitrag, Warum Browser-Zero-Days nicht verschwinden, im Detail darzulegen versucht hat. Wir führen diese Debatte hier nicht neu. Das heute Relevante an jenem Argument ist dies: Ein Browser ist das größte einzelne Stück Parse-Maschinerie für nicht vertrauenswürdige Inhalte auf Ihrem Computer, und die Ökonomie des Bug-Findens in solcher Maschinerie verschiebt sich gerade unter allen gleichzeitig.

Mozilla hat recht: Ein gut ausgestatteter Verteidiger hat jetzt bessere Werkzeuge. Ein gut ausgestatteter Angreifer auch. Die Frage ist, was das mit den Zahlen macht, die ein Nutzer tatsächlich interessieren – nicht Bugs, die pro Release behoben werden, sondern Bugs, die als funktionierender Exploit in jemandes Posteingang enden.

Was ein Auditor mit Maschinengeschwindigkeit verändert – und was nicht. Auditing beschleunigt sich auf beiden Seiten der Linie. Die Form der Browser-Angriffsfläche und die Folgen einer einzelnen erfolgreichen Kompromittierung bewegen sich nicht.

Die linke Spalte ist der Ort, an dem Mythos lebt. Auditing – auf beiden Seiten – beschleunigt sich. Diese Beschleunigung ist asymmetrisch nützlich für Verteidiger dann, wenn sie es sind, die das Werkzeug zuerst fahren, wie Mozilla es getan hat, wie Chromium es vermutlich tut und wie die Hunderte kleinerer Browser und browserbasierter Apps es weitgehend nicht tun. Die Beschleunigungen der rechten Spalte existieren nicht. Kein noch so gründliches Auditing macht aus einem monolithischen In-Process-Renderer einen nicht monolithischen. Kein noch so gründliches Auditing trennt den Renderer vom Schlüsselbund, Dateisystem, der Webcam, dem Netzwerk-Stack. Die Form des Problems ist unverändert.

Die Haltung, die weiter Sinn ergibt

Mozilla beendet den Beitrag mit einer vernünftigen Hoffnung – dass wir menschliche Nachvollziehbarkeit als erstrangige Sicherheitseigenschaft des Browsers erhalten können, während wir trotzdem maschinelle Hilfe beim Auffinden von Bugs einsetzen. Diese Hoffnung teilen wir. Sie ist nicht die Hoffnung, auf der dieser Blog gebaut ist.

Die Haltung, um die herum Bromure gebaut wurde, sagt nicht voraus, wie viele Bugs im Renderer stecken. Sie sagt voraus, dass es stets mindestens einen Bug im Renderer gibt, den niemand gefunden hat – manchmal kommen Verteidiger zuerst an ihn heran, manchmal Angreifer – und dass die Architektur um den Renderer herum diese Unsicherheit überlebbar machen muss.

Das ist keine Argumentation eines Browserherstellers. Es ist eine Wahl des Bedrohungsmodells. Ein Renderer, den Mythos auditiert hat, bleibt ein Renderer, der C++ gegen feindseligen Input ausführt. Das nächste Paper zu speichersicheren Toolchains, die nächste Fuzzer-Generation, das nächste Mythos werden nicht ändern, was auf einem Computer passiert, wenn ein Renderer heute kompromittiert wird, in der Version von Chrome, Safari oder Firefox, die bereits auf den Laptops der Leute liegt.

Zwei Verteidigungen gegen einen Renderer-Bug. Die eine hängt davon ab, dass der Auditor den Bug zuerst erreicht. Die andere hängt von der Architektur um den Bug herum ab – unabhängig davon, wer ihn fand.

Beide Diagramme sind echte Verteidigungen. Das linke ist dasjenige, in das die gesamte Browserbranche seit zwanzig Jahren investiert und das jetzt mit Mythos beschleunigt. Es wird tatsächlich besser. Es ist aber auch – strukturell – eine Verteidigung, die davon abhängt, dass der Hersteller das Rennen vor dem Angreifer beendet. Wenn sich dieses Rennen von Monaten auf Stunden komprimiert, wie es geschieht, verengt sich die Verteidigung auf die Frage, ob Ihr Gerät im Fenster zufällig aktualisiert wurde. Dieses Fenster schrumpft für beide Seiten gleichzeitig.

Das rechte ist architektonisch. Es kümmert sich nicht darum, ob der Bug von Mozilla, von Anthropic, von derselben Angreifergruppe, die 2025 die Operation ForumTroll fuhr, oder noch von niemandem gefunden wurde. Es stellt eine andere Frage: Wenn ein Renderer-Bug feuert, was bedeutet „feuert" in Bezug auf das, was der Angreifer tatsächlich anfasst?

Was Bromure tatsächlich tut, in einem Atemzug gesagt

Jeder Tab läuft in einer Wegwerf-Linux-VM auf Apple Silicon. Der Renderer – V8, Blink, der WebP-Decoder, Dawn, jeder einzelne Parser, in dem ein Auditor der Mythos-Klasse Bugs findet – läuft in diesem Gast, niemals auf dem Host. Wenn eine Renderer-Kompromittierung feuert, ist der Angreifer im Gast. Der Gast enthält nicht Ihren Dokumente-Ordner, Ihren Schlüsselbund, Ihr iCloud Drive, Ihr lokales Netzwerk, Ihre Kamera oder Ihr Mikrofon. Er enthält einen Browser, ein Profil und den Zustand, den dieses Profil angesammelt hat. Wenn das Fenster geschlossen wird, wird der Gast zerstört. Jede Browser-Sitzung, die startet, startet sauber.

Das ist keine Behauptung, dass Renderer-Bugs keine Rolle spielen. Sie tun es. Passwörter, die in einen kompromittierten Tab getippt werden, werden weiterhin in diesen Tab getippt. Cookies, die einem kompromittierten Profil gehören, sind weiterhin durch eine Kompromittierung dieses Profils erreichbar. Eingaben, die der Sitzung im Exploit-Fenster übergeben wurden, sind im Zugriff. Was nicht im Zugriff ist, weil es nicht in derselben VM ist, ist der Rest des Computers – und der Rest des Computers ist der Ort, an dem Persistenz, laterale Bewegung und der größte Teil des tatsächlichen Schadens leben.

Zwei Dinge, die dieser Beitrag nicht sagt

Beim Lesen des Obigen wären zwei Fehler leicht zu machen. Wir wollen beiden zuvorkommen.

Nicht: „unser Renderer ist besser“

Bromure setzt auf Chromium-Upstream. Die Parser, die Mythos in Firefox auditiert hat, haben Analoge in jedem Chromium-basierten Browser, Bromure eingeschlossen. Wir behaupten nicht, dass unser Renderer weniger Bugs hat als irgendein anderer. Wir behaupten, dass unsere Haltung nicht davon abhängt, dass unser Renderer weniger Bugs hat.

Nicht: „KI-Auditing ist eigentlich schlecht“

Tooling der Mythos-Klasse ist ein klarer Netto-Gewinn für Verteidiger – wenn jeder Browser und jeder gebündelte Drittanbieter-Parser mit dieser Kadenz auditiert wird, wird die Welt sicherer. Unser Punkt ist enger: Diese Art Fortschritt hebt die Obergrenze der Renderer-Qualität; sie ändert nichts an der Design-Frage, was zu tun ist, wenn der Renderer trotzdem ausgenutzt wird. Auf diese Frage wurde Bromure gebaut, um zu antworten.

Worauf als Nächstes zu achten ist

Die ehrliche Lesart von Mozillas Ankündigung lautet: Das ist der Auftakt eines langen Gesprächs. Es gibt mindestens drei Dinge, die in den nächsten Quartalen wichtig werden.

Erstens, ob Chromium und WebKit ähnliche Funde-Volumen bestätigen, wenn ihre eigenen Mythos-gestützten Audits ausgeliefert werden. Die Firefox-Zahlen sind markant; das branchenweite Bild ist noch unscharf. Zweitens, ob dasselbe Tooling nach der Offenlegung auch in Angreiferhand auftaucht. Mozilla ist vorsichtig und beansprucht nicht, dass die 271 Bugs ausnutzbare Zero-Days gewesen wären; es waren Fixes. Die Frage ist, wie dieselbe Werkzeugklasse aussieht, wenn sie am Morgen nach dem nächsten Stable-Release auf Chrome gerichtet wird, von jemandem, der nicht patcht.

Drittens, und das ist Mozillas eigene Sorge, ob das Zusammenspiel von KI-gestützter Entwicklung und KI-gestütztem Auditing netto zu mehr oder zu weniger Nachvollziehbarkeit führt. Eine Codebasis, die nur ein Modell auditieren kann, ist eine Codebasis, deren Sicherheit vom fortlaufenden Zugang zu Modellen abhängt. Das ist ein anderer Ausfallmodus als der, mit dem wir zwanzig Jahre gelebt haben, und kein offensichtlich besserer.

Für unseren Teil werden wir weiter darüber schreiben, wie sich das entwickelt. Und wir werden weiter dieselbe Design-Wette platzieren: dass eine Wegwerf-VM pro Tab das schlimmste Ergebnis eines Browser-Bugs zu einer Sitzung macht, die Sie neu starten müssen – und nicht zu einem Computer, den Sie neu aufbauen müssen. Diese Wette wird nicht schlechter, wenn Renderer besser werden. Sie wird, im engsten nützlichen Sinn, etwas redundanter – ein Problem, das wir sehr gern hätten.

Installieren Sie Bromure. Halten Sie auch Ihren anderen Browser aktuell. Und wenn die nächste Schlagzeile lautet „KI-gestützter Audit findet Hunderte Schwachstellen in [Produkt]" – und sie wird es dieses Jahr viele Male – lesen Sie sie als das, was sie ist: ein Beleg, dass die Decke sich nach oben bewegt, und nicht, dass der Boden sich verändert hat.