Wprowadzenie do problemu / definicja luki
Przeglądarka to dziś „runtime” dla aplikacji webowych, a więc realna powierzchnia ataku – szczególnie gdy w grę wchodzą błędy pamięci (use-after-free, buffer overflow, type confusion) w komponentach renderujących, multimedialnych czy akcelerowanych GPU. Dlatego choćby pozornie „rutynowe” aktualizacje Stable Chrome mają znaczenie operacyjne: zamykają wektory prowadzące do RCE, eskalacji uprawnień w sandboxie lub obejść polityk bezpieczeństwa.
12 lutego 2026 Google wypuściło kolejną aktualizację kanału Stable dla desktopów: 145.0.7632.68 (Windows/Mac) oraz 144.0.7559.67 (Linux). Aktualizacja ma być rolowana stopniowo w kolejnych dniach/tygodniach.
W skrócie
- Nowe wersje Stable: 145.0.7632.68 dla Windows/Mac oraz 144.0.7559.67 dla Linux.
- To kolejny krok w rollout po wydaniu z 10 lutego 2026, w którym Chrome 145 trafiło na Stable i zawierało 11 poprawek bezpieczeństwa (w tym luki o randze High).
- W praktyce taki „mały bump” (np. z .45/.46 do .68) bywa wykorzystywany do stabilizacji, poprawek regresji lub dopięcia rollout, ale organizacyjnie warto traktować go jako element łańcucha aktualizacji bezpieczeństwa.
Kontekst / historia / powiązania
Dwa dni wcześniej, 10 lutego 2026, Google ogłosiło promocję Chrome 145 do Stable dla Windows/Mac/Linux i wskazało, iż wydanie zawiera 11 security fixes (z listą CVE i komponentów).
Co ważne dla zespołów IT/SOC: ekosystem Chrome ma też równoległe zmiany „enterprise’owe” i bezpieczeństwa platformy (np. mechanizmy ograniczające kradzież sesji czy zmiany w WebGPU w określonych trybach ochrony). W release notes dla środowisk zarządzanych widać m.in. wątki dotyczące bezpieczeństwa sesji i twardnienia przeglądarki w Chrome 145.
Analiza techniczna / szczegóły luki
Sam wpis z 12 lutego 2026 nie wymienia wprost CVE ani listy poprawek bezpieczeństwa – podaje tylko numery buildów i odsyła do changeloga.
Jednak patrząc na kontekst z 10 lutego, wiemy, iż gałąź 145 w Stable obejmuje szereg napraw klasycznych podatności przeglądarkowych, m.in.:
- Use-after-free w CSS (High)
- Heap buffer overflow w Codecs (High)
- Błędna implementacja w WebGPU (High)
oraz inne luki Medium/Low w obszarach takich jak Frames, DevTools, File input czy Downloads.
Żeby pokazać „typ” ryzyka na konkretnym przykładzie z tej serii: CVE-2026-2315 (WebGPU, High) została opisana jako błąd implementacyjny umożliwiający potencjalnie out-of-bounds memory access po stronie Chrome (scenariusz: spreparowana strona HTML).
Wniosek operacyjny: choćby jeżeli 12 lutego to „maintenance build”, to w praktyce jest on częścią bezpiecznego dowiezienia linii 145 na endpointy (oraz ograniczania okna ekspozycji na podatności opisane w wydaniu 145).
Praktyczne konsekwencje / ryzyko
- Ryzyko dla użytkowników końcowych: podatności pamięciowe w przeglądarce zwykle są atrakcyjne dla atakujących, bo mogą prowadzić do kompromitacji przez samo wejście na stronę (lub wykonanie akcji w UI), a potem do dalszych etapów łańcucha ataku (np. ucieczka z sandboxa, dropper). W tej serii poprawek mamy kilka luk High.
- Ryzyko dla organizacji: opóźnienia w rollout powodują, iż część floty pozostaje na buildach sprzed poprawek. Wpisy Google wprost mówią o stopniowym wdrażaniu „over the coming days/weeks”.
- Wersje różne per OS: 12 lutego widać asymetrię numeracji (Windows/Mac: 145.x, Linux: 144.x). To istotne dla inwentaryzacji i compliance – progi wersji w politykach (np. w MDM/EDR) powinny uwzględniać platformę, a nie tylko „jedną docelową liczbę”.
Rekomendacje operacyjne / co zrobić teraz
- Wymuś/monitoruj aktualizację do najnowszego Stable na każdej platformie: dla Windows/Mac celuj w 145.0.7632.68, a dla Linux co najmniej 144.0.7559.67 (zgodnie z komunikatem z 12 lutego).
- Zamknij okno ekspozycji: potraktuj rollout jako pilny, bo gałąź 145 zawiera liczne poprawki bezpieczeństwa, w tym High.
- Zadbaj o „relaunch compliance”: w praktyce wiele organizacji ma poprawnie pobrane aktualizacje, ale użytkownicy nie restartują Chrome. Mierz wskaźniki „pending relaunch” i komunikuj wymuszenia (np. grace period).
- SOC/IR: jeżeli widzisz kampanie webowe/drive-by lub anomalia związane z GPU/codec, potraktuj endpointy bez 145 jako podwyższone ryzyko (priorytet do aktualizacji i dodatkowy monitoring).
- Enterprise/zmiany funkcji: o ile zarządzasz flotą, śledź również zmiany w release notes (np. mechanizmy bezpieczeństwa sesji i inne twardnienia), bo mogą wpływać na aplikacje webowe i polityki.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- 10 lutego 2026: wydanie „duże” – wejście Chrome 145 na Stable i jawnie wymienione CVE (11 pozycji).
- 12 lutego 2026: wydanie „małe/utrwalające” – komunikat skupia się na numerach buildów i odsyła do logu zmian, bez listy CVE.
Taki układ jest typowy: najpierw publikacja z listą CVE, a później szybkie „dot release” poprawiające jakość/stabilność rollout i ewentualne regresje.
Podsumowanie / najważniejsze wnioski
- Aktualizacja z 12 lutego 2026 podnosi Stable do 145.0.7632.68 (Windows/Mac) oraz 144.0.7559.67 (Linux) i jest rolowana stopniowo.
- Warto ją traktować jako element łańcucha bezpieczeństwa po wydaniu z 10 lutego, które zawierało 11 poprawek security (w tym High w obszarach CSS/Codecs/WebGPU).
- Dla organizacji najważniejsze jest: aktualizacja + wymuszenie restartu + poprawna walidacja wersji per OS.
Źródła / bibliografia
- Google Chrome Releases – Stable Channel Update for Desktop (12 lutego 2026). (Chrome Releases)
- Google Chrome Releases – Stable Channel Update for Desktop (10 lutego 2026) + lista poprawek bezpieczeństwa (CVE). (Chrome Releases)
- NVD – CVE-2026-2315 (WebGPU, High) – opis i zakres wersji. (nvd.nist.gov)
- Chrome Enterprise & Education release notes – wybrane zmiany w Chrome 145 (kontekst funkcji i bezpieczeństwa). (Google Help)
- Zewnętrzny advisory (CERT/CIRT) odnoszący się do wydań Chrome z lutego 2026 (kontekst operacyjny). (cirt.gy)
