Problem cichej łatki: dlaczego „załatane” nie znaczy „ujawnione”

Cicha łatka to poprawka luki bezpieczeństwa, która trafia do wydania bez CVE, bez opublikowanego advisory (biuletynu bezpieczeństwa) i bez powiadomienia osoby, która ją zgłosiła. Z perspektywy zespołu broniącego cicha łatka niczym nie różni się od braku poprawki: nie możesz się na nią powołać, zweryfikować jej ani stwierdzić, czy zawiera ją wersja, której używasz. Pełne ujawnienie to nie tylko scalony kod. To build z poprawką i konkretnym numerem wersji, identyfikator CVE, opublikowane advisory, powiadomienie zgłaszającego i publiczne uznanie autorstwa. Pomiń te elementy, a „załatane” staje się prywatną deklaracją, a nie realnym efektem dla bezpieczeństwa.

Większość programów ujawniania podatności (VDP) traktuje scalony pull request jako metę. To dopiero półmetek. Połowa „zgłoś i nagródź” — przyjęcie, triaż, nagroda — dostaje całą uwagę i całe oprzyrządowanie. Połowa „napraw i ujawnij” — ta część, która zaczyna się po naprawieniu kodu — to miejsce, w którym nawet sumienne programy niezauważenie zawodzą. Oto ta właśnie historia, opowiedziana na najwyraźniejszym z ostatnich przykładów, gdy coś poszło nie tak.

Poprawka Cursora, której nikt nie mógł zweryfikować

W lipcu 2026 roku doniesienia o podatności w Cursorze podzieliły się wokół pytania, które nigdy nie powinno budzić wątpliwości: została załatana czy nie?

Oto co się wydarzyło. 15 grudnia 2025 roku firma Mindgard, specjalizująca się w bezpieczeństwie AI, zgłosiła na adres [email protected] lukę pozwalającą na wykonanie kodu w środowisku Cursor na Windowsie. Mechanizm jest paskudny w swojej prostocie: złośliwy plik git.exe podłożony w katalogu głównym sklonowanego repozytorium uruchamia się automatycznie w chwili otwarcia projektu. Cursor wywołuje git rev-parse --show-toplevel, a ponieważ kolejność wyszukiwania w Windowsie sprawdza katalog roboczy przed ścieżkami systemowymi, zamiast prawdziwego Gita uruchamia się binarka atakującego — z uprawnieniami programisty i bez żadnego pytania o zgodę. Mindgard potwierdził podatność aż do wersji Cursor 3.2.16, testowanej 30 kwietnia 2026 roku.

Potem zgłoszenie ucichło. Według kalendarium Mindgard prośby o aktualizację statusu z lutego, marca i kwietnia 2026 roku pozostały bez odpowiedzi. 1 czerwca 2026 roku Mindgard zasygnalizował, że opublikuje szczegóły. Zrobił to 14 lipca 2026 roku — pełne opracowanie techniczne, 213 dni po pierwszym zgłoszeniu.

Dopiero wtedy rzecznik Cursora powiedział serwisowi Dark Reading, że firma „zajęła się problemem 13 lipca 2026 roku” i skontaktuje się z Mindgard. Tyle że ta rzekoma poprawka nie wskazywała żadnej załatanej wersji, nie miała opublikowanego advisory i nie niosła ze sobą żadnego CVE. Serwis The Hacker News przejrzał opublikowane advisory bezpieczeństwa Cursora i na 15 lipca nie znalazł żadnego wpisu dotyczącego tego problemu. Cursor 3.11 ukazał się 10 lipca — przed rzekomą poprawką z 13 lipca — więc ostatnia publiczna wersja, na którą ktokolwiek mógł wskazać, jej nie zawierała.

Właśnie dlatego poważne media opisywały ten błąd jako wciąż niezałatany, nawet po tym, jak producent oświadczył, że został naprawiony. Obie wersje były „prawdziwe”, bo poprawka istniała wyłącznie jako niemożliwe do zweryfikowania zapewnienie. Łatka, na którą nikt nie może się powołać, której nie da się potwierdzić ani przypisać do konkretnej wersji, w praktyce nie jest łatką. Ta sprzeczność to cała lekcja.

Czym jest cicha łatka?

Cicha łatka to poprawka, która usuwa lukę istotną z punktu widzenia bezpieczeństwa, ale nigdy nie jest przedstawiana jako sprawa bezpieczeństwa: bez CVE, często bez advisory, czasem ukryta w niezwiązanym wydaniu. Kod się zmienia; świat nigdy nie dowiaduje się, co zmieniono ani dlaczego. Pełne ujawnienie ma za to pięć elementów:

