8 września 2026 Google wydał Chrome 153.0.8010.36/.37 (Windows/macOS) i 153.0.8010.36 (Linux). Wśród 230 poprawek jest CVE-2026-87491 — out-of-bounds write w V8, oznaczony jako Medium. Jednocześnie vendor pisze wprost: Google is aware that an exploit for CVE-2026-87491 exists in the wild. To najczystszy możliwy argument, że severity label i exploitation evidence to dwa różne wymiary decyzji.
Medium; active exploitation = confirmed.„Medium + exploited” bywa pilniejsze niż „Critical + theoretical”
Severity odpowiada na pytanie o bazowy techniczny impact w danym modelu. Active exploitation odpowiada na inne: czy ktoś zainwestował w działający exploit i używa go w realnym świecie. To dwa różne wymiary, które można mieć naraz:
Taki rekord powinien zwykle wyprzedzać severity = Critical z exploit evidence = none i asset exposure = low. Jeśli backlog sortuje wyłącznie po score, finding trafia pod dziesiątki Critical/High, mimo że atakujący już go używa. Google ogranicza szczegóły exploita do czasu, aż większość użytkowników dostanie aktualizację — więc VE nie powinien dopisywać primitive, sandbox escape chain ani payloadu. Wystarczające evidence to: affected version + remote web content + memory corruption w V8 + exploit in the wild.
Patch installed ≠ browser restarted
Chrome auto-update może pobrać nową wersję, ale procesy działają ze starym kodem aż do restartu. Dlatego weryfikacja nie może opierać się na package version on disk — potrzebna jest running browser version oraz potwierdzenie, że użytkownik zakończył starą sesję. W endpoint fleet to istotne: wielodniowe uptime'y przeglądarki potrafią zostawić exploitable runtime mimo pobranej poprawki.
Kanał, populacja i ekspozycja
Google utrzymuje też Extended Stable, więc VE mapuje kanał aktualizacji, nie samą nazwę produktu: który kanał ma endpoint, jaka wersja jest faktycznie uruchomiona, czy polityka enterprise opóźnia restart, czy VDI resetuje obraz, czy golden image zawiera fix. Przeglądarka jest wyjątkowa, bo attack surface jest codziennie wystawiona na niezaufaną treść — nie trzeba publicznego serwera, wystarczy user browses web / opens malicious content. Dlatego „internal workstation” nie oznacza niskiej ekspozycji.
Priorytetyzacja i weryfikacja
Praktyczny model priorytetu: base severity + exploitation evidence + attack surface frequency + user population + privilege context + remediation availability. CVE-2026-87491 ma bardzo silny exploitation modifier. Compensating controls (web filtering, browser isolation, application control, EDR exploit prevention, ograniczenie JS w strefach) zmniejszają ryzyko, ale żaden nie jest równoważny patchowi. Minimalna weryfikacja: właściwa running version per kanał, proces po restarcie, coverage wszystkich managed endpoints, osobno unmanaged/BYOD, przegląd telemetrii EDR pod kątem browser exploitation w okresie przed poprawką. Przy confirmed active exploitation warto polować po telemetrii (crashe V8, child-process anomalies, post-browser payload) — jeśli EDR pokaże chain, przechodzimy do incident response.
Powiązane na blogu
- Windows: dwa 7.8 w KEV — KEV jako sygnał ważniejszy niż intuicja z CVSS
- StyleSmuggler: 0-day → CVE → hotfix — jak stan podatności zmienia się w czasie
Źródła
- Google Chrome Releases — Stable Channel Update for Desktop, 08.09.2026 — chromereleases.googleblog.com
Nota redakcyjna: stan informacji 10 września 2026. CVE-2026-87491 (Chrome, out-of-bounds write w V8) jest oznaczony przez Google jako Medium, a vendor potwierdza exploit in the wild. Artykuł nie odtwarza szczegółów exploita (ograniczonych przez vendora) i koncentruje się na priorytetyzacji z exploitation evidence oraz weryfikacji running version.