Fałszywe CVE, raporty generowane przez AI i potrzeba weryfikacji

Tworzenie wiarygodnie wyglądających raportów o podatnościach staje się coraz tańsze, co zwiększa obciążenie osób utrzymujących oprogramowanie i zespołów ds. bezpieczeństwa. W lipcu 2026 r. opublikowano sześć wpisów dotyczących typowych luk i zagrożeń (CVE) w SQLite, a dwa z nich otrzymały ocenę dotkliwości 9,8. Raporty wyglądały na wiarygodne: opisywały błędy związane z bezpieczeństwem pamięci i zawierały wyjaśnienia techniczne oraz kod umożliwiający odtworzenie problemu.

Badacze JFrog odkryli jednak, że niektórych funkcji, do których odnosiły się raporty, nie było w wersjach objętych zgłoszeniami. Co więcej, żadna z prób odtworzenia problemu (PoC) nie pozwoliła zreprodukować opisywanych podatności. Na stronie CVE projektu SQLite można obecnie przeczytać, że tych sześciu zgłoszeń nie uznaje się za błędy; wpisy CVE zostały później odrzucone.

Problem nie ogranicza się do SQLite. Daniel Stenberg, opiekun projektu curl, oszacował w ubiegłym roku, że około 20% napływających zgłoszeń dotyczących bezpieczeństwa było efektem niskiej jakości treści generowanych przez AI. GitHub otrzymał za pośrednictwem swojego organu uprawnionego do nadawania numerów CVE (CNA) prawie 4 000 wniosków o nadanie numeru CVE w maju 2026 r.; to około dziesięciokrotny wzrost liczby zgłoszeń rok do roku. GitHub nie przypisał tego wzrostu AI ani nie odnotował spadku jakości zgłoszeń, ale ogromny wzrost ich liczby uwypukla przeciążenie procesu ujawniania luk w zabezpieczeniach.

AI ułatwia tworzenie szczegółowych zgłoszeń dotyczących podatności, ale ustalenie, czy są one wiarygodne, wymaga czasu. A kiedy CVE trafia do kanałów informacyjnych o bezpieczeństwie i publicznych baz danych, poprawienie pierwotnego wpisu nie oznacza automatycznie, że poprawiona zostanie każda jego kopia. Coraz bardziej potrzebne staje się zatem odróżnianie zgłoszonej podatności od takiej, którą zweryfikowano pod względem technicznym.

Czym jest „fałszywe” CVE?

Określenia „fałszywe CVE” powszechnie używa się w odniesieniu do CVE, które prawdopodobnie zgłoszono błędnie. „Fałszywe” nie znaczy jednak, że ktoś celowo wprowadza w błąd. Przyczyną może być analiza statyczna, która pomija kontrolę poprawności lub błędnie zakłada, że atakujący może kontrolować dane wejściowe. Raport może szczegółowo opisywać rzeczywistą funkcję, a jednocześnie wskazywać nieprawidłową ścieżkę ataku. Identyfikator CVE może zostać nadany, a następnie wycofany, jeśli zgłoszony problem w rzeczywistości nie był podatnością. To co innego niż celowo zmyślony raport.

Spór również nie oznacza, że CVE jest fałszywe. Dostawca może zakwestionować ustalenia badacza dotyczące możliwości wykorzystania podatności, granic zagrożenia lub tego, czy dana funkcja miała przetwarzać niezaufane dane wejściowe. Sam spór nie dowodzi jednak, że badacz popełnił błąd. Odrzucenie CVE nie musi też oznaczać, że zostało ono zmyślone — powodem odrzucenia może być duplikat lub przyczyny administracyjne. Choć identyfikator CVE nie stanowi niezależnej weryfikacji technicznej, branża musi poważnie traktować prawdziwe zgłoszenia.

Dlaczego fałszywe CVE stanowią problem

Jednym z obserwowanych problemów jest wykorzystywanie AI do generowania raportów o podatnościach bez rzetelnej weryfikacji ustaleń. Takie raporty mogą zawierać szczegółowe wyjaśnienia techniczne, odwołania do kodu, a nawet próby odtworzenia problemu (PoC), przez co wyglądają wiarygodnie. Jak pokazały zgłoszenia CVE dotyczące SQLite, niektóre z przywołanych funkcji nie istniały nawet w wersjach objętych zgłoszeniami.

GitHub poinformował o znacznym wzroście liczby zgłoszeń podatności w 2026 r., choć nie przypisał tego wzrostu AI ani nie odnotował pogorszenia jakości zgłoszeń. Obawy budzi to, że wraz ze wzrostem liczby raportów rośnie również nakład pracy potrzebny do ich zbadania — niezależnie od tego, czy opisane w nich ustalenia są prawdziwe.