1. Build z poprawką i konkretnym numerem wersji. „Naprawione w 3.12.0”, a nie „naprawione”.
2. Identyfikator CVE, żeby luka miała stałą, wyszukiwalną nazwę.
3. Opublikowane advisory opisujące podatność, wersje, których dotyczy, i sposób jej złagodzenia.
4. Powiadomienie zgłaszającego, że poprawka trafiła do wydania.
5. Publiczne uznanie autorstwa dla badacza, który ją znalazł.

Pomiń którykolwiek z nich, a użytkownicy nie odpowiedzą na jedyne pytanie, które ich obchodzi: czy jestem bezpieczny i w której wersji?

Dlaczego producenci to robią — od niewinnych powodów po interesowne

Powody układają się w całe spektrum. Na niewinnym krańcu: opiekun projektu nigdy nie zdał sobie sprawy, że błąd ma wymiar bezpieczeństwa, albo maleńki zespół nie ma procesu, żeby wystąpić o CVE i napisać advisory. Na krańcu interesownym: niechęć do publicznego przyznania, że luka istniała, strach o wizerunek albo nadzieja, że po cichu naprawiony problem sam zniknie.

Intencja nie zmienia rezultatu. Niezależnie od tego, czy cisza bierze się z przeciążonego opiekuna projektu, czy ze zdenerwowanego działu PR, zespół broniący po drugiej stronie dostaje to samo: poprawkę, której nie widzi.

Dlaczego cicha łatka pomaga atakującym, a nie tobie

Cicha łatka nie chroni użytkowników. Daje atakującym przewagę nad nimi. To część wbrew intuicji i warto powiedzieć ją wprost.

Jak ujął to Tod Beardsley z Rapid7: „kiedy łatasz po cichu, przekazujesz szczegóły podatności wyłącznie wprawnym, przestępczym atakującym”. Oto ta asymetria. Kiedy poprawka trafia do publicznego repozytorium, zmotywowani atakujący porównują wersję z poprawką i bez niej (diff), odtwarzają lukę na podstawie zmiany i przekuwają ją w działający exploit — często w ciągu kilku dni. Taka praca jest w pełni w zasięgu każdego kompetentnego przeciwnika, który celowo czyta historię commitów.

Zespoły broniące tego nie robią. Nie poddają inżynierii wstecznej każdego cichego commitu w każdej zależności. Polegają na advisory, które mówi im, co się zmieniło i czy to ma znaczenie. Cicha łatka wytycza więc wyraźną granicę: luka staje się w pełni widoczna dla niewielkiej grupy gotowej jej szukać, a pozostaje niewidoczna dla ogromnej rzeszy, która załatałaby ją, gdyby tylko ktoś jej powiedział. Ludzie, którzy aktualizują zgodnie z harmonogramem, czytają advisory, robią wszystko jak trzeba — to właśnie oni zostają bez ochrony, podczas gdy „powiadomieni” są atakujący.

Cisza nie kupuje bezpieczeństwa przez zaciemnianie. Kupuje atakującemu przewagę na starcie.

Połowa cyklu życia, o której wszyscy zapominają

Większość zespołów modeluje cykl życia ujawnienia jako: zgłoszenie → triaż → naprawa. Pełny model ma jeszcze trzy kroki doczepione na końcu: → CVE → advisory → powiadomienie. Ten ogonek to nie uprzejmość. Kodyfikują go normy.

Normy ISO/IEC 29147 (ujawnianie podatności) oraz ISO/IEC 30111 (obsługa podatności) definiują obowiązki producenta, a opublikowane advisory jest wprost jednym z nich: opis podatności, wersji, których dotyczy, oraz sposobu jej złagodzenia — najlepiej w czytelnym dla maszyn formacie CSAF 2.0, żeby skanery i zespoły w dalszej części łańcucha mogły je przetworzyć automatycznie. W skoordynowanym ujawnieniu advisory publikuje się równolegle z poprawką lub krótko po niej. „Nigdy” nie jest opcją przewidzianą przez normę.

Są też zegary i mierzą całą drogę do publicznego ujawnienia, a nie tylko scalenie kodu:

To przyjęte w branży uczciwe terminy. Mierzone którymkolwiek z nich, zgłoszenie potwierdzone w grudniu i wciąż pozbawione advisory czy CVE w kolejnym lipcu nie jest „w toku”. Jest spóźnione według każdego istniejącego, opublikowanego punktu odniesienia.

CVE nie jest opcjonalne, a producenci nadają je sami

