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

Cicha łatka usuwa lukę bezpieczeństwa, ale nie informuje użytkowników, czego dotyczy zmiana i w której wersji ją znajdą. Kod może być już poprawiony, a zespół odpowiedzialny za aktualizację nadal nie wie, czy powinien pilnie wdrożyć nowe wydanie.

Po naprawie trzeba więc zaplanować komunikację: wskazać wersje objęte problemem, opisać sposób usunięcia zagrożenia i odpowiedzieć badaczowi. Identyfikator CVE ułatwia śledzenie podatności, jeśli dany przypadek kwalifikuje się do jego nadania. Publiczne wyróżnienie badacza wymaga uzgodnienia, czy i pod jaką nazwą chce wystąpić.

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

W lipcu 2026 roku pojawiły się sprzeczne doniesienia o tym, czy podatność w Cursorze została naprawiona.

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 polega na tym, że 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ę plik wykonywalny atakującego, z uprawnieniami programisty i bez pytania o zgodę. Mindgard potwierdził podatność aż do wersji Cursor 3.2.16, testowanej 30 kwietnia 2026 roku.

Potem badacz nie otrzymywał odpowiedzi. 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 ukazało się 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. W tej wypowiedzi nie wskazano wersji z poprawką ani opublikowanego biuletynu bezpieczeństwa, ani identyfikatora CVE. Serwis The Hacker News przejrzał opublikowane biuletyny bezpieczeństwa Cursora i na 15 lipca nie znalazł żadnego wpisu dotyczącego tego problemu. Cursor 3.11 ukazał się 10 lipca, przed deklarowaną naprawą z 13 lipca. Same daty nie pozwalały ustalić, w której publicznej wersji znalazła się poprawka.

Brak numeru poprawionej wersji pozostawił czytelników ze sprzecznymi informacjami: producent deklarował naprawę, a media nadal opisywały problem jako niezałatany. Nie dowodzi to, że kod pozostał podatny. Pokazuje natomiast, że komunikat producenta nie dawał użytkownikom wystarczających danych do sprawdzenia własnej instalacji.

Co powinien zawierać komunikat o poprawce

Biuletyn bezpieczeństwa, często nazywany advisory, powinien pozwolić użytkownikowi ustalić, czy problem go dotyczy i co ma zrobić. Przygotuj:

1. Numer wersji z poprawką. Na przykład „naprawione w 3.12.0”, zamiast samego „naprawione”.
2. Identyfikator CVE, jeśli został nadany. Ułatwia powiązanie komunikatów producenta, skanerów i dostawców zależności.
3. Opis podatności i działania dla użytkownika. Wersje objęte problemem, aktualizacja lub tymczasowe ograniczenie ryzyka.
4. Odpowiedź dla zgłaszającego. Informacja o wydaniu poprawki i planowanej publikacji.
5. Uzgodnione wyróżnienie badacza. Nazwa wybrana przez badacza, anonimowe podziękowanie albo brak wpisu, zgodnie z jego decyzją.

Brak CVE czy publicznego nazwiska sam w sobie nie oznacza, że poprawka jest nieskuteczna. Problem zaczyna się wtedy, gdy użytkownik nie może ustalić, jakie wersje są podatne i jak usunąć zagrożenie.

Skąd bierze się cisza

Czasem opiekun projektu nie rozpoznaje znaczenia błędu dla bezpieczeństwa. Czasem niewielki zespół nie ma osoby odpowiedzialnej za przygotowanie biuletynu. Zdarza się też obawa przed rozgłosem. Bez danych o konkretnym przypadku nie można rozstrzygnąć, który z tych powodów zadziałał.

Niezależnie od przyczyny warto przypisać publikację konkretnej osobie i uzgodnić termin, zanim zadanie z naprawą zostanie zamknięte.

Kto może odtworzyć błąd z poprawki

Brak komunikatu nie ukrywa zmiany w publicznym kodzie. Jak ujął to Tod Beardsley z Rapid7: „kiedy łatasz po cichu, przekazujesz szczegóły podatności wyłącznie wprawnym, przestępczym atakującym”.

Atakujący może porównać wersję przed poprawką i po niej, odtworzyć podatność oraz spróbować wykorzystać ją w nieaktualnych instalacjach. Zespół utrzymujący wiele zależności zwykle nie analizuje w ten sposób każdego commitu. Korzysta z biuletynów, żeby ustalić priorytet aktualizacji.

Poprawiona wersja nadal chroni użytkowników, którzy ją wdrożyli. Cisza utrudnia dotarcie z informacją do tych, którzy jeszcze tego nie zrobili.

Zaplanuj komunikację po naprawie

Do etapów zgłoszenie → triaż → naprawa dodaj przygotowanie biuletynu i kontakt z badaczem. Ustal też, kto sprawdzi możliwość uzyskania CVE. Normy ISO/IEC 29147 i ISO/IEC 30111 opisują ujawnianie i obsługę podatności. Terminy z polityk zespołów badawczych nie są automatycznie terminami ustawowymi.

Publiczny komunikat może mieć format czytelny dla maszyn, np. CSAF 2.0. Ułatwia to automatyczne przetwarzanie informacji przez odbiorców, ale nie zastępuje dokładnego opisu wersji i działań naprawczych.

