54 no 55 jauniem SQLite CVE ir izdomāti, NVD tos jau bija novērtējis kā kritiskus

Drošības uzņēmums JFrog paņēma sešus svaigus SQLite ievainojamību ierakstus ar bīstamības vērtējumu no 7,5 līdz 9,8 punktiem un atvēra pirmkodu. Pirmajā aprakstā minētās funkcijas norādītajā versijā vispār nav. Otrajā norādītās koda rindas izrādījās komentārs un atmiņas piešķiršanas izsaukums. Pievienotie uzbrukuma paraugi izpildīja pilnīgi derīgu SQL vaicājumu bez avārijas un bez atmiņas noplūdes.

Kad JFrog pārskatīja visus 55 ierakstus, ko četrās dienās bija iesniedzis viens GitHub repozitorijs, izdomāti izrādījās 54. Vienā bija īsta kļūda ar nepārbaudītiem CVE metadatiem. Pa to laiku šie apraksti NVD datubāzē jau stāvēja ar kritisku statusu un CISA pievienotu papildinājumu.

funkcijas, kuru pirmkodā nav

JFrog analīzē katrs ieraksts izjūk citā vietā:

• CVE-2026-51302, 9,8 punkti: use-after-free funkcijā exprComputeOperands(), kuras SQLite 3.41.0 pirmkodā nav;
• CVE-2026-51303, 9,8 punkti: kļūda funkcijā ExprListDelete(), kurai starp versijām 3.51.2 un 3.51.3 nav nevienas izmaiņas;
• CVE-2026-51300, 9,1 punkts: norādītās rindas ir komentārs un atmiņas piešķiršanas izsaukums;
• CVE-2026-51297, 8,8 punkti: atsauce uz jsonBlobEdit(), kas pirmkodā parādījās tikai 2025. gadā;
• CVE-2026-51296, 7,5 punkti: rindu numuri pārsniedz paša faila garumu;
• CVE-2026-51304, 7,5 punkti: nepareizi funkciju paraksti.

Katram ierakstam bija pievienots uzbrukuma paraugs. JFrog tos palaida. Programma nevienā gadījumā neavarēja.

CNA sistēma strādā uz uzticības principa

CVE numuru piešķir CNA jeb CVE numerācijas iestāde. MITRE un pārējās CNA, kas apkalpo svešu kodu, iesniedzēja darbu nepārbauda. Pieteikuma autoram tiek ticēts, ka viņš pats savu atradumu ir verificējis. Šoreiz līdz JFrog neviens SQLite pirmkodu neatvēra.

Tālāk ieraksti aizgāja uz NVD, kur tiem CISA ADP programma pielika savu papildinājumu ar to pašu kritisko vērtējumu. Red Hat vienam no izdomātajiem caurumiem sākotnēji uzlika maksimālos 10,0 punktus un vēlāk vērtējumu pazemināja. 31. jūlijā oss-security sarakstā parādījās ziņa, ka MITRE visus 54 ierakstus ir atzinis par nederīgiem.

JFrog drošības komanda savu secinājumu formulē īsi:

Neuzticieties tikko publicētiem CVE aizvērtām acīm. Pirms prioritāšu noteikšanas vai ielāpošanas pārbaudiet aprakstu, uzbrukuma paraugu un pirmkodu.

NVD manuālā pārbaude apstājās 2024. gadā

NIST, kas uztur NVD, agrāk katru ierakstu pēc nokļūšanas datubāzē pārlasīja un papildināja ar savu analīzi. 2024. gadā iesniegumu skaits pieauga un šis process praktiski apstājās. Tā gada nogalē neapstrādāto ierakstu rinda pārsniedza 17 000. 2025. gada beigās tā jau bija garāka par 27 000. ASV Tirdzniecības ministrijas ģenerālinspektora 2026. gada maija atskaite secina, ka NIST piešķirto naudu iztērēja bez plānošanas un izlēmīgas rīcības.

