Im März 2025 veröffentlichte Google ein Chrome-Update für CVE-2025-2783 und meldete, dass die Lücke bereits ausgenutzt wurde. Laut Sicherheitshinweis wurde unter nicht näher beschriebenen Umständen auf Windows ein falsches Handle übergeben. Über den Angriff selbst ist öffentlich nur wenig bekannt. Der Chrome-Sicherheitshinweis zeigt, warum ein rasches Update wichtig ist, auch wenn die vollständige Angriffskette nicht veröffentlicht wurde.
Ein Zero-Day ist eine Schwachstelle, die ausgenutzt wird, bevor ein öffentlicher Patch verfügbar ist. Das bedeutet nicht, dass jeder Browser und alle Nutzenden betroffen sind: Version, Plattform, Einstellungen und Angriffsweg spielen eine Rolle. Updates schliessen bekannte Lücken. Bis ein Fix erscheint, können Schutzfunktionen des Browsers und ein vorsichtiger Umgang mit riskanten Inhalten die Gefährdung verringern.
Was ein Zero-Day ist

Stell dir eine Tür mit einem defekten Schloss vor. Jemand entdeckt den Fehler, bevor die Eigentümer einen Ersatz einbauen können. In der IT-Sicherheit bezeichnet Zero-Day eine Schwachstelle, die Angreifer ausnutzen, bevor ein Patch öffentlich verfügbar ist. Der Hersteller kann den Fehler bereits kennen oder noch nichts davon wissen. Wird eine Lücke nach Veröffentlichung eines Patches ausgenutzt, spricht man meist von einem N-Day.
Browser verarbeiten komplexe, nicht vertrauenswürdige Webinhalte. Mehrere Schutzebenen sollen Fehler begrenzen. Eine Lücke im Renderer ist ernst, gibt Angreifern aber nicht automatisch Kontrolle über das Betriebssystem. Je nach Browser, Plattform und Ziel benötigen sie zusätzlich einen Ausbruch aus der Sandbox oder höhere Rechte. Die Chromium-Dokumentation zur Website-Isolation beschreibt eine Schutzebene, die einen kompromittierten Renderer einschränkt.
Bei einem Zero-Day können Verteidiger noch keinen Fix für genau diese Lücke installieren. Unsichtbar ist ein Angriff deshalb nicht zwangsläufig: Verhaltensanalysen, Website-Isolation, Sandboxing und Untersuchungen können ihn erkennen oder einschränken. Angreifer brauchen zudem einen Weg zu einem betroffenen System, etwa über eine bösartige Seite oder präparierte Inhalte.
Der Lebenszyklus eines Zero-Days
Diese vereinfachte Abfolge unterscheidet eine noch ungepatchte Lücke von einer, die auch nach Veröffentlichung eines Fixes gefährlich bleibt.
- 1
Entdeckung
Forschende, der Hersteller oder Angreifer entdecken eine Schwachstelle. Sie kann vertraulich gemeldet, bei einer Untersuchung gefunden oder geheim gehalten werden. Dafür gibt es keinen festen Zeitplan. - 2
Entwicklung eines Exploits
Angreifer ermitteln, wie sich die Lücke in einer Zielumgebung auslösen lässt. Manchmal genügt ein Fehler; andere Angriffe verbinden einen Renderer-Fehler mit einem Sandbox-Ausbruch oder einer weiteren Schwachstelle. Eine vollständige Übernahme des Geräts folgt daraus nicht automatisch. - 3
Ausnutzung in freier Wildbahn
Eine bösartige Seite, eine kompromittierte Website oder ein gezielt verschickter Link kann den Angriff ausliefern. Für den konkreten Exploit fehlt womöglich eine Signatur. Schutzfunktionen des Browsers und verhaltensbasierte Sicherheitstools können trotzdem Teile des Angriffs blockieren oder sichtbar machen. - 4
Patch und Offenlegung
Der Hersteller untersucht die Lücke, entwickelt einen Fix und veröffentlicht einen Sicherheitshinweis. Wann die Lücke bekannt wird und wann Updates installiert werden, variiert. Sobald ein Patch verfügbar ist, schliesst seine zeitnahe Installation die bekannte Browserlücke auf dem betroffenen System. - 5
Ausnutzung als N-Day
Systeme ohne installierten Fix können weiter gefährdet sein. Angreifer können veröffentlichte Details oder vorhandenen Exploit-Code manchmal für solche Systeme anpassen. Wiederverwendung ist möglich, aber weder ein fertiges Exploit-Kit noch eine feste Dauer sind vorgegeben. Googles Analyse wiederverwendeter Exploits zeigt, warum ein veröffentlichter Fix auch tatsächlich bei den Nutzenden ankommen muss.

Ein Exploit ist nur so lange ein Zero-Day, wie kein öffentlicher Patch verfügbar ist. Danach verlagert sich das Risiko auf Geräte ohne Update. Ermittle die betroffenen Versionen, installiere Fixes zügig und lass Schutzfunktionen im Browser und auf Endgeräten durchgehend aktiviert.
Wo Update-Lücken entstehen

