Luka, którą Google nazywa średnią

8 września Google przeniósł Chrome 153 do stabilnego kanału dla Windows, Mac i Linux, po cichu zamykając CVE-2026-87491, błąd zapisu poza granicami bufora w V8, silniku, który uruchamia każdy skrypt na każdej stronie otwieranej przez użytkownika Chrome. W tych samych notatkach wydania własny zespół bezpieczeństwa Google napisał zdanie, które naprawdę ma znaczenie: "Google wie, że w obiegu istnieje exploit dla CVE-2026-87491." Specjalnie spreparowana strona internetowa wystarczy, by go uruchomić, a udany atak pozwala napastnikowi wykonać dowolny kod wewnątrz piaskownicy przeglądarki.

Jeśli jednak spojrzeć na kolumnę wagi obok CVE, własny system śledzenia błędów Chromium ocenia ją jako średnią. Nie krytyczną, nawet nie wysoką. Badaczka, która ją znalazła i zgłosiła, Jihyeon Jeong z Compsec Lab na Seoul National University, otrzymała nagrodę w wysokości 2500 dolarów, nagrodę średniego poziomu, która pasuje do średniej etykiety. Nic w samej poprawce nie sygnalizuje pilności. Wszystko w sposobie, w jaki luka była wykorzystywana, sygnalizuje.

Dlaczego CISA nie zgadza się z etykietą

Amerykańska agencja ds. cyberbezpieczeństwa i bezpieczeństwa infrastruktury nie ocenia błędów według tego, jak poważne teoretycznie mogłyby być. Prowadzi jedną listę, katalog znanych wykorzystywanych podatności, i jedyną rzeczą, która umieszcza CVE na tej liście, jest dowód, że ktoś już wykorzystuje ją przeciwko rzeczywistym celom. CVE-2026-87491 znajduje się teraz na tej liście, zarejestrowane pod Google, Chromium V8, z terminem naprawy do 23 września 2026 roku, piętnaście dni po wydaniu poprawki.

Ten piętnastodniowy termin jest wymogiem dla amerykańskich cywilnych agencji federalnych, a nie wymogiem unijnym, więc nie wiąże bezpośrednio żadnego czytelnika Servoli. To, co daje, jest czymś bardziej użytecznym niż wymóg prawny: drugim, niezależnym sygnałem, zbudowanym wyłącznie na dowodach wykorzystania, a nie na własnej ocenie dostawcy, i trafił on na lukę, którą własne śledzenie Chromium nadal nazywa średnią. Gdy te dwie oceny różnią się tak wyraźnie, to właśnie wpis do KEV odzwierciedla to, co naprawdę dzieje się teraz w internecie.

Cztery luki zero-day, jeden silnik

CVE-2026-87491 nie jest odosobnionym przypadkiem. To siódma luka zero-day w Chrome, którą Google potwierdził jako aktywnie wykorzystywaną w 2026 roku, i pojawiła się zaledwie cztery dni po szóstej, CVE-2026-85046, kolejnej luce w V8 naprawionej 3 września. Cztery z siedmiu potwierdzonych w tym roku luk zero-day znajdują się konkretnie w V8, silniku JavaScript i WebAssembly, który dzielą Chrome, Edge, Opera, Brave i każda inna przeglądarka oparta na Chromium.

Ta koncentracja nie jest przypadkiem tego, co akurat zgłoszono w tym roku. V8 jest jednym z najbardziej testowanych metodą fuzzingu i najlepiej wynagradzanych elementów kodu w przeglądarce, co oznacza, że napastnicy, którzy rzeczywiście coś tam znajdują, zyskują komponent działający praktycznie na każdym komputerze i telefonie na świecie, a nie funkcję niszową włączoną tylko przez ułamek użytkowników. Cztery trafienia w jednym silniku w ciągu dziewięciu miesięcy brzmią mniej jak pech, a bardziej jak świadomy wybór napastników co do tego, gdzie znajduje się najcenniejsza praca.

Co to oznacza dla zespołu bezpieczeństwa w UE

Większość programów zarządzania podatnościami wciąż priorytetyzuje najpierw według wagi nadanej przez dostawcę, a dopiero potem, jeśli w ogóle to sprawdza, według statusu wykorzystania. Ta luka jest argumentem przeciwko takiej kolejności. Zespół, który naprawia natychmiast błędy krytyczne i wysokie, a średnie zostawia na kolejne okno konserwacyjne, pozostawiłby CVE-2026-87491 otwartą przez tygodnie, podczas gdy była już wykorzystywana, ponieważ etykieta mówiła, że może poczekać.

Sama poprawka nie kosztuje nic poza zwykłym cyklem aktualizacji: Chrome aktualizuje się automatycznie do wersji 153.0.8010.36 lub nowszej na większości zarządzanych i niezarządzanych urządzeń w ciągu kilku dni, a sprawdzenie numeru wersji w ustawieniach Chrome to potwierdza. Trwalsza zmiana ma charakter proceduralny. Oczekiwanie NIS2 dotyczące zarządzania podatnościami zgodnie z najnowszym stanem wiedzy technicznej łatwiej spełnić, wpinając kanał KEV CISA bezpośrednio do kolejki priorytetów łatania, niż ufając, że własna ocena wagi dostawcy przechwyci na czas każdą aktywnie wykorzystywaną lukę, bo ten przypadek pokazuje, że ta ocena tego nie robi.

Servola Journal

Robimy to dla wszystkich, którzy starają się nadążyć za tym, co technologia robi z naszym życiem. Dla ludzi, którzy ją budują, i dla ludzi, którym się to przydarza. Servola Journal istnieje, aby to, czego się uczymy, należało do nich wszystkich.

Nikt nam za to nie płaci. Żadnych reklam, żadnego muru płatności, za darmo dla wszystkich. Po prostu wierzymy, że zrozumienie tego, co dzieje się z nami wszystkimi, nie powinno zależeć od tego, kogo stać na zapłacenie za to.

Jeśli dało ci to dziś coś wartościowego, powiedz nam, żebyśmy kontynuowali. Obserwuj nas, zostaw polubienie albo napisz pozytywny komentarz. Czytamy każdy z nich, i to one nas napędzają.

Czytaj dalej: Wykorzystane Tygodnie Przed Łatą PaperCut  |  Zespoły Bezpieczeństwa UE Bez Głosu W Sprawie Astry