Poziom ważności podatności sam nie wyznacza wysokości nagrody. Opisuje skutki techniczne w określonych warunkach. O pilności naprawy decydują również aktywne wykorzystanie i ekspozycja zasobu. Nagroda zależy też od tego, co dostarczył badacz, od opublikowanych zasad programu, jakości zgłoszenia, bonusów oraz decyzji człowieka.

To rozróżnienie wyjaśnia pozornie niezrozumiałe zdanie w komunikacie Google o Chrome z września 2026 roku. CVE-2026-85046 była podatnością o wysokim poziomie ważności w V8. Google poinformował, że exploit był aktywnie wykorzystywany. Ujawniona nagroda wyniosła 1000 $.

Wysoki poziom ważności i aktywne wykorzystanie nie określają automatycznie nagrody. Dla zespołu bezpieczeństwa w startupie ten przypadek jest dobrym modelem rozdzielenia czterech decyzji: technicznej oceny skutków, pilności naprawy, dostarczonych materiałów dotyczących exploita oraz ustalenia wysokości nagrody.

## Dlaczego Google ujawnił nagrodę w wysokości zaledwie 1000 $ za wykorzystywaną podatność w Chrome?

Publiczne informacje nie pokazują obliczeń Google. Pokazują podatność, priorytet naprawy i ostateczną nagrodę. Te informacje nie wyjaśniają jednak, jak ustalono kwotę.

W [komunikacie o kanale stabilnym z 3 września](https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_01882797386.html) Google opisał CVE-2026-85046 jako „Type Confusion in V8”, podatność o wysokim poziomie ważności. Firma wymieniła badacza Salvatore Gulizię, znanego również jako Serotav, podała datę zgłoszenia 4 sierpnia i ujawniła nagrodę w wysokości 1000 $. Google poinformował też, że exploit dla tej CVE był już używany w rzeczywistych atakach.

Poprawione wersje to 152.0.7977.82 lub .83 dla Windows i macOS oraz 152.0.7977.82 dla Linuksa. Aktualizacja zawierała 12 poprawek bezpieczeństwa. Google zastrzegł, że dostęp do szczegółów błędów może pozostać ograniczony, dopóki większość użytkowników nie zainstaluje aktualizacji.

| Publiczny fakt | Na jakie pytanie odpowiada | Na jakie pytanie nie odpowiada |
|---|---|---|
| Wysoki poziom ważności | Jak Google sklasyfikował skutki techniczne | Jaką nagrodę należy wypłacić za zgłoszenie |
| CVSS 8,8 | Jakie warunki techniczne opisuje wektor CISA | Czy wykorzystanie jest powszechne |
| Aktywnie wykorzystywany exploit | Czy obrońcy powinni pilnie zainstalować poprawkę | Jaki exploit dostarczył autor zgłoszenia |
| Nagroda 1000 $ | Jaką kwotę Google zdecydował się ujawnić | Jak wyglądały wewnętrzne obliczenia lub łączna wypłata |

Pierwsze trzy wiersze nie wystarczą do odtworzenia decyzji o nagrodzie.

Właśnie dlatego macierz nagród potrzebuje przedziałów kwot, a nie cennika. Jeśli tabela mówi „wysoki poziom ważności równa się 1000 $”, pomija czynniki wpływające na wysokość nagrody w danym przedziale. Czy badacz dostarczył przykład powodujący awarię, wiarygodny proof of concept, prymityw exploita nadający się do ponownego użycia, sposób ograniczenia ryzyka czy pełny łańcuch? Czy zgłoszenie było jasne i oryginalne? Przedział dla danego poziomu ważności wyznacza granice dyskusji, ale jej nie zastępuje. W przewodniku po [poziomach nagród, którym ufają badacze](/blog/bug-bounty-reward-tiers-researchers-trust-hackerone-cuts) wyjaśniamy, jak opublikować takie podstawy bez zamieniania ich w sztywną formułę.

## Czy CVE-2026-85046 pozwala wydostać się z izolowanego środowiska Chrome?

Według publicznie dostępnych dowodów nie. Oficjalny wpis CVE mówi, że odpowiednio przygotowany HTML pozwalał wykonać dowolny kod **wewnątrz izolowanego środowiska**. To poważna podatność umożliwiająca wykonanie kodu w silniku JavaScript V8 przeglądarki Chrome, ale nie jest tym samym co ucieczka z izolowanego środowiska i przejęcie kontroli nad systemem operacyjnym.

