3 sierpnia 2026 oficjalna strona SQLite wymieniała sześć numerów zgłoszeń z adnotacją, że nie opisują żadnego błędu w bibliotece. Tego samego dnia jeden z tych numerów miał w bazie podatności GitHuba ocenę 9,8 na 10 punktów. W tym samym wpisie pola z wersjami, których problem dotyczy i w których został naprawiony, wypełniono słowem “nieznane”. Firma JFrog sprawdziła dostarczone dowody i żaden nie doprowadził do awarii. Autor SQLite napisał na forum projektu, że nowe zgłoszenia przeciwko jego bibliotece można dziś prawdopodobnie uznać za fałszywe. Tak wyglądają fałszywe CVE, które przeszły przez proces i wyglądają w skanerze jak każde inne.
Dowody, które nie odtwarzają żadnej awarii
Zgłoszenia pochodzą z nowego repozytorium programmervuln/cveadvisory- na GitHubie. Według analizy JFrog Security Research opublikowano tam 55 opisów podatności, a firma uznała 54 z nich za wygenerowane przez model językowy.
Techniczna część tej analizy jest mocniejsza niż jakikolwiek detektor. Badacze wzięli dołączone dowody, czyli fragmenty kodu, które mają wywołać błąd, i po prostu je uruchomili. Nic się nie stało, żadna awaria nie wystąpiła. Potem sięgnęli do samego kodu SQLite. Opisywane funkcje albo nie istnieją w wymienionych wersjach, albo robią coś zupełnie innego niż w opisie. Zgłoszenia brzmiały wiarygodnie, bo używały prawidłowej terminologii i prawidłowej struktury. Rozsypywały się dopiero przy próbie sprawdzenia.
Wniosek o autorstwie wart jest jednak ostrożniejszego potraktowania niż reszta. JFrog opiera go między innymi na detektorze treści generowanych przez AI, a takie narzędzia dają wynik prawdopodobny, nie rozstrzygający. Kto to napisał i po co, nie zostało ustalone. Pewne jest natomiast to, że dowody nie odtwarzają awarii.
Twórca SQLite: nowe zgłoszenia można uznać za nieprawdziwe
Richard Hipp, autor biblioteki, odniósł się do sprawy na forum projektu 29 lipca. Napisał, że dostał od analityków bezpieczeństwa informacje o wielu dziesiątkach sfabrykowanych zgłoszeń. Wyrywkowe sprawdzenie nie wykazało wśród nich ani jednego prawidłowego. Zakończył zdaniem, którego zwykle nie pisze się o własnym projekcie: “If you see new CVEs against SQLite, you can probably assume they are fake”. Po polsku: nowe zgłoszenia przeciwko SQLite można z dużym prawdopodobieństwem uznać za fałszywe.
3 sierpnia na oficjalnej stronie projektu poświęconej podatnościom przy sześciu numerach widniała krótka adnotacja: “Not a bug in SQLite. These are unreproducible. They appear to be AI hallucinations”. Czyli: to nie jest błąd w SQLite, zgłoszeń nie da się odtworzyć i wyglądają na halucynacje sztucznej inteligencji. Halucynacja to w żargonie AI odpowiedź, która brzmi poprawnie i jest zmyślona.
Ta sama strona zawiera zresztą akapit starszy niż cała sprawa, wart przeczytania przez każdego, kto układa priorytety łatania. Twórcy piszą wprost, że nie śledzą CVE i że nie należy zakładać, iż zgłoszenie o SQLite zawiera wiarygodne informacje. Powód podają prozaiczny: badacze bywają rozliczani z liczby i wagi znalezionych podatności, więc opisy potrafią wyolbrzymiać rzeczywisty wpływ.
Ten sam numer, dwie różne oceny
Warto zobaczyć, jak jedno zgłoszenie wygląda w różnych miejscach tego samego dnia. W bazie podatności GitHuba wpis z 27 lipca opisuje użycie pamięci po jej zwolnieniu w mechanizmie obliczania wyrażeń w SQLite 3.41. Ocena 9,8, atak przez sieć, bez wymaganych uprawnień i bez udziału użytkownika. Status wpisu przy sprawdzeniu 3 sierpnia brzmiał “Unreviewed”, czyli niezweryfikowany, a wersje objęte i naprawione miały wartość “Unknown”.
Ten sam numer u Red Hata wygląda inaczej. Dystrybutor podaje ocenę 7,6 wobec 9,8 w rejestrze cve.org i dodaje notatkę, że problem nie dotyczy jego produktów. Napisał też, że sam projekt SQLite potwierdził fikcyjny charakter zgłoszenia. Według Red Hata jego klienci nie potrzebują łatek ani errat, a wynik skanera dla tego numeru mogą potraktować jako fałszywy alarm.
Z tego zestawienia płynie wniosek wart zapamiętania. W tym przypadku różni analitycy przypisali temu samemu numerowi różne metryki i różne wyniki końcowe. Red Hat robi to jawnie, bo uwzględnia własny kontekst produktowy. Liczba ze skanera jest więc wynikiem czyjejś oceny w konkretnych warunkach, a nie odczytem z termometru.
Wpis w bazie GitHuba
Hipp opisał przy okazji rzecz, która według niego tłumaczy, dlaczego problem się utrzymuje. Jego zdaniem zgłoszenie da się zarejestrować praktycznie w dowolnym momencie i bez weryfikacji, a wycofanie go wymaga już udowodnienia, że jest nieprawdziwe. To jego ocena procesu, nie ustalenie, więc traktujmy ją jako głos poszkodowanego. Sprawdzalny jest natomiast jeden fakt: 3 sierpnia omawiany wpis nadal widniał w bazie GitHuba ze statusem “Unreviewed”, czyli bez przeglądu po stronie serwisu.
Pierwsza Misja AI · Kodożercy
Rozumiesz zagrożenia AI, gdy rozumiesz jak naprawdę działa.
Kurs Pierwsza Misja AI ma dedykowaną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja. Zanim zaczniesz się bać, zacznij rozumieć.
Poznaj pełny program →
Co to zmienia w kolejce łatania
Tu dochodzimy do sedna. W procesach, które priorytetyzują zgłoszenia automatycznie według wyniku, wysoka ocena może wywindować wpis na górę kolejki, zanim ktokolwiek go przeczyta. JFrog pisze o tym warunkowo i słusznie, bo nie każdy zespół pracuje w ten sposób.
Skala robi się namacalna, gdy spojrzeć, gdzie siedzi SQLite. Ta biblioteka jest w telefonach, przeglądarkach, aplikacjach mobilnych i w wielu narzędziach, o których nikt nie myśli jak o bazie danych. Sam projekt zastrzega, że dokładnych liczb nie da się ustalić, ale rozpowszechnienie jest ogromne. Fałszywe CVE dla takiego składnika może więc generować pracę w wielu miejscach naraz, a każde z nich może wymagać osobnej weryfikacji.
Wniosek praktyczny jest niewielki i tani. Zanim zgłoszenie o wysokiej ocenie wskoczy na szczyt listy, warto zajrzeć na stronę producenta komponentu. Przy SQLite zajmuje to minutę, bo projekt prowadzi własną listę. Drugi krok jest równie prosty: sprawdzić, czy dołączony dowód w ogóle się odtwarza. Ta sama zasada wracała przy zgłoszeniach przygotowanych przez AI w programie nagród Apple. Wracała też wcześniej, gdy twórcy bibliotek open source zmienili zasady zgłaszania błędów. Za każdym razem wracało też to samo pytanie: kto ma sprawdzić zgłoszenie, którego nikt nie musiał sprawdzić przed wysłaniem.
Pytania praktyczne
Co oznacza ocena 9,8 w skali CVSS?
CVSS to standard punktowania podatności w skali od 0 do 10, gdzie wynik od 9,0 oznacza poziom krytyczny. W omawianym wpisie 9,8 składa się między innymi z ataku przez sieć, niskiej złożoności, braku wymaganych uprawnień i braku udziału użytkownika. Ta ocena nie jest jednak pomiarem, tylko wynikiem analizy według ustalonego wzoru i przypisanych metryk. Dlatego ten sam numer ma 9,8 w jednym rejestrze i 7,6 u dystrybutora, który policzył go we własnym kontekście.
Czy te zgłoszenia zostały już usunięte z baz?
Przy sprawdzeniu 3 sierpnia 2026 wpis dla jednego z omawianych numerów wciąż wisiał w bazie podatności GitHuba ze statusem niezweryfikowanym. Oficjalna strona SQLite oznaczała wtedy sześć numerów jako niemożliwe do odtworzenia, a Red Hat opisywał jeden z nich jako fikcyjny. Przed decyzją o łataniu warto więc sprawdzić opis w tej bazie, z której korzysta konkretny skaner.
Podsumowanie
3 sierpnia strona projektu SQLite wymieniała sześć numerów zgłoszeń jako nieodtwarzalne i wyglądające na halucynacje sztucznej inteligencji. JFrog przebadał je razem z pozostałymi opisami z tego samego repozytorium i uznał 54 z 55 za wygenerowane przez model językowy. Dołączone dowody nie odtwarzają awarii. Red Hat podaje dla jednego z tych numerów ocenę 7,6 wobec 9,8 w rejestrze cve.org i nazywa zgłoszenie fikcyjnym. Ten sam wpis 3 sierpnia nadal widniał w bazie GitHuba bez przeglądu, a Richard Hipp tłumaczy taką asymetrię tym, że zarejestrowanie zgłoszenia jest łatwiejsze niż jego wycofanie. Dla zespołu, który priorytetyzuje naprawy według liczby ze skanera, płynie stąd jeden praktyczny wniosek. Przy zaskakująco wysokiej ocenie pierwszy krok to sprawdzenie, czy producent komponentu w ogóle o tym problemie wie.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