Najczęstsza wymówka dla braku CVE — że jego nadanie jest trudne albo reglamentowane — nie wytrzymuje zderzenia z tym, jak system faktycznie działa. Identyfikatory CVE nadają CVE Numbering Authorities (CNA), a wielu producentów jest własnym CNA. Tam, gdzie producent nim nie jest, zewnętrzne CNA, zespoły CERT i platformy takie jak HackerOne mogą nadać je w jego imieniu. Bycie producentem nie jest przeszkodą w zdobyciu CVE — często to najłatwiejsza do niego droga.

Dowodzi tego historia samego Cursora. Inne podatności w Cursorze z 2026 roku dostały CVE i advisory: RCE przez obejście zaufania MCP od Check Point, zero-clickowe RCE przez wstrzyknięcie promptu „DuneSlide” od Cato Networks oraz luki RCE na poziomie systemu operacyjnego opisane przez SecurityWeek. Maszyneria istniała i działała. Po prostu nigdy nie skierowano jej na zgłoszenie dotyczące git.exe. To czyni tę ciszę luką w procesie, a nie luką w możliwościach — wyborem, które zgłoszenia dostają pełną obsługę, a które po cichu się porzuca.

„Załatane, ale nieujawnione” to naruszenie SLA, a nie zamknięte zgłoszenie

Oto nowe ujęcie, które zmienia sposób prowadzenia programu. Większość VDP ma status końcowy oznaczający „naprawiliśmy to”: resolved, fix_verified, closed, paid. Zgłoszenie osiąga go w chwili scalenia poprawki, a ticket znika z tablicy.

Ten status to kłamstwo przez przemilczenie. Zgłoszenie, które jest naprawione, ale nie ma CVE, advisory ani powiadomienia badacza, nie jest zakończone. Jest w stanie naruszenia — pracy badacza, prawa użytkowników do wiedzy, że są narażeni, oraz norm definiujących, czym jest ujawnienie. Zgłoszenie dotyczące Cursora zostało, według słów samego producenta, „załatwione” 13 lipca. Jednocześnie było w stanie naruszenia we wszystkich trzech punktach. Obie rzeczy były prawdziwe, bo „załatwione” i „ujawnione” to różne stany, a śledzono tylko jeden z nich.

Skala skutków unaocznia koszt. Cursor ma ponad milion aktywnych użytkowników dziennie, ponad milion płacących subskrybentów i korzysta z niego ponad 50 000 firm. Każde z nich spędziło całą lukę w ujawnieniu bez możliwości odpowiedzi na pytanie „czy jestem bezpieczny i w której wersji?”, bo odpowiedź nigdy nie została opublikowana. Cicha łatka skaluje swoją szkodliwość do wielkości bazy użytkowników, którą ucisza.

Traktuj „załatane, ale nieujawnione” tak, jak już traktujesz przekroczone SLA na potwierdzenie zgłoszenia: jako naruszenie zapalające się na czerwono, a nie ticket, który po cichu się zamyka.

Checklist ujawnienia, który da się zbudować

Białą plamą, której nie wypełnia żadne relacjonowanie incydentów, jest ta operacyjna: jak sprawić, żeby cichej łatki nie dało się zamknąć jako zrobionej we własnym programie? Oto checklist. Celowo da się go zbudować na tych samych torach, które już śledzą przyjęcie i triaż zgłoszeń.

1. Dodaj status końcowy disclosed. Zgłoszenie nie kończy się na fix_verified; musi przejść przez disclosed. Spraw, żeby blokował zamknięcie tak samo, jak dziś robi to resolved. Nie ma ujawnienia — nie ma „zrobione”.
2. Zainicjuj wniosek o CVE przy fix_verified. Przejście w stan „naprawione” powinno automatycznie zaproponować lub otworzyć wniosek o CVE — do twojego CNA jako producenta albo do zewnętrznego CNA — i zapisać nadany identyfikator w zgłoszeniu. Nie ma identyfikatora — nie ma zamknięcia.
3. Dołącz szablon advisory i krok publikacji. Wykorzystaj ponownie miejsce, w którym publikujesz swoją politykę bezpieczeństwa, żeby opublikować advisory — wersje, których dotyczy, sposób złagodzenia i uznanie autorstwa — w formacie CSAF, żeby maszyny mogły je odczytać. Szablon zamienia „napisz advisory” z pustej kartki w formularz.
4. Nałóż na to zegar ujawnienia. Dodaj SLA ujawnienia — „advisory opublikowane w ciągu N dni od fix_verified” — i przepuść je przez tę samą maszynerię stanów zagrożone i naruszone, której już używasz do potwierdzeń. Przekroczenie N dni staje się naruszeniem na tablicy, wysłanym na dyżur, a nie niewidzialnym zamkniętym ticketem.
5. Połącz uznanie autorstwa z powiadomieniem. Powiąż uznanie autorstwa badacza w advisory ze swoją ścieżką Hall of Fame i reputacji, i wyślij wiadomość „twoje zgłoszenie jest teraz publiczne” przez istniejącą księgę komunikacji z badaczami. Pętla zamyka się z osobą, która ją otworzyła.