Bez šī pārbaudes slāņa datubāzē nonāk tas, ko iesniedzējs uzraksta. Valodas modelis pilnā CVE formātā tekstu uzraksta dažās sekundēs, ar funkciju nosaukumiem, rindu numuriem un uzbrukuma paraugu. Cilvēkam, kas to pēc tam pārbauda pret pirmkodu, vajag stundu vai divas. Šī asimetrija arī ir visa stāsta būtība. Tā nekur nepazudīs.

Automātiskajiem skeneriem atšķirības nav. Ja NVD ierakstā stāv 9,8 punkti un ietekmētā versija sakrīt ar to, kas ir SBOM sarakstā, brīdinājums parādās katrā konveijerā, kur SQLite atrodas kaut kur atkarību kokā. Bet SQLite atkarību kokā mēdz būt gandrīz visur: Android, iOS, Chrome, Firefox, Python standarta bibliotēka un praktiski katrs telefona lietotņu vietējais datu krājums.

ko tas nozīmē ielāpošanas rindā

Daudzās organizācijās iekšējā politika prasa katru kritisko CVE aizvērt noteiktā termiņā. Prasību parasti uzspiež no ārpuses: apdrošinātājs, audita procedūra vai klienta līgums. SQLite ir iebūvēts gandrīz katrā mobilajā lietotnē, pārlūkā un iegultajā ierīcē, tāpēc 9,8 punktu vērts ieraksts par to uzreiz iedarbina inventarizāciju pa visu infrastruktūru.

LWN komentāros šo mehānismu nosauca par neautentificētu pakalpojuma atteices uzbrukumu pret ielāpošanas komandām. Aizsardzība prasa validācijas slāni pirms automātikas. Tieši šo soli lielākā daļa piegādes ķēdes skenēšanas rīku ir izlaidusi, jo bīstamības vērtējumu tie paņem no NVD tieši, bez jautājumiem.

Praktiskais minimums pirms ielāpošanas:

1. vai aprakstā minētā funkcija tajā versijā, kas norādīta, pirmkodā vispār eksistē;
2. vai pievienotais uzbrukuma paraugs uz tavas versijas dod aprakstīto rezultātu;
3. vai ražotājs ievainojamību ir apstiprinājis savā drošības lapā;
4. vai par to ziņo vēl kāds avots ārpus CVE iesniedzēja.

kāpēc šādu ierakstu būs vairāk

SQLite izstrādātāji motivāciju savā lapā skaidro jau gadiem. Pelēkās cepures hakeriem atlīdzību rēķina pēc uzrakstīto CVE skaita un smaguma. Rezultātā rodas ieraksti ar minimālu ietekmi vai bez ietekmes vispār, bet ar pārspīlētiem apgalvojumiem par sekām. Tā pati lapa brīdina, ka CVE par SQLite nav uzskatāms par autoritatīvu informācijas avotu. Valodas modelis šo darbu tagad paātrina simtkārt.

Tā pati tabula rāda, ka problēma nav jauna. CVE-2021-45346 SQLite izstrādātāji atzīmējuši kā dezinformāciju. CVE-2021-42169 pēc viņu vērtējuma ar SQLite nav nekāda sakara. Vēl vairākos gadījumos kļūda mitinājās SQLite JDBC bibliotēkā, Node.js saistījumā vai PHP kalendāra lietotnē LuxCal, ne pašā datubāzes dzinī. Jaunums ir tikai ražība: agrāk šādi ieraksti nāca pa vienam gadā.

SQLite izstrādātāji savā ievainojamību lapā visus sešus ierakstus tagad ir atzīmējuši ar vienu piezīmi: tie nav atkārtojami un izskatās pēc AI halucinācijām. Tajā pašā tabulā ir 52 CVE par visu SQLite vēsturi. Viens GitHub repozitorijs četrās dienās iesniedza 55.

Avoti

• JFrog Security Research: SQLite Critical CVEs or LLM Slop?
• The Register: AI slop pollutes the CVE pipeline with fake vulns
• LWN.net: SQLite Critical CVEs or LLM Slop?
• sqlite.org: Vulnerabilities