Kompatibilitätstests, Richtlinien für verwaltete Geräte oder ein offen gelassener Browser können Updates verzögern. Das ist eine andere Phase als die Zeit vor Veröffentlichung eines Patches. Beide erfordern mehrere Schutzebenen, doch nur das Update behebt die bekannte Lücke in einer betroffenen Version.
Vor dem Patch. Für die betroffene Software gibt es noch keinen spezifischen Fix. Welche Systeme angreifbar sind, hängt von Version, Betriebssystem, Einstellungen und Bedingungen des Exploits ab. Hersteller veröffentlichen während der Entwicklung eines Fixes möglicherweise nur begrenzte technische Details.
Patch verfügbar, aber nicht installiert. Verwaltete Geräte brauchen womöglich Tests und einen abgestimmten Rollout. Währenddessen können Angreifer ungepatchte Versionen ins Visier nehmen. Erst wenn die betroffenen Browser mit der korrigierten Version neu gestartet sind, schützt sie der veröffentlichte Fix.
Zurückgelassene Geräte. Gemeinsam genutzte Rechner, nicht mehr unterstützte Betriebssysteme und unverwaltete Browser verpassen mitunter ein Update. Eine Bestandsaufnahme mit Versionsprüfung zeigt diese Geräte, statt den aktuellen Stand der ganzen Flotte einfach vorauszusetzen.
Ausnahmefälle. Muss ein Update aufgeschoben werden, begrenze den Zugang zu riskanten Inhalten, nutze verwaltete Browser-Schutzfunktionen und halte fest, wann die korrigierte Version installiert wird. Ein Remote-Browser kann die lokale Ausführung von Website-Code reduzieren. Er rechtfertigt aber keine verschobenen Updates und beseitigt das Risiko für Konten in der Remote-Session nicht.
Was die Daten zeigen
Die Google Threat Intelligence Group erfasste 75 im Jahr 2024 offengelegte Zero-Day-Schwachstellen, die nachweislich ausgenutzt wurden. Sie betreffen viele Produktkategorien, nicht 75 Browserlücken. Ihre Analyse für 2024 zählt erkannte und offengelegte Fälle, nicht jeden Angriff.
erfasste und ausgenutzte Zero-Days über alle Produktkategorien hinweg im Jahr 2024
bei Endnutzerprodukten, darunter Browser sowie mobile und Desktop-Betriebssysteme
bei Produkten für Unternehmen
In diesem Datensatz sank die Zahl der Browser-Zero-Days von 17 im Jahr 2023 auf 11 im Jahr 2024. Daraus lässt sich weder eine allgemeine Verzögerung beim Patchen noch die Wahrscheinlichkeit eines Angriffs auf eine beliebige Person ableiten. Die Zahlen unterstreichen, warum Teams betroffene Versionen erfassen, verfügbare Fixes installieren und bis dahin Schutzfunktionen nutzen sollten.
Dokumentierte Browserfälle
Sicherheitshinweise der Hersteller dokumentieren die Schwachstelle und das Update. Über Betroffene oder die vollständige Angriffskette verraten sie oft wenig. Diese vier Beispiele zeigen, warum diese Grenze wichtig ist.

Chrome CVE-2023-2033. Googles Sicherheitshinweis vom April 2023 beschreibt einen Type-Confusion-Fehler in V8 und meldet, dass ein Exploit in freier Wildbahn existierte. Der Hinweis nennt weder den Angriffsweg noch eine vollständige Übernahme des Geräts.
Firefox CVE-2024-9680. Mozillas Sicherheitshinweis vom Oktober 2024 meldet einen Use-after-free-Fehler in Animation Timelines, der in freier Wildbahn ausgenutzt wurde. Er beschreibt keine Kampagne, keinen Sandbox-Ausbruch und keine Spyware.
Safari 18.1.1. Apples Sicherheitshinweis nennt CVE-2024-44308 in JavaScriptCore und CVE-2024-44309 in WebKit. Beide könnten auf Macs mit Intel-Prozessor aktiv ausgenutzt worden sein. Ein Angriffsweg oder eine spätere Kampagne wird nicht genannt.
Chrome CVE-2025-2783. Googles Sicherheitshinweis vom März 2025 bestätigte die Ausnutzung und kündigte ein Desktop-Update an. Wie der Angriff ausgeliefert wurde und wie lange einzelne Rollouts dauerten, lässt er offen.
Ein Browser-Exploit und ein gestohlenes angemeldetes Konto sind verschiedene Folgen. Ein Renderer-Fehler kann in der Sandbox enden. Eine gestohlene Session benötigt möglicherweise gar keinen Browserfehler. Dieses andere Kontorisiko erklärt unser Leitfaden zum Session-Hijacking.
Schutz über Updates hinaus