Uruchom to, a zgłoszenie fizycznie nie może osiągnąć stanu „zrobione”, dopóki jest cichą łatką. Tablica statusów wymusza ujawnienie tak samo, jak już wymusza triaż.

Jak Kit trzyma cichą łatkę z dala od tablicy

Obszar CSIRT w Kit już prowadzi połowę „zgłoś i nagródź” programu VDP na torach SLA, a to dokładnie ten fundament, którego potrzebuje połowa poświęcona ujawnieniu. Żeby jasno oddzielić to, co jest już gotowe, od tego, co artykuł proponuje: SLA na potwierdzenie i na naprawę zależną od poziomu ważności, maszyneria stanów zagrożone i naruszone, eskalacja na dyżur, podlegające audytowi przejścia statusów, synchronizacja zgodności w dół łańcucha i ścieżka uznania autorstwa w Hall of Fame — to wszystko działające funkcje. Kit nie miał nic wspólnego z błędem w Cursorze i żadne narzędzie nie powstrzyma producenta przed napisaniem złego kodu.

To, co architektura Kit rzeczywiście daje, to fundament, który strukturalnie utrudnia ukrycie cichej łatki:

• Zegary SLA ze stanami zagrożone i naruszone, stosowane już do celów potwierdzenia i naprawy zależnej od poziomu ważności. Ten sam mechanizm zegara jest tym, na czym działa SLA ujawnienia: „advisory opublikowane w ciągu N dni” płynie tą samą ścieżką naruszenia.
• Eskalacja na dyżur, żeby ześlizgujący się zegar wzywał człowieka, zamiast po cichu się starzeć — to różnica między zgłoszeniem Cursora leżącym bez odpowiedzi całymi miesiącami a naruszeniem, które wychodzi na wierzch.
• Podlegające audytowi przejścia statusów dla każdego zgłoszenia, więc dodanie stanu disclosed, który blokuje zamknięcie, to rozszerzenie istniejącego cyklu życia, a nie nowy system.
• Synchronizacja zgodności w dół łańcucha i ścieżka uznania autorstwa w Hall of Fame, żeby uznanie autorstwa badacza w advisory i powiadomienie „jesteś teraz publiczny” jechały po już istniejących torach.

Cicha łatka to, strukturalnie, naruszenie SLA, którego nie mierzy żadne obecne narzędzie. Kit już mierzy naruszenia SLA. Skierowanie tej samej dyscypliny na ujawnienie to właściwe posunięcie — i miejsce na to jest na tej samej tablicy, która śledzi potwierdzenia i triaż.

Wniosek: ujawnienie to przejście statusu, a nie scalenie

Program ujawniania podatności nie kończy się w chwili wydania poprawki. „Załatane, ale nieujawnione” to naruszenie zgłoszenia, pracy badacza i prawa użytkowników do wiedzy — i powinno zapalać się na czerwono na tej samej tablicy, która śledzi potwierdzenia i triaż.

Historia Cursora to nie jednorazowy skandal. To domyślny sposób, w jaki zawodzi każdy program, którego cykl życia po cichu kończy się na „scalone”. Rozwiązaniem nie jest większa staranność w naprawianiu — te zespoły i tak naprawiają sumiennie. Rozwiązaniem jest traktowanie CVE, advisory, powiadomienia i uznania autorstwa jako wymaganych przejść statusu, przez które zgłoszenie musi przejść, zanim będzie można nazwać je zrobionym.

Jeśli dopiero budujesz proces przyjmowania zgłoszeń, zacznij od tekstu jak uruchomić program ujawniania podatności. O tym, co się dzieje, gdy relacja psuje się przed naprawą, przeczytasz w gdy badacze ujawniają sprawę publicznie oraz w naszym spojrzeniu na SLA i uczciwość wypłat w bug bounty. A jeśli sprzedajesz w Europie, obowiązkowe wymogi ujawniania z unijnego Cyber Resilience Act zamieniają krok publikacji advisory z dobrej praktyki w prawo. To zamykający rozdział ich wszystkich: zgłoszenie nie jest zrobione, dopóki nie zostanie ujawnione.