FlawOpen

flawopen.com/Teardowns/cve-2026-0628-chrome-gemini-webview-extension-policy

● CVE-2026-0628 · CVSS 8.8[3] · Hoch
Sicherheitsforschung · FlawOpen

CVE-2026-0628: Chrome-Gemini-WebView

CVE-2026-0628 ließ Chrome-Erweiterungen per DNR Geminis privilegierte WebView beeinflussen. Aktualisieren Sie Chrome auf 143.0.7499.192 oder neuer.[1], [3], [5]

CVSS-VektorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H[3]
💡 Einfache Erklärung (ELI5)

Stellen Sie sich Gemini Live als öffentlichen Serviceschalter in einer Bibliothek vor, hinter dem sich eine Tür nur für Mitarbeitende befindet. Chrome hinderte Erweiterungen daran, durch diese Tür zu gehen, aber eine Regel zum Umleiten von Lieferungen konnte weiterhin ein Skript am Gemini-Schalter austauschen. Das Skript lief an diesem eingebetteten Schalter, der über eine Durchreiche Browserfunktionen anfordern konnte. Bei CVE-2026-0628 fehlte die Prüfung auf diesem Lieferweg.[2], [5]

Kernkonzepte & Begriffe

Privilegierte WebView
Eine in eine browserverwaltete Oberfläche eingebettete Seite, die mit Funktionen kommunizieren kann, die gewöhnlichen Websites nicht offenstehen.[2], [5]
declarativeNetRequest (DNR)
Chrome-Erweiterungs-API, die deklarative Regeln auf passende Netzwerkanfragen anwendet, etwa für Weiterleitungen und Antwortheaderänderungen.[2], [6]
CVE-2026-0628
Googles hoch eingestufte Chrome-Schwachstelle: unzureichende Richtliniendurchsetzung im WebView-Tag vor Chrome 143.0.7499.192.[3], [4]
BragJack / Prompt Forcing
Forschungsbericht vom September 2026 über die Steuerung von Browser-KI-Agenten durch Erweiterungen. Dies ist eine Forschungsbezeichnung, keine weitere Chrome-CVE.[2], [4]

Framework-Zuordnungen

  • CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-862

Ursachenanalyse

Google beschreibt CVE-2026-0628 als unzureichende Richtliniendurchsetzung im Chrome-WebView-Tag. Laut der technischen Analyse von Forever Security nutzte Gemini Live die browserverwaltete Seite chrome://glic, die gemini.google.com in eine WebView einbettete. Chromium blockierte Erweiterungsinteraktionen mit der privilegierten Seite, doch die beschriebene Lücke erlaubte einer Erweiterung mit declarativeNetRequest (DNR), passende HTTPS-Anfragen der eingebetteten Seite zu beeinflussen. Der Forscher beschreibt veränderte Antwortheader und den Austausch eines Skripts, sodass Code in der eingebetteten Gemini-Origin lief und mit der Browser-Agent-Schnittstelle kommunizieren konnte. Dadurch konnte die Grenze zwischen normalen Erweiterungsrechten und den Funktionen des privilegierten Panels überschritten werden. Der Bericht demonstriert Zugriff auf Seitenkontext, lokale Dateiinhalte und Bildschirmaufnahmen; außerdem wird ein möglicher Kamera-/Mikrofonzugriff beschrieben. Das sind vom Forscher gemeldete Auswirkungen, kein Nachweis realer Ausnutzung. Die CVE setzt voraus, dass ein Nutzer eine bösartige Erweiterung installiert. Google behob die WebView-Grenze in Chrome 143.0.7499.192/.193 für Windows/macOS und .192 für Linux. Der öffentliche Chromium-Fix bestätigt die Grenze: RulesetManager gibt false zurück, wenn request.is_web_view true ist, und zwar vor der bestehenden Freigabeentscheidung. Chromium ergänzte ChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatched; der Test überspringt MPArch, daher deckt dieser Regressionstest diese Architektur nicht ab.[3], [2], [5], [4]

Schritt-für-Schritt Angriffsablauf

Schritt 1

Voraussetzungen prüfen

Der beschriebene Chrome-Pfad setzt eine betroffene Version und eine vom Nutzer installierte bösartige oder kompromittierte Erweiterung mit DNR und passenden Hostberechtigungen voraus. Es ist kein Drive-by-Angriff durch eine Webseite.[3], [2], [6]

Schritt 2

Die Browser-Agent-Oberfläche öffnen

Gemini Live nutzt die Browserseite chrome://glic und bettet die Gemini-Web-App in eine WebView ein. Die Browserseite kann Funktionen aufrufen, die gewöhnlichen Webseiten nicht zur Verfügung stehen.[2]

Schritt 3

Die WebView-Anfragegrenze überschreiten

Laut Forscher konnten DNR-Regeln HTTPS-Ressourcen in der eingebetteten WebView beeinflussen, obwohl Erweiterungen nicht direkt mit der privilegierten Oberfläche interagieren durften.[2], [5]

Schritt 4

Privilegiertes Seitenverhalten erreichen

Durch Änderung der Antwortregeln und des in der Gemini-Origin geladenen Codes konnte die demonstrierte Kette mit der Browser-Agent-Schnittstelle kommunizieren. Der Forscher berichtet von lokalen Dateien und Bildschirmaufnahmen; ein Einsatz in freier Wildbahn ist öffentlich nicht belegt.[2], [3]

Schritt 5

Patchen und Erweiterungsrisiko senken

Googles Fix ist je nach Plattform in Chrome 143.0.7499.192/.193 enthalten. Aktualisieren Sie auf den aktuellen Stable-Build und begrenzen Sie Erweiterungen mit weitreichenden Host- und DNR-Berechtigungen.[1], [3], [5]

Quellcode: Verwundbar vs. Sicher

Dies ist die C++-Änderung im Chromium-Upstream und keine nachgestellte Exploit-Kette. Sie weist WebView-Anfragen vor der bestehenden Freigabeentscheidung ab, damit Declarative-Net-Request-Regeln nicht darauf angewendet werden. Chromium ergänzte außerdem ChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatched; dieser Browser-Test überspringt MPArch und belegt daher keine Abdeckung dieser Architektur.[5]

VERWUNDBARE IMPLEMENTIERUNG
// Auszug: extensions/browser/api/declarative_net_request/ruleset_manager.cc
// Vor der Korrektur prüfte diese abschließende Entscheidung nicht, ob die Anfrage aus einer WebView stammte.
return true;
GEHÄRTETER SICHERHEITS-PATCH
// Auszug: extensions/browser/api/declarative_net_request/ruleset_manager.cc
// Chromium-Änderung 9722f06a vor der bestehenden abschließenden Freigabe:
// Declarative-Net-Request-Regeln dürfen nicht auf Anfragen angewendet werden,
// die aus WebViews stammen.
if (request.is_web_view) {
  return false;
}
return true;

Checkliste für Engineering & Systemsicherheit

Quellen