Zügiges Patchen ist unerlässlich. Eine Lücke lässt sich aber erst beheben, wenn sie bekannt ist und ein Fix vorliegt. Weitere Schutzmassnahmen haben unterschiedliche Aufgaben: Sie können den Zugang zu anfälligem Code erschweren, die Wirkung eines Exploits begrenzen oder Missbrauch erkennbar machen.
Erweiterungen. Je nach erteilten Berechtigungen können Browser-Erweiterungen weitreichenden Zugriff auf Seiten oder Browserdaten haben. Prüfe deine installierten Erweiterungen und entferne unnötige. Missbrauch durch Erweiterungen ist ein anderes Risiko als ein Browser-Zero-Day. Ein aktueller Browser prüft Erweiterungen nicht automatisch für dich.
Schutzfunktionen des Browsers. Website-Isolation, Sandboxing und Exploit-Schutz können die Folgen mancher Fehler begrenzen. Wie gut sie wirken, hängt von der konkreten Lücke und Plattform ab. Änderungen an verwalteten Sicherheitseinstellungen brauchen einen dokumentierten Grund und eine Risikoprüfung.
Betriebssystem und Endgeräte. Halte auch das Betriebssystem aktuell. Sicherheitstools auf Endgeräten können verdächtiges Verhalten erkennen, selbst wenn ihnen eine Signatur für einen bestimmten Zero-Day fehlt. Sie sind weder grundsätzlich blind noch eine Garantie gegen jeden Angriff.
Remote-Browser-Isolation. Wird eine Website in einem Remote-Browser ausgeführt, ist der lokale Browser samt Betriebssystem ihrem Code weniger direkt ausgesetzt. Das schützt weder Konten innerhalb der Remote-Session vor Übernahme noch vor unsicheren Downloads oder Interaktionen über Viewer und Zwischenablage. Browser.lol-Sessions enden nicht immer beim Schliessen des Tabs, und gespeicherte Profile können bestehen bleiben. Isolation ergänzt rasche Updates, sie rechtfertigt keine Verzögerung.
Schutz durch mehrere Ebenen
Jede Massnahme deckt einen anderen Teil des Angriffs ab. Ihr Nutzen hängt von der Lücke, der Konfiguration und dem Arbeitsablauf ab.
| Massnahme | Vor einem öffentlichen Patch | Nach Veröffentlichung eines Patches |
|---|---|---|
| Antivirus und EDR | Können verdächtiges Verhalten erkennen; kein spezifischer Fix | Können Aktivitäten erkennen, während Updates ausgerollt werden |
| Browser- und Betriebssystem-Updates | Noch kein Fix für eine unbekannte Lücke | Fix des Herstellers zügig installieren |
| URL-Reputation | Kann bekannte Angriffsseiten blockieren | Hängt weiterhin davon ab, ob die Seite bekannt ist |
| Lokale Browser-Sandbox | Kann einzelne Exploit-Schritte begrenzen | Zusätzlich zum Update aktiviert lassen |
| Tor Browser | Eigene Schutzfunktionen und Update-Stand sind entscheidend | Tor Browser aktualisieren, sobald ein Fix vorliegt |
| Remote-Browser-Isolation | Kann die lokale Ausführung von Website-Code reduzieren | Weiter aktualisieren; Remote-Konten und Daten bleiben gefährdet |
Keine Zeile verspricht vollständigen Schutz. Remote-Isolation verlagert die Ausführung von Website-Code. Eine Lücke im Remote-Browser kann aber weiterhin die Session oder darin genutzte Konten betreffen. Auch der Browser.lol-Viewer läuft in einem lokalen Browser. Prüfe den gesamten Ablauf mit Downloads, Zwischenablage, Zugangsdaten und gespeicherten Profilen, bevor du ihn als begrenzt einstufst.
Musst du unbekannte Seiten öffnen, arbeite nach einem kontrollierten Ablauf mit Testkonten und möglichst ohne echte Geheimnisse. Prüfe nach der Arbeit, ob die Remote-Session tatsächlich beendet wurde. Allein den Tab zu schliessen, ist dafür keine verlässliche Methode. Aktualisiere lokale und Remote-Browser weiter und beachte Warnungen der übrigen Schutzebenen.
Risiko begrenzen und zügig aktualisieren

Zero-Day-Meldungen erinnern daran, dass ein spezifischer Patch nicht vor Entdeckung einer Lücke bereitstehen kann. Sie belegen weder, dass jeder Browser ständig angegriffen wird, noch dass Patchen gescheitert ist. Hersteller-Fixes, Browser-Sandboxing, Überwachung auf Endgeräten und Remote-Isolation erfüllen unterschiedliche Aufgaben mit unterschiedlichen Grenzen.
Aktualisiere betroffene Browser, sobald es praktikabel ist, lass ihre Schutzfunktionen aktiviert und nutze einen Remote-Browser dort, wo er die lokale Gefährdung sinnvoll verringert. Zugangsdaten, übertragene Dateien und die Remote-Session selbst gehören dabei zum Sicherheitskonzept. Mehrere Schutzebenen verringern Risiken, ohne zu versprechen, dass jeder unbekannte Exploit gestoppt wird.
Brauchst du für deine nächste Aufgabe eine isolierte Session?
Starte eine isolierte Session direkt im Web.
Session startenKeine Browserinstallation nötig • Funktionen je nach Plan



