Kontekst
W marcu 2026 wysłałem do CERT Polska swoje pierwsze zgłoszenie podatności z wnioskiem o obsługę procesu CVE. Zgłoszenie dotyczyło kodu projektu open-source, dlatego przed publikacją szczegóły techniczne musiały zostać ograniczone do koordynatora i producenta.
Po zakończeniu koordynacji CERT Polska opublikował advisory dla LMS (LAN Management System), a podatności zostały opisane jako CVE-2026-40455, CVE-2026-40456 i CVE-2026-40457. Ten wpis zostawiam jako krótką retrospektywę procesu, nie jako techniczny opis payloadów.
Czym jest responsible disclosure?
Responsible disclosure polega na tym, że odkrywca podatności przekazuje informacje w sposób kontrolowany, zanim szczegóły trafią publicznie. W praktyce oznacza to:
- zgłoszenie problemu do producenta lub zaufanego koordynatora,
- czas na analizę, klasyfikację i przygotowanie poprawki,
- publikację informacji dopiero po zakończeniu uzgodnionego procesu.
Celem nie jest samo zdobycie identyfikatora CVE. Ważniejsze jest to, aby użytkownicy mieli dostęp do poprawki lub jasnej informacji o podatnych wersjach, a techniczne szczegóły nie przyspieszały nadużyć przed zakończeniem koordynacji.
Dlaczego CERT Polska?
CERT Polska pełni rolę zaufanego koordynatora disclosure. W takim procesie pomaga uporządkować komunikację, klasyfikację podatności, kontakt z projektem oraz moment publicznego ujawnienia.
W moim przypadku istotne było też rozdzielenie dwóch etapów: prywatnego raportu technicznego oraz publicznej notatki, która opisuje root cause i poprawkę bez publikowania instrukcji nadużycia.
Po publikacji
Po publikacji advisory przygotowałem osobne raporty dla poszczególnych CVE. Każdy opis skupia się na przepływie danych, warunkach eksploatacji, ograniczeniach CVSS i commicie naprawczym. To podejście jest bardziej użyteczne niż publikowanie gotowych payloadów: pokazuje przyczynę błędu, ale nie skraca drogi do nadużycia.