Poniżej przykłady terminów spotykanych w politykach ujawniania. Szczegóły, wyjątki i okres między poprawką a publikacją zależą od konkretnej polityki.

Ponad siedem miesięcy bez informacji o wersji z poprawką uzasadnia pytania o przebieg obsługi zgłoszenia. O naruszeniu konkretnego SLA można mówić dopiero po sprawdzeniu uzgodnionych terminów i warunków.

Kto nadaje CVE

Identyfikatory nadają organizacje CVE Numbering Authority (CNA). Producent będący CNA może nadawać je w swoim zakresie. W pozostałych przypadkach można zwrócić się do właściwego zewnętrznego CNA. Nie każdy błąd kwalifikuje się do CVE, a sam brak identyfikatora nie przesądza o naruszeniu prawa.

Inne podatności w Cursorze otrzymały identyfikatory i biuletyny, m.in. problemy opisane przez Check Point i Cato Networks. To pokazuje, że publikowanie takich informacji było możliwe. Nie wyjaśnia jednak, dlaczego zgłoszenie dotyczące git.exe pozostało bez analogicznego komunikatu w opisywanym okresie.

Oddziel naprawę od publikacji

Statusy takie jak resolved, fix_verified, closed i paid opisują różne zdarzenia. Naprawa, jej weryfikacja i wypłata nie potwierdzają, że użytkownicy otrzymali biuletyn. Jeśli system nie śledzi publikacji osobno, łatwo ją przeoczyć.

W przypadku produktu używanego przez ponad milion aktywnych użytkowników dziennie, ponad milion płacących subskrybentów i 50 000 firm, jak w przywoływanych danych o Cursorze, komunikat może dotyczyć wielu instalacji. Nie wynika z tego, że każda była podatna: opisywany błąd dotyczył określonego środowiska i sposobu otwierania projektu.

Ustal więc osobny termin publikacji i osobę odpowiedzialną. Przekroczenie uzgodnionego terminu powinno być widoczne także wtedy, gdy zadanie programistyczne jest już zamknięte.

Propozycja procesu publikacji

Poniższe kroki opisują proces, który można wdrożyć we własnym systemie obsługi zgłoszeń. Nie są listą funkcji dostępnych obecnie w Kit.

1. Dodaj stan disclosed. Po fix_verified sprawdź, czy potrzebny komunikat został opublikowany. Stan disclosed może potwierdzać publikację niezależnie od technicznego resolved.
2. Przy fix_verified sprawdź zasadność CVE. Wyznacz osobę do kontaktu z CNA i zapisz identyfikator albo powód, dla którego nie występujesz o jego nadanie.
3. Przygotuj szablon biuletynu. Uwzględnij podatność, wersje, poprawkę lub obejście oraz uzgodnione podziękowanie. Jeśli odbiorcy potrzebują CSAF, dodaj publikację w tym formacie.
4. Ustal termin publikacji. Możesz liczyć go od fix_verified, jeśli pasuje to do polityki programu. Ustal przypomnienie i odbiorcę eskalacji po przekroczeniu terminu.
5. Powiadom badacza. Przekaż link do biuletynu. Przed publicznym wyróżnieniem potwierdź zgodę i wybraną nazwę.

Zamknięcie zgłoszenia powinno wymagać potwierdzenia tych czynności albo zapisanego, uzasadnionego wyjątku.

Co Kit obsługuje obecnie

Moduł CSIRT w Kit śledzi zgłoszenia, ich statusy oraz SLA na potwierdzenie i naprawę, zależne od poziomu ważności. Pokazuje zagrożone i przekroczone terminy oraz obsługuje eskalację na dyżur. Historia zmian pozwala sprawdzić przebieg pracy, a Hall of Fame służy do publikowania uzgodnionych wyróżnień badaczy.

Kit nie ma obecnie stanu disclosed, automatycznego wniosku o CVE, publikacji biuletynów CSAF ani osobnego SLA na ujawnienie. Opisany wyżej proces wymaga osobnej organizacji lub rozszerzenia narzędzia. Sam status naprawy w Kit nie potwierdza publikacji komunikatu.

Kto odpowiada za ostatni krok

Przy każdej istotnej poprawce ustal, kto przygotuje komunikat, gdzie go opublikuje i jak powiadomi badacza. Dopiero wtedy sprawdź, czy system pozwala tę pracę śledzić. Sama dodatkowa etykieta bez osoby odpowiedzialnej i terminu nie rozwiąże problemu.

Jeśli dopiero organizujesz przyjmowanie zgłoszeń, zacznij od tekstu jak uruchomić program ujawniania podatności. O sporach w trakcie obsługi piszemy w artykułach gdy badacze ujawniają sprawę publicznie oraz SLA i uczciwość wypłat w bug bounty. Przy produktach objętych unijnym CRA sprawdź również obowiązki dotyczące podatności, ich zakres i terminy stosowania. Nie każda rekomendacja dotycząca publicznego biuletynu jest tym samym co ustawowy obowiązek zgłoszenia incydentu.