Chrome izoluje treści internetowe w procesie renderera o ograniczonych uprawnieniach. Gdy napastnik uzyska w nim możliwość wykonania kodu, izolowane środowisko ma uniemożliwić mu swobodny dostęp do systemu hosta. Pełny łańcuch przejęcia przeglądarki często wymaga kolejnej podatności, która pozwala przekroczyć tę granicę. Zespół Project Zero Google opisał to rozróżnienie w materiałach o [ucieczce z izolowanego środowiska Chrome](https://googleprojectzero.blogspot.com/2020/02/).

[Analiza techniczna](https://serotav.github.io/Writeups/v8/when-sorting-leads-to-confusion/) Gulizii opisuje ten podział. Badacz opisuje pomylenie typów, które umożliwiło dowolny odczyt i zapis na stercie JavaScript. Następnie informuje, że połączył „ten błąd” z **n-day sandbox escape**, aby zdobyć flagę w v8CTF. Ta CVE stanowiła więc jeden element łańcucha. Oddzielny, wcześniej znany exploit pozwalał wydostać się z izolowanego środowiska.

To rozróżnienie jest ważne z dwóch powodów.

Po pierwsze, wyznacza granice twierdzenia technicznego. Nazwanie tej CVE „sandbox escape” przypisałoby jej możliwości drugiego exploita. Skrót „sandbox RCE” też jest ryzykowny, bo wielu czytelników zrozumie go jako wykonanie kodu, które przełamało izolację. Precyzyjne określenie brzmi: **wykonanie dowolnego kodu w rendererze V8 działającym w izolowanym środowisku Chrome**.

Po drugie, wpływa na rozmowę o nagrodzie. Podatność w V8, która daje użyteczny prymityw, i działające przejęcie przeglądarki od początku do końca to dwa różne rezultaty pracy badacza. Program może zasadnie definiować dla nich oddzielne kategorie i bonusy. Z zewnętrznej analizy opublikowanej później nie da się wywnioskować, który z nich zawierało zgłoszenie otrzymane przez Google.

Tytuł wpisu przesłanego do Hacker News twierdził również, że błąd dotyczył „wszystkich wersji Chromium”. Historia kodu pokazuje co innego. Optymalizacja `Array.prototype.sort`, z którą wiąże się podatność, [trafiła do V8 27 kwietnia 2026 roku](https://chromium.googlesource.com/v8/v8/+/66a3f1e94d4b681bff6476a876067a3c79a853f0). [Tabela wersji](https://v8.dev/docs/version-numbers) V8 przypisuje wersję 14.9 do Chrome M149. Wpis CVE wyznacza górną granicę, czyli wersje starsze niż 152.0.7977.82, ale nie podaje dolnej. Dolną granicę można ustalić z historii repozytorium.

CISA informuje, że problem może dotyczyć kilku przeglądarek opartych na Chromium, w tym Chrome, Edge i Opera. To sygnał, aby sprawdzić komunikat każdego dostawcy, a nie dowód, że podatny był każdy wariant Chromium i każda historyczna wersja.

## Dlaczego CVSS i katalog KEV CISA odpowiadają na różne pytania?

CVSS opisuje cechy techniczne. Katalog Known Exploited Vulnerabilities (KEV) CISA informuje obrońców, że wykorzystanie przestało być tylko możliwością i zostało zaobserwowane. Potrzebujesz obu sygnałów, ale nie łącz ich w jeden wynik ani w jedną zasadę wypłaty.

[Oficjalny wpis CVE](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/85xxx/CVE-2026-85046.json) opisuje specjalnie przygotowany HTML, który prowadzi do wykonania dowolnego kodu w izolowanym środowisku. Słabość sklasyfikowano jako CWE-843, czyli dostęp do zasobu za pomocą niezgodnego typu. Wynik 8,8 widoczny w [NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-85046) pochodzi z wtórnej oceny przygotowanej przez CISA ADP, a nie z niezależnej oceny NVD.

Wektor ma postać `AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H`. W praktyce oznacza to:

- Atak jest możliwy przez sieć.
- Ma niski poziom złożoności.
- Nie wymaga wcześniejszych uprawnień.
- Wymaga interakcji użytkownika, na przykład otwarcia odpowiednio przygotowanej treści internetowej.
- Zakres pozostaje bez zmian, co odpowiada wykonaniu kodu wewnątrz izolowanego środowiska.
- Skutki dla poufności, integralności i dostępności są w tym zakresie ocenione jako wysokie.

CVSS nie informuje, czy exploit jest obecnie wykorzystywany. Temu służy KEV. CISA [dodała CVE-2026-85046 do katalogu KEV](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json) 4 września i wyznaczyła 18 września jako termin naprawy dla agencji federalnych objętych tym wymogiem. Prywatnych firm nie obowiązuje ten federalny termin, ale informacja o aktywnym wykorzystaniu pomaga ustalić priorytet naprawy. Zespół powinien zakończyć dyskusję o tym, czy exploit jest tylko teoretyczny, i przesunąć aktualizację na początek kolejki.

Dla osób zarządzających bezpieczeństwem w startupie płynie z tego prosta zasada: **CVSS pomaga opisać skutki, a KEV ustalić kolejność prac.** Żaden z nich nie oblicza nagrody. Jeśli program ma przyznawać bonus za zgłoszenie z dowodami aktywnego wykorzystania, zapisz tę zasadę w polityce. Ustal ją przed rozpatrywaniem konkretnej nagrody.

## Za co dokładnie wypłacono nagrodę 1000 $ dotyczącą Chrome?

Można potwierdzić tylko, że to ujawniona w komunikacie Chrome nagroda za zgłoszenie Gulizii dotyczące tej CVE. Publiczne dowody nie wskazują dokładnej kategorii VRP, obliczeń ani zawartości poufnego zgłoszenia.

Obowiązujące [zasady Chrome Vulnerability Reward Program](https://bughunters.google.com/about/rules/chrome-friends/chrome-vulnerability-reward-program-rules) pokazują, dlaczego próba odtworzenia sposobu wyliczenia kwoty byłaby ryzykowna. Nagrody są uznaniowe. Google bierze pod uwagę między innymi odtwarzalność, możliwość wykorzystania, jakość zgłoszenia, proponowane sposoby ograniczenia ryzyka oraz oryginalność. Tabela obejmuje kwotę bazową za błędy związane z bezpieczeństwem pamięci, kilka mnożników dotyczących V8 oraz znacznie wyższe, warunkowe bonusy za kwalifikujące się łańcuchy exploitów.

Opublikowane kwoty opisują zasady programu, nie wyliczenie tej konkretnej wypłaty. Nie wiemy, którego wiersza użył Google, czy zastosował korektę ani jakie dowody znalazły się w pierwotnym zgłoszeniu. Nie wiemy też, czy aktywnie wykorzystywany exploit przypominał pracę badacza.

v8CTF wprowadza jeszcze jedno źródło nieporozumień. [Oficjalne zasady](https://github.com/google/security-research/blob/master/v8ctf/rules.md) przewidują 10 000 $ dla pierwszej osoby, która zgłosi prawidłową flagę spełniającą warunki dla wskazanej wersji. Gulizia twierdzi, że zdobył flagę, łącząc tę podatność z n-day sandbox escape. Nie znaleźliśmy publicznego źródła pierwotnego, które potwierdzałoby, że Google uznał flagę lub wypłacił nagrodę. Dodanie 10 000 $ do 1000 $ zamieniłoby możliwą, oddzielną nagrodę w fałszywą sumę.

Rozróżniaj trzy rodzaje materiałów dostarczanych przez badacza:

1. **Zgłoszenie podatności:** jasny i oryginalny opis, który pozwala dostawcy odtworzyć i naprawić problem bezpieczeństwa.
2. **Prymityw exploita:** niezawodna możliwość, taka jak kontrolowany dostęp do pamięci, która otwiera drogę do dalszego wykorzystania.
3. **Pełny łańcuch:** elementy potrzebne do przekroczenia istotnych granic bezpieczeństwa i uzyskania końcowego efektu.

Programy często wyceniają je inaczej, ponieważ wymagają różnego nakładu pracy i dowodzą innych skutków. Na ostateczną kwotę mogą też wpływać jakość zgłoszenia, nowość, sposoby ograniczenia ryzyka, to, czy zgłoszenie było duplikatem, zakres i bonusy zdefiniowane przez program. Właśnie dlatego sam poziom ważności nie może być ceną.

## Jak startup powinien ustalać wysokość nagrody?

Prowadź cztery oddzielne rejestry. Każdy ma inną osobę odpowiedzialną, standard dowodowy i rezultat. Dzięki temu sam poziom ważności nie przesądzi o pilności i kwocie nagrody.

### 1. Oceń techniczny poziom ważności

Odtwórz problem i zapisz, która granica została przekroczona. Uwzględnij wymagane uprawnienia, potrzebną interakcję, podatny zasób oraz wpływ na poufność, integralność i dostępność. Zapisz również, której granicy **nie** przekroczono. W tym przypadku „wewnątrz izolowanego środowiska” jest równie ważne jak „wykonanie dowolnego kodu”.

Nie zostawiaj samego wyniku CVSS. Zachowaj wektor i uzasadnienie, aby kolejny recenzent mógł sprawdzić, skąd wziął się wynik.

### 2. Ustal pilność naprawy

Połącz poziom ważności z bieżącą ekspozycją i informacjami o zagrożeniu. Zasoby dostępne z internetu, dostępny kod exploita, aktywne wykorzystanie i wpis w KEV mogą nadać zgłoszeniu wyższy priorytet niż technicznie podobnemu problemowi. To decyzja o reakcji. Może zmieniać się szybko wraz z nowymi informacjami.

Pilność nie powinna po cichu zmieniać tego, co zgłosił badacz. Jeśli aktywne wykorzystanie pojawi się po zgłoszeniu, przyspiesz naprawę i zapisz nowy sygnał. Przyznaj bonus tylko wtedy, gdy pozwala na to opublikowana polityka albo osoba z odpowiednimi uprawnieniami wprost zatwierdzi uznaniowy wyjątek.

### 3. Oceń materiały dotyczące exploita

Zapisz to, co rzeczywiście dostarczył badacz, a nie to, co zespół opracował później. Wystarczy zwięzły podział:

| Rezultat | Co zapisać |
|---|---|
| Odtworzenie | Kroki, podatna wersja, oczekiwane i zaobserwowane zachowanie |
| Proof of concept | Niezawodność, ograniczenia, awarie, kontrolowane skutki |
| Prymityw exploita | Uzyskana możliwość i nienaruszona jeszcze granica bezpieczeństwa |
| Pełny łańcuch | Każdy element, przekroczona granica, efekt od początku do końca |
| Wkład w ograniczenie ryzyka | Pomysł na poprawkę, analiza obejścia lub sprawdzone rozwiązanie tymczasowe |

Taki zapis zapobiega późniejszemu przypisywaniu badaczowi innego wkładu niż rzeczywiście wniósł. Daje też uzasadniony powód, by dwie podatności o tym samym poziomie ważności umieścić w różnych miejscach przedziału nagrody.

### 4. Omów i zatwierdź wypłatę

Zacznij od opublikowanego przedziału dla danego poziomu. Następnie porównaj rezultat, jakość, oryginalność i bonusy zapisane w zasadach programu. Przedstaw kwotę wraz z uzasadnieniem. Jeśli recenzent się nie zgadza, powinien podać kwotę alternatywną, a nie tylko oddać głos przeciw. Na końcu niech nagrodę zatwierdzi wskazana osoba z odpowiednimi uprawnieniami.

Rejestr decyzji powinien odpowiadać na pięć pytań:

- Która polityka i który przedział poziomu ważności miały zastosowanie?
- Co dostarczył autor zgłoszenia?
- Które czynniki przesunęły propozycję w ramach przedziału?
- Jakie alternatywy rozważyli recenzenci?
- Kto i kiedy zatwierdził ostateczną kwotę?

Uzasadnienie warto ustalić przed zatwierdzeniem wypłaty. Po zatwierdzeniu nagroda staje się obietnicą złożoną na zewnątrz. Wewnętrzne ustalenia powinny do tego czasu pozostać otwarte na zmianę. Przewodnik po [nagrodach i wypłatach](/docs/bounties-and-payouts) opisuje moment, w którym narada staje się zobowiązaniem finansowym.

## Dlaczego pilność naprawy i uczciwość nagrody wymagają oddzielnych rejestrów?

Aktywnie wykorzystywana podatność powinna trafić do pilnej naprawy. Nie oznacza to, że sygnał o zagrożeniu ma automatycznie zmieniać nagrodę. Uczciwość wymaga zastosowania znanych reguł do rzeczywistego wkładu badacza i rzetelnego zapisania wyjątków.

W przypadku Chrome widać wszystkie cztery kwestie. Podatność była technicznie poważna. Aktywne wykorzystanie sprawiało, że poprawka była pilna. Publiczne dowody opisują prymityw ograniczony przez izolowane środowisko oraz oddzielny n-day sandbox escape użyty w łańcuchu badawczym. Google ujawnił nagrodę w wysokości 1000 $, nie ujawniając sposobu jej wyliczenia. Nie wynika z tego, że Google wycenił aktywnie wykorzystywane przejęcie przeglądarki na 1000 $. Publicznie dostępne fakty nie pozwalają sprowadzić tych ocen do jednej decyzji.

Jeśli zespół dopiero buduje kanał przyjmowania zgłoszeń, określa zakres, safe harbor i oczekiwania dotyczące odpowiedzi, zacznij od [programu ujawniania podatności](/blog/how-to-set-up-vulnerability-disclosure-program). Proces obsługi nagród nie naprawi kanału, w którym giną dowody albo badacze nie wiedzą, czego się spodziewać.

## Jak Kit zapobiega automatycznemu przeliczaniu poziomu ważności na cenę?

W Kit proces nagród obejmuje przedziały kwot, niezależne oceny, uzasadnienie i zatwierdzenie przez człowieka.

Kit przechowuje minimalną i maksymalną kwotę dla każdego poziomu ważności. Ocena zapisuje migawkę sugerowanego przedziału, a jego maksimum ogranicza propozycje, kwoty alternatywne i nagrody. Jeśli w migawce nie ma maksimum, Kit korzysta z bieżącej górnej granicy danego poziomu. Jeżeli program z macierzą nagród nadal nie ma możliwego do ustalenia limitu, operacja finansowa zostaje bezpiecznie zablokowana.

Przy nieoczywistej nagrodzie członek zespołu może utworzyć propozycję nagrody z uzasadnieniem przechowywanym w postaci zaszyfrowanej. Głosowanie jest domyślnie prowadzone w ciemno, więc zwykli recenzenci nie widzą nazwisk, stanowisk ani kwot alternatywnych przed oddaniem własnego głosu. Sprzeciw wymaga podania dodatniej kwoty alternatywnej. Wynik głosowania pomaga osobie zatwierdzającej, ale ma charakter doradczy. Nie ma automatycznego kworum, reguły konsensusu ani mechanizmu, który sam zatwierdza wypłatę.

Ostateczna kwota wynika z decyzji zespołu. Kit obecnie **nie** pobiera danych CVE, NVD, CISA KEV ani EPSS. Nie oblicza nagród na podstawie CVSS lub stanu wykorzystania podatności. Nie ma zewnętrznej bazy porównawczej nagród, nie klasyfikuje prymitywu ani wyjścia z izolowanego środowiska i nie przechowuje niezmiennej wersji macierzy nagród lub polityki z momentu wysłania zgłoszenia. Przedział zapisany podczas oceny jest migawką, ale powstaje później niż zgłoszenie.

Uwzględnij te ograniczenia przy planowaniu procesu. Oprogramowanie może zachować dane wejściowe, ograniczyć wpływ pierwszej widocznej kwoty, wymusić limit i zapisać decyzję. Nie potrafi zamienić poziomu ważności w obiektywną cenę. Jeśli chcesz uporządkować sporne nagrody, zobacz, jak działają [propozycje nagród i głosowanie zespołu](/docs/bounty-proposals), i sprawdź, czy taki sposób podejmowania decyzji odpowiada twojemu programowi.

Praktyczna zasada jest prosta: oceń błąd, nadaj naprawie priorytet, sklasyfikuj dostarczone dowody i omów kwotę, zanim stanie się obietnicą. Dzięki czterem oddzielnym rejestrom zaskakującą kwotę będzie można wyjaśnić na podstawie zapisanych decyzji.

<div class="blog-inline-cta">
  <p><strong>Zadbaj, by decyzję o nagrodzie można było prześledzić.</strong> Kit łączy przedziały nagród według poziomu ważności, uzasadnienie propozycji, głosowanie w ciemno, kwoty alternatywne i zatwierdzenie przez człowieka w jednym procesie CSIRT.</p>
  <p><a href="/users/sign_up">Rozpocznij bezpłatny okres próbny</a></p>
</div>