senn-techPatch-Gap in sechs Firefox-Releases: was die GLM-Studie wirklich belegt
Epoch AI hat am 29. Oktober 2026 eine Studie publiziert, die Betreiber einer Firefox-Fläche zu Ende lesen sollten. Das offene Gewichtsmodell GLM 5.3 hat aus publizierten, aber noch nicht ausgelieferten Sicherheitsfixes funktionierende Angriffe auf Firefox gebaut, über sechs Releases hinweg und für rund 1.000 Dollar je Version.
Der Wert der Studie liegt in der Kette, die Epoch selbst mitliefert, inklusive der Punkte gegen die eigene Headline. Diese Kette steht hier nachgerechnet, getrennt nach dem, was die Primärquelle hergibt und was nicht. Der Patch Gap ist nichts Neues; neu ist nur, wen er heute erreicht.
Was offen bleibt, sage ich offen. Epoch hat weder den Code der Harness noch den Datensatz veröffentlicht, und die vier Gegenmaßnahmen von Mozilla sind Anbietermeldungen im eigenen Blog, davon eine als Absicht formuliert. Relevant für uns ist die Update-Politik.
Was passiert, wenn eine Seite besucht wird
Der Nachweis ist ein einzelner Webseitenbesuch. Ein Benutzer öffnet die Seite, danach liest diese eine lokale Datei und schickt ihren Inhalt an den Angreifer, ohne weiteren Klick. Epoch nennt als Folge ausgelesene Passwörter, gestohlene Authentifizierungs-Cookies und eingesehene private Dateien. Firefox steht laut der Studie bei über 200 Millionen aktiven Nutzern.
Zwei Grenzen gehören zu diesem Befund, und beide stammen von Epoch selbst. Erstens gibt es keinen Codeausführungserfolg auf jungen Firefox-Releases; der Bericht hält das wörtlich als Stand zum Zeitpunkt des Schreibens fest. Der Demonstrationsschaden ist gelesener Dateiinhalt. Zweitens brauchte jede erfolgreiche Attacke eine zweite, unveröffentlichte Schwachstelle, einen Sandbox-Bypass. Ohne ihn schlägt der Angriff fehl. Diese Lücke hat Epoch gemeldet, geschlossen ist sie in Firefox 159.0 vom 27. Oktober 2026.
| Baustein | Was er leistet | Status |
|---|---|---|
| Patch-Gap-Lücke, aus publizierten Fixes abgeleitet | Codeausführung im Web-Content-Prozess | über sechs Releases wirksam, von Epoch abgeleitet |
| Unveröffentlichte Lücke, von GLM 5.3 je Versuch erneut gefunden | Umgehung der Sandbox, damit der Prozess überhaupt an Dateien kommt | an Mozilla gemeldet, Fix in Firefox 159.0 am 27.10.2026 |
Die zweite Zeile erklärt die Strategie, die Mozilla kurz darauf beschrieben hat, und sie ist der Grund, warum ich die sechs Releases nicht als "Firefox ist sechs Wochen lang angreifbar" lesen würde.
Die zwei Kostenzahlen, die oft verwechselt werden
Rund 1.000 Dollar sind die marginalen Rechenkosten je erfolgreicher Version, und zwar erst nach Aufbau der Umgebung. Die Gesamtausgaben für Firefox beziffert Epoch mit über 100.000 Dollar, die Chrome-Versuche mit noch einmal etwa 100.000 Dollar, ohne den gleichen Erfolg.
Das Verhältnis 1 zu 100 aus manchen Überschriften gilt nur gegen die Randkosten je Version. Teilt man die Gesamtausgaben von über 100.000 Dollar auf die sechs Versionen, sind es mehr als 16.000 Dollar je Version. Dazu gehört Epochs eigene Einordnung: Die Nichterfolge gegen Chrome gelten der Gruppe ausdrücklich nicht als Beleg, dass solche Angriffe dort nicht gelingen würden.
Epoch misst eine harte Grenze von 48 Stunden pro Versuch; der schnellste erfolgreiche Ansatz brauchte 12 Stunden, ohne menschlichen Input nach dem Startauftrag.
Was die Gegenmaßnahme schon konnte und was nicht
Firefox verschleiert publizte Sicherheitsfixes als normale Verbesserungen. Die Studie hält fest, dass GLM 5.3 diese Tarnung überwunden hat: Das Modell las den Code und entschied, welche Änderungen Sicherheitspatches waren. Der Mechanismus funktioniert weiter, nur mit mehr Aufwand auf beiden Seiten.
Epoch veröffentlicht weder Code noch Datensatz, die bibliographische Angabe führt als URL nur die Publikationsseite. Damit lässt sich die Zahl der sechs Releases nicht unabhängig nachfahren. Die Zeitachse lässt sich nachfahren, und die habe ich am 1. November 2026 selbst gemessen.
Die beiden Debian-Zeilen sind die unangenehmsten in dieser Grafik, weil sie eine Distribution betreffen, die im eigenen Haus steht. Die ESR-Linie ist der Grund, warum ich die 14-Tage-Kadenz nicht auf Workspace-Rechner rechne.
Die Kadenz, gemessen statt erzählt
Am 1. November 2026 zeigt die Maschinendatei firefox_versions.json von product-details.mozilla.org LATEST_FIREFOX_VERSION 159.0, FIREFOX_ESR 153.6.0esr, FIREFOX_ESR115 115.44.0esr, dazu LAST_RELEASE_DATE 27.10.2026 und NEXT_RELEASE_DATE 06.11.2026. Die Release-Notes liefern die Daten 18. August, 1., 15. und 29. September sowie 13. und 27. Oktober. Die Hauptversionen 155.0 bis 159.0 erscheinen alle 14 Tage, die Punktversionen 156.0.1, 157.0.1 und 158.0.1 sieben Tage nach ihrer Hauptversion (22. September, 6. und 20. Oktober).
Zwischen 156.0 am 15. September und 159.0 am 27. Oktober liegen 42 Tage, meine eigene Differenz aus den zwei Release-Daten. Epochs Zeitfenster vom 17. September bis 26. Oktober sind 39 Tage: Es beginnt zwei Tage nach 156.0 und endet einen Tag vor 159.0.
Für den Betrieb mit Gruppenrichtlinie ist die ESR-Linie der reale Fall, und die hängt hinterher. Im gemessenen Stand läuft die Hauptlinie auf 159.0, die ESR-Linie auf 153.6.0esr. Auf dem Debian-Zweig kam das erste firefox-esr-Sicherheitspaket für Debian 13 laut Meldung am 3. Oktober 2026. Die drei Publizierungen 153.5.0, 153.5.1 und 153.6.0 vom 13., 20. und 27. Oktober landeten gemeinsam in einer einzigen Meldung, DSA-6590-1 vom 28. Oktober. Wer an der Distribution hängt, erbt deren Rhythmus.
Dazu eine Zählweise, die man kennen sollte, bevor jemand "167 Fixes" als Explosion liest: Mozilla zählt nicht mehr mit einem Sammel-CVE für Speicherprobleme. Die Meldung zu Firefox 159.0 führt 167 CVEs, davon 108 hoch eingestuft. Die Zählweise hat sich also mitgeändert.
Was Mozilla dagegen tut, und was davon hält
Mozilla hat am selben Tag im eigenen Blog geantwortet und vier Maßnahmen beschrieben. Die Hauptlinie ist auf wöchentliche Auslieferung umgestellt, die Durchlaufzeit also etwa halbiert. Regressionstests bleiben bis nach dem Ausliefern des Fixes unter Verschluss; ohne sie sei GLM 5.3 deutlich weniger leistungsfähig. Jeder neue Commit wird gescannt. Und die Zeitfenster von Renderer-Fixes und Sandbox-Fixes sollen getrennt werden, damit beide Bausteine eines Angriffs nie im selben Fenster liegen.
Die letzte Maßnahme ist die interessanteste, weil sie an der zweiten Zeile der Kette ansetzt, aber eine Absichtserklärung; Mozilla schreibt, man werde diesen Ansatz anwenden. Ebenso sind die übrigen drei Punkte Anbietermeldungen einer Gegenpartei, die ihre Erfolgsaussicht selbst beschreibt: mehr als siebenfach so viele Sicherheitskorrekturen wie im Vergleichszeitraum 2025, Angreifermodelle einige Generationen zurück, ein endlicher Vorrat an Lücken. Eine unabhängige Messung davon kenne ich nicht.
Was an Skepsis im Umlauf ist, hält einer Prüfung nicht stand. Die Diskussion auf Hacker News, 13 Punkte und 9 Kommentare, enthält keinen methodischen Einwand; ein Mozilla-Mitarbeiter diskutiert die Begrenzungen, bestreitet aber kein Ergebnis. Die schärfsten Vorbehalte stehen in der Studie selbst.
Was wir gemessen haben und was daraus folgt
Eine Firefox-Zahl aus unserer Flotte nennen wir hier nicht, wir haben sie für diesen Beitrag nicht belegt gemessen. Was wir an einem eigenen Stack regelmäßig durchspielen, ist der Ablauf von der Meldung bis zum ausgerollten Stand, etwa beim PHP-Patch-Tag oder beim LiteLLM-Schadcode. Unser Ertrag aus dieser Studie ist eine Regel für eigene Policies.
Der Browser-Client zählt wie ein Server
Der Nachweis dieser Studie braucht keinen Exploit gegen den Server-Eingang, nur einen Seitenbesuch. Ein Browser im Firmen-Notebook ist wie ein Dienst zu führen: mit Auslieferungsdatum, Zuständigkeit und Frist.
Kurze Kadenz nur, wenn sie ausgerollt wird
Die halbierte Durchlaufzeit beim Hersteller verpufft, wenn die Distribution oder ein Gruppenrichtlinien-Zweig den Rhythmus nicht mitmacht. Den Abstand haben wir an den zwei Debian-Zeilen oben gemessen.
Zwei Bausteine statt einem Schalter
Wo ein Angriff einen Renderer-Fehler und einen Sandbox-Ausbruch braucht, ist ein Zweig, der beide fängt, ein starker Hebel. Wer Sandboxes auf Clients betreibt, hält sie auf dem aktuellen Stand.
Zählung und Methodik zusammen lesen
Eine Zahl wie 167 CVEs ist ohne die Zählweise eine Methodenänderung, kein Zustand. Das gilt für eigene Reports genauso.
Weiterführende Quellen
- epoch.ai/publications/open-weight-models-patch-gap
- epochai.substack.com/p/glm-patch-gap-exploit-firefox
- blog.mozilla.org/en/firefox/privacy-security/defending-patch-gap
- product-details.mozilla.org/1.0/firefox.json
- lwn.net/Articles/1100702
- lwn.net/Articles/1103614
- mozilla.org/en-US/firefox/153.0/releasenotes
- ubuntu.com/security/notices/USN-8501-1
- anthropic.com/research/n-days
- proofpoint.com/us/blog/threat-insight
- news.ycombinator.com/item
Was ist der Patch Gap?+
Die Zeit zwischen Veröffentlichung eines Sicherheitsfixes und seiner Auslieferung. Bei Open-Source-Projekten liegt der Quelltext offen, aus einer Änderung lässt sich ableiten, was vorher angreifbar war. Die Studie zeigt, dass ein offenes Gewichtsmodell diese Ableitung selbst leistet.
Wie lange war Firefox betroffen?+
Sechs Releases zwischen dem 17. September und dem 26. Oktober 2026, mit der Einschränkung, dass jede Attacke zusätzlich eine unveröffentlichte Sandbox-Schwachstelle brauchte. Diese hat Mozilla in Firefox 159.0 am 27. Oktober geschlossen.
Müssen wir Firefox jetzt aus dem Bestand nehmen?+
Dafür sehe ich nach dieser Studienlage keinen Grund, eine Empfehlung in diese Richtung wäre überzogen. Der demonstrierte Schaden ist ein Datei-Lesevorgang nach einem Seitenbesuch. Wer Firefox oder ESR betreibt, hält den Stand und führt den Browser wie einen Dienst mit Auslieferungsdatum und Frist.