KI-Exploits im Firefox-Patch-Gap: Was Epoch AI zeigt

Ein Sicherheitsfix kann öffentlich sichtbar sein, während die reguläre Browser-Version ihn noch nicht enthält. Genau dieses Zeitfenster hat Epoch AI mit einem KI-Modell untersucht. Der am 29. Oktober 2026 veröffentlichte Bericht zeigt erfolgreiche Dateizugriffe über sechs damalige Firefox-Releases.

Für die heutige Einordnung ist eine zweite Information entscheidend: Die Versuche benötigten zusätzlich eine zuvor unveröffentlichte Schwachstelle. Laut Epoch wurde sie mit Firefox 159 vom 27. Oktober geschlossen. Die Untersuchung belegt deshalb weder eine aktuelle Angriffswelle noch, dass jede heute eingesetzte Firefox-Version auf dieselbe Weise angreifbar ist. Redaktionsstand: 30. Oktober 2026.

Das Wichtigste

• Untersucht wurde die Strecke vom öffentlich sichtbaren Fix bis zur allgemeinen Veröffentlichung eines Updates.
• Der demonstrierte Schaden war das Auslesen und Übertragen einer lokalen Datei beim Besuch einer präparierten Webseite.
• Der zusätzliche, damals unveröffentlichte Baustein der Angriffskette ist laut Forschern inzwischen gepatcht.
• Rund 1.000 US-Dollar bezeichnen marginale API-Kosten nach dem Aufbau der Versuchsumgebung; das Firefox-Forschungsbudget lag über 100.000 US-Dollar.

Die Lücke liegt schon vor dem regulären Update

Der Epoch-Bericht untersucht einen bestimmten Teil des sogenannten Patch Gap: Eine Korrektur lässt sich bereits in öffentlichen Entwicklungsständen erkennen, ist aber noch nicht in der allgemein verfügbaren Produktversion angekommen. Angreifer können die Änderung als Hinweis darauf lesen, wo die bisherige Version verwundbar ist.

Davon zu unterscheiden ist die spätere Zeit zwischen Veröffentlichung eines Updates und seiner tatsächlichen Nutzung auf einem Endgerät. Beide Zeiträume können relevant sein, haben aber unterschiedliche Verantwortliche und Gegenmaßnahmen.

Diese Trennung verhindert einen häufigen Denkfehler: Eine veröffentlichte Korrektur ist ein Fortschritt im Entwicklungsprozess. Ihre Schutzwirkung für ein bestimmtes System muss separat festgestellt werden.

Was das Modell tatsächlich erreichte

Epoch nutzte GLM 5.3, ein Modell mit öffentlich verfügbaren Gewichten. Die Forscher stellten eine isolierte Umgebung und Informationen bereit, die zum Veröffentlichungszeitpunkt der jeweiligen Zielversion bereits verfügbar waren. Das Modell hatte dabei keinen Internetzugang.

Die sechs untersuchten Releases aus dem Zeitraum 17. September bis 26. Oktober waren 156.0, 156.0.1, 157.0, 157.0.1, 158.0 und 158.0.1. Getestet wurde laut Bericht auf Ubuntu 26.04 mit Standardeinstellungen und offiziell bezogenem Firefox. Nach der Vorbereitung entwickelte das Modell selbstständig Angriffsketten, bei denen ein Webseitenbesuch zum Auslesen und Übertragen einer lokalen Datei führte.

Das ist ein kontrollierter Forschungsnachweis. Daraus folgt keine Statistik über tatsächlich angegriffene Nutzer, Windows-Installationen, alle Browser oder beliebige Unternehmensumgebungen. Eine darüber hinausgehende beliebige Codeausführung auf dem Rechner gelang bei jüngeren Firefox-Releases laut Bericht nicht. Auch die Chrome-Versuche ergaben bis zum Berichtszeitpunkt keinen gleichwertigen Exploit.

Das negative Chrome-Ergebnis ist seinerseits keine Sicherheitsgarantie. Es beschreibt die getestete Versuchsanordnung und die bis dahin erzielten Ergebnisse.

Firefox 159 verändert den untersuchten Stand

Die erfolgreiche Kette beruhte nicht ausschließlich auf öffentlich erkennbaren Fixes. Für den Zugriff auf Dateien außerhalb der normalerweise wirksamen Browser-Isolation war eine weitere, damals unveröffentlichte Lücke erforderlich. Epoch meldete sie an Mozilla und berichtet über ihre Behebung mit Firefox 159.

Die Mozilla-Release-Notes datieren dessen allgemeine Veröffentlichung auf den 27. Oktober 2026. Das Sicherheitsadvisory MFSA 2026-118 dokumentiert die in Firefox 159 behobenen Sicherheitsprobleme. Eine eindeutige Zuordnung des Epoch-Befunds zu einer bestimmten dort gelisteten CVE nehmen wir daraus nicht vor.

Epoch hatte zum Veröffentlichungszeitpunkt noch nicht bestätigt, ob eine vergleichbare Kette gegen Version 159 gelingt. Die Aussage „alle aktuellen Firefox-Versionen lassen sich für 1.000 Dollar übernehmen“ wäre deshalb fachlich falsch. Ebenso wäre „mit diesem Update sind sämtliche denkbaren Patch-Gap-Angriffe ausgeschlossen“ durch die Quellen nicht gedeckt.

Warum die Kostenangabe einen Kontext braucht

Die rund 1.000 US-Dollar beziehen sich auf zusätzliche API-Kosten je erfolgreich angegriffener Firefox-Version, nachdem die Forscher ihre Umgebung aufgebaut und den Ansatz entwickelt hatten. Die gesamten Firefox-API-Ausgaben einschließlich Vorbereitung und Vorversuchen lagen über 100.000 US-Dollar.

Die kleinere Zahl ist damit ein Hinweis auf die Kosten weiterer Versuche unter den geschaffenen Bedingungen. Sie ist kein vollständiges Projektbudget und kein universeller Preis für einen erfolgreichen Angriff. Umgekehrt verschwindet die Bedeutung des Ergebnisses nicht dadurch, dass der Aufbau aufwendig war: Ein einmal etablierter Ablauf kann wiederholt genutzt werden. Wie leicht andere Akteure ihn reproduzieren können, wurde damit nicht umfassend gemessen.

Unsere Einordnung: drei Zustände statt eines grünen Patch-Tickets

Für IT-Verantwortliche zeigt die Untersuchung, warum der Status „Patch vorhanden“ allein wenig über ein konkretes Restrisiko aussagt. Ein Entwicklerteam kann eine Korrektur fertig haben, der Hersteller kann sie ausliefern, und ein Unternehmen kann sie bereits verteilt haben. Das sind drei verschiedene Aussagen.

Auf Herstellerseite entsteht eine Abwägung zwischen überprüfbaren Änderungen, ausreichenden Tests und zügiger Auslieferung. Eine schnellere Freigabe darf die betriebliche Qualität nicht beliebig ersetzen. Die Studie begründet auch keine pauschale Forderung, Quellcode zu schließen oder offene Entwicklungsprozesse aufzugeben.

Auf Betreiberseite hilft eine präzise Abschlussbedingung. Wenn ein Browser-Update als erledigt gilt, sollte klar sein, ob damit die Freigabe des Pakets, eine erfolgreiche Verteilung oder die tatsächlich verwendete Version gemeint ist. Mozilla weist für direkt bezogene Firefox-Installationen darauf hin, dass Updates nach einem Neustart angewendet werden. Linux-Paketverwaltung und Microsoft Store haben eigene Verteilungswege. Ein verfügbarer Download beantwortet die Betriebsfrage daher nur teilweise.

Bei einer Ausnahme gehört der betroffene Bestand zum Vorgang: Welche Geräte oder Dienste sind noch offen, wer verantwortet die Entscheidung und wann wird erneut geprüft? Eine Ausnahme ohne Bezug zum konkreten System lässt sich später schwer von einer vergessenen Aufgabe unterscheiden. Ein begründeter Aufschub braucht außerdem ein überprüfbares Ende.

Auch die Herkunft der Erkenntnis sollte erhalten bleiben. Ein Hersteller-Advisory, eine nachgewiesene Ausnutzung im Forschungsaufbau und ein bestätigter Zugriff im eigenen Unternehmen lösen unterschiedliche Arbeit aus. Diese Differenzierung ist ebenso wichtig wie beim testmetest-Fund in präparierten GitHub-Repositories: Ein technischer Befund ist ein Ausgangspunkt für die eigene Eingrenzung, keine fertige Opferstatistik.

Kopexa kann betroffene Assets mit Risiken, Maßnahmen, Verantwortlichen und Prüfnachweisen verbinden. Die Softwareverteilung und technische Versionsprüfung erfolgen weiterhin mit den dafür eingesetzten Betriebswerkzeugen. Entscheidend ist, dass die verantwortlichen Teams den offenen Bestand, Ausnahmen und die Abschlussprüfung gemeinsam nachvollziehen können.

Die neue Erkenntnis aus dem Epoch-Bericht liegt im Zusammenspiel von sichtbaren Korrekturen und automatisierter Analyse. Für Unternehmen bleibt daraus eine konkrete Führungsaufgabe: Zwischen „Fix bekannt“ und „Schutz am System geprüft“ darf kein unklarer Status verschwinden.