Osoby zajmujące się wstępną oceną zgłoszeń podatności dobrze znają praktyczne trudności z tym związane. Model AI może wskazać podejrzane wywołanie API, zarysować scenariusz wykorzystania podatności i szybko przygotować profesjonalnie wyglądający raport. Ustalenie, czy taki scenariusz jest wykonalny, może wymagać sprawdzenia konkretnego wydania, prześledzenia przepływu sterowania, poznania sposobu, w jaki dane trafiają do funkcji, przygotowania środowiska testowego i uruchomienia opisywanego exploita. Ten sam proces trzeba przeprowadzić niezależnie od tego, czy raport jest trafny, a może to być kosztowne.

Fałszywe CVE mogą również szkodzić reputacji. Informacja o podatności może szybko rozprzestrzenić się w kanałach z danymi dla skanerów, bazach bezpieczeństwa i wynikach wyszukiwania. Późniejsza korekta może jednak nie dotrzeć równie daleko. Nawet po zakwestionowaniu lub odrzuceniu raportu dostawcy mogą być zmuszeni tłumaczyć się przed klientami, którzy widzieli pierwotną informację.

Istnieje również ryzyko, że rzeczywiste podatności zostaną przeoczone lub ich zbadanie się opóźni, ponieważ zespoły poświęcają czas na analizę błędnych zgłoszeń. Gdy osoby utrzymujące oprogramowanie i zespoły ds. bezpieczeństwa dysponują ograniczonymi zasobami, każda godzina poświęcona na obalenie fałszywego alarmu to czas, który można było przeznaczyć na zbadanie rzeczywistego problemu z bezpieczeństwem.

Automatyzacja jako sposób na rozwiązanie problemu

Wielu analityków nadal ręcznie dokonuje wstępnej oceny zgłoszeń, próbując poradzić sobie z ich nową falą, ale takie podejście nie jest zrównoważone. Automatyzacja może bardzo pomóc w weryfikowaniu zgłoszeń podatności na podstawie rzeczywistego wydania i konfiguracji, których dotyczą. Oto pięć pytań, które należy zadać:

• Czy warunki konieczne do przeprowadzenia ataku są wiarygodne, w tym wymagania dotyczące konfiguracji i uprawnień?
• Czy wskazana funkcja istnieje w wersji objętej zgłoszeniem?
• Czy atakujący może dotrzeć do podatnego kodu? Ustal, czy odpowiedni kod może zostać wykonany w warunkach, w których występuje podatność, oraz czy atakujący może dostarczyć dane wejściowe, które do niego dotrą.
• Czy testerzy mogą odtworzyć to zachowanie w kontrolowanym teście lub za pomocą PoC?
• Czy zaobserwowane zachowanie powoduje skutki dla bezpieczeństwa opisane w komunikacie?

Narzędzia agentowe mogą tworzyć środowiska testowe, analizować ścieżki w kodzie, generować PoC i rejestrować dowody wykonania do weryfikacji. Nie potrafią jednak automatycznie rozstrzygnąć każdego twierdzenia. Nawet jeśli podatność jest autentyczna, PoC może zawieść, gdy środowisko jest niekompletne lub wyzwalacz działa nieprawidłowo. Testerzy mogą odtworzyć awarię, nie dowodząc przy tym, że można ją wykorzystać w sposób opisany w zgłoszeniu. Dlatego ludzki osąd pozostaje niezbędny. Narzędzia te mogą jednak pomóc zespołom szybciej uzyskać odtwarzalny wynik, zanim zgłoszenie pochłonie więcej czasu działów inżynieryjnych, zarządzania podatnościami i obsługi klienta.

Jak poradzić sobie z przytłoczeniem w ekosystemie CVE

Żadna zwięzła polityka nie rozwiąże jak za dotknięciem czarodziejskiej różdżki problemu fałszywych CVE. Pomogłyby jednak wymóg przedstawiania mocniejszych dowodów przy zgłoszeniu oraz jaśniejsze określanie statusu odtworzenia podatności. Przydatne byłoby również bardziej przejrzyste postępowanie ze spornymi wpisami i szybsze korygowanie danych pochodnych. Należy zachęcać badaczy do weryfikowania ustaleń uzyskanych z pomocą AI przed ich zgłoszeniem.

Zespoły ds. bezpieczeństwa i dostawcy muszą skupić się na analizie dowodów. Krytyczna ocena CVE nie informuje, czy w danym środowisku można dotrzeć do podatnej ścieżki. Sam fakt, że PoC nie działa, nie oznacza, że wszystko jest w porządku. Otrzymanie identyfikatora CVE nie zwalnia też zespołów z wykonania pracy technicznej niezbędnej do zrozumienia problemu.

AI zwiększa możliwości wykrywania podatności, a zarazem umożliwia tworzenie wiarygodnie wyglądających, lecz nieprawdziwych twierdzeń. W świecie, w którym liczba zgłoszeń stale rośnie, organizacje muszą inwestować w weryfikację. Obejmuje ona tworzenie testów, odtwarzanie wyników, sprawdzanie założeń i ułatwianie oceny dowodów. To obszar, w którym agentowe testowanie bezpieczeństwa może odegrać istotną rolę.