Wprowadzenie do problemu / definicja luki
Integracja asystentów AI bezpośrednio w przeglądarkach (tzw. agentic browsers) przesuwa granice użyteczności, ale jednocześnie otwiera nową powierzchnię ataku: komponent AI działa „bliżej” przeglądarki i często ma szerszy dostęp do zasobów systemu niż zwykła karta WWW. Właśnie w takim miejscu pojawiła się podatność CVE-2026-0628 w Google Chrome, która mogła umożliwić złośliwemu rozszerzeniu przejęcie panelu Gemini Live i uruchomienie działań wykraczających poza jego standardowe uprawnienia.
W skrócie
- Podatność: CVE-2026-0628 (High; w NVD widoczny też wektor CVSS 3.1 8.8 dodany przez CISA-ADP).
- Mechanizm: niewystarczające egzekwowanie polityk w tagu WebView → możliwość wstrzyknięcia skryptu/HTML do uprzywilejowanego kontekstu.
- Scenariusz ataku: użytkownik instaluje złośliwe rozszerzenie; następnie po uruchomieniu Gemini w panelu bocznym atakujący może przejąć kontekst panelu.
- Skutki (wg Unit 42): potencjalny dostęp do kamery/mikrofonu, zrzutów ekranu, lokalnych plików oraz możliwość nadużyć phishingowych w „zaufanym” UI panelu.
- Status: Google załatało błąd w aktualizacji Stable 143.0.7499.192/.193 (wydanie ogłoszone 6 stycznia 2026).
Kontekst / historia / powiązania
Badanie opisał zespół Palo Alto Networks Unit 42, wskazując na szerszy trend: „AI w przeglądarce” to nie tylko ryzyko prompt injection z poziomu stron WWW, ale również powrót klasycznych problemów bezpieczeństwa w nowym, wysoko uprzywilejowanym komponencie (panel AI).
W tym przypadku podatność została:
- zgłoszona odpowiedzialnie do Google 23 października 2025,
- naprawiona na początku stycznia 2026,
- a szczegóły upubliczniono 2 marca 2026 wraz z publikacją analizy.
Media branżowe (m.in. SecurityWeek oraz Dark Reading) podkreśliły, iż to przykład ryzyka „eskalacji” z pozornie ograniczonego rozszerzenia do komponentu o uprawnieniach bliskich przeglądarce.
Analiza techniczna / szczegóły luki
1) Gdzie przebiegała granica zaufania
Kluczowy detal z analizy Unit 42: Gemini web app (gemini.google[.]com/app) może być ładowany:
- jako zwykła strona w karcie (standardowy model WWW), albo
- wewnątrz nowego panelu Gemini z dodatkowymi „hakami” przeglądarki, które zapewniają rozszerzone możliwości potrzebne do realizacji zadań przez asystenta.
To „miejsce uruchomienia” aplikacji Gemini zmieniało stawkę: w zwykłej karcie wpływanie na treść strony przez rozszerzenie jest w wielu przypadkach oczekiwane; natomiast wpływanie na treść uprzywilejowanego panelu wbudowanego w przeglądarkę staje się problemem krytycznym.
2) Jakie API/zdolności mogły zostać nadużyte
Unit 42 opisuje, iż rozszerzenie z „podstawowym” zestawem uprawnień mogło wykorzystać możliwości przechwytywania i modyfikowania ruchu WWW (w analizie wskazano declarativeNetRequest) tak, aby doprowadzić do wstrzyknięcia JavaScript w kontekście panelu Gemini.
3) Co oznacza „eskalacja” w praktyce
Gdy kod atakującego wykona się w kontekście panelu Gemini, przestaje obowiązywać typowa „nisko-uprawnieniowa” perspektywa rozszerzenia. Według demonstracji Unit 42 przejęty panel mógł umożliwiać m.in.:
- uruchomienie kamery i mikrofonu bez standardowej ścieżki zgody,
- wykonanie screenshotów dowolnych kart,
- dostęp do lokalnych plików i katalogów,
- oraz wyświetlenie treści phishingowych w UI, które użytkownicy uznają za część Chrome.
4) Jak to zostało sklasyfikowane formalnie
Opis CVE w NVD wskazuje na insufficient policy enforcement in WebView tag prowadzące do możliwości wstrzyknięcia skryptu/HTML do uprzywilejowanej strony przez spreparowane rozszerzenie (wymagana jest instalacja rozszerzenia przez użytkownika).
Praktyczne konsekwencje / ryzyko
Ryzyko dla użytkowników indywidualnych
- Naruszenie prywatności: potencjalny podgląd audio/wideo, zrzuty ekranu, wyciek plików.
- Phishing „z wnętrza przeglądarki”: panel Gemini jest elementem zaufanym, więc podszycie się pod komunikaty lub ekrany logowania jest psychologicznie groźniejsze niż zwykły pop-up na stronie.
Ryzyko dla firm (endpointy i dane)
W środowisku enterprise choćby pojedyncze złośliwe rozszerzenie może stać się wektorem do:
- wycieku danych z dokumentów lokalnych,
- podsłuchu spotkań (mikrofon/kamera),
- kradzieży treści widocznych w aplikacjach webowych (zrzuty ekranów, treści stron).
Warto podkreślić: to nie jest „zdalny drive-by” bez udziału użytkownika — warunkiem jest instalacja rozszerzenia. Jednak w praktyce kampanie złośliwych rozszerzeń (lub przejęcia legalnych dodatków) są realnym zjawiskiem, a AI-panel zwiększa potencjalny „zwrot” z takiej infekcji.
Rekomendacje operacyjne / co zrobić teraz
1) Aktualizacja Chrome (priorytet)
- Upewnij się, iż Chrome jest co najmniej w wersji 143.0.7499.192 (Windows/Mac: 143.0.7499.192/.193; Linux: 143.0.7499.192).
- W organizacji: wymuś aktualizacje politykami (MDM/GPO) i zweryfikuj stan wersji w inwentarzu.
2) Higiena rozszerzeń (kluczowa, bo atak wymaga instalacji)
- Zredukuj liczbę rozszerzeń do niezbędnego minimum.
- W firmie: allowlist i blokada instalacji spoza zatwierdzonych źródeł; cykliczny przegląd uprawnień.
- Monitoruj rozszerzenia używające mechanizmów modyfikacji ruchu/treści (to nie znaczy, iż są złe — ale to obszar wymagający nadzoru).
3) Kontrola dostępu do peryferiów i telemetryka
- Ogranicz dostęp przeglądarki do kamery/mikrofonu tam, gdzie to możliwe (polityki, ustawienia OS).
- Zbieraj sygnały: nietypowe uruchomienia kamery/mikrofonu, anomalie ruchu wychodzącego, nietypowe działania przeglądarki po uruchomieniu panelu AI.
4) Edukacja użytkowników (szybka, konkretna)
- „Zaufany panel przeglądarki” ≠ „zawsze bezpieczny”.
- Instalacja rozszerzeń „od AI / do produktywności” powinna przechodzić tę samą weryfikację co każde inne narzędzie.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
W klasycznym modelu przeglądarki złośliwe rozszerzenie zwykle działa w granicach przyznanych mu uprawnień (np. manipulacja DOM na stronach). Tu istotna jest zmiana jakościowa: poprzez błąd izolacji/polityk, rozszerzenie mogło przejść do kontekstu wbudowanego komponentu AI o rozszerzonych możliwościach (kamera, pliki, screenshoty). To modelowo inny typ ryzyka niż np. prompt injection wyłącznie z poziomu treści strony, bo wchodzi w grę eskalacja do uprzywilejowanego elementu przeglądarki.
Podsumowanie / najważniejsze wnioski
- CVE-2026-0628 pokazało, iż AI-asystenci w przeglądarce tworzą nową „warstwę uprzywilejowania”, a błędy izolacji mogą dać atakującemu dużo więcej niż w tradycyjnych scenariuszach z rozszerzeniami.
- Naprawa jest dostępna od 6 stycznia 2026 w Stable 143.0.7499.192/.193, więc najważniejsza akcja to aktualizacja i walidacja wersji.
- Ponieważ atak wymaga instalacji dodatku, „higiena rozszerzeń” (allowlist, kontrola uprawnień, monitoring) pozostaje jednym z najskuteczniejszych środków redukcji ryzyka.
Źródła / bibliografia
- Unit 42 (Palo Alto Networks) – analiza CVE-2026-0628 i scenariuszy eskalacji przez panel Gemini (publikacja: 2 marca 2026). (Unit 42)
- Chrome Releases (Google) – Stable Channel Update for Desktop, wersja 143.0.7499.192/.193 (data: 6 stycznia 2026). (Chrome Releases)
- NVD (NIST) – wpis CVE-2026-0628 (data publikacji w NVD: 7 stycznia 2026). (nvd.nist.gov)
- SecurityWeek – omówienie wpływu podatności na Gemini Live w Chrome (publikacja: 2 marca 2026). (SecurityWeek)
- Dark Reading – komentarz o ryzykach „agentic browsers” i eskalacji przez panel Gemini (publikacja: 2 marca 2026). (Dark Reading)
