CVE-uri false generate de AI în baza NVD — ce s-a întâmplat cu SQLite și de ce ar trebui să te îngrijoreze

Baza de date oficială de vulnerabilități cibernetice a Statelor Unite — NVD (National Vulnerability Database) — a publicat peste 50 de CVE-uri pentru SQLite care s-au dovedit a fi complet false. Nu greșeli minore, nu estimări eronate — fabricații totale, generate cel mai probabil de un model de limbaj AI (LLM). Funcții de cod care nu există, linii citate din fișiere care nu au atâtea rânduri, patch-uri inventate, exploit-uri care nu fac nimic. Iar NVD le-a marcat „critice” fără să verifice. Cercetătorii de la JFrog Security Research au demontat totul în detaliu pe 30 iulie 2026.

Ce vei găsi în acest articol:

Ce s-a întâmplat concret — povestea completă a CVE-urilor false pentru SQLite

Ce este un CVE și de ce contează NVD pentru securitatea ta

Dovezile clare că vulnerabilitățile sunt inventate, cu exemple specifice

De ce e o problemă gravă — alerte false, timp pierdut, încredere erodată

Ce înseamnă pentru tine ca utilizator, developer sau companie din România

Pași concreți prin care verifici dacă o vulnerabilitate e reală

Ce s-a întâmplat: cronologia unui eșec al sistemului

Totul a început cu un repository GitHub nou-nouț: programmervuln/cveadvisory. Contul tocmai fusese creat, fără istoric, fără reputație, fără nicio legătură cu echipa de dezvoltare SQLite. A publicat o serie de „avertismente de securitate” pentru SQLite — baza de date embedded folosită de miliarde de dispozitive: telefoane, browsere, aplicații desktop, sisteme embedded.

Avertismentele arătau profesional. Aveau structura standard a unui CVE — identificator unic (CVE-2026-XXXXX), descriere tehnică, versiuni afectate, scor CVSS, cod de demonstrație (PoC — Proof of Concept), referințe la fișierele sursă SQLite. La prima vedere, nimic suspect.

NVD le-a procesat și le-a publicat. Mai mult, prin programul ADP (Automated Data Pipeline), agenția americană CISA le-a validat și ea. Scoruri de 9.8 critic, 9.1 critic, 8.8 ridicat — genul de scoruri care declanșează automat patch-uri de urgență în companii.

Ce înseamnă un scor CVSS de 9.8? CVSS (Common Vulnerability Scoring System) e un sistem standardizat care evaluează gravitatea unei vulnerabilități pe o scară de 0 la 10. Un scor de 9.8 înseamnă „critic” — vulnerabilitatea poate fi exploatată ușor, de la distanță, fără autentificare, cu impact maxim. E genul de alertă care face echipele de securitate să oprească totul și să aplice patch-uri imediat.

Apoi, cercetătorii JFrog au început să verifice. Și totul s-a prăbușit.

Ce este un CVE și de ce contează NVD

Pentru cine nu lucrează în IT, sistemul CVE (Common Vulnerabilities and Exposures) e practic catalogul global al găurilor de securitate din software. Fiecare vulnerabilitate cunoscută primește un identificator unic — de exemplu CVE-2026-51302 — care e folosit de companii, echipe de securitate, producători de software și autorități pentru a comunica despre aceeași problemă.

NVD (National Vulnerability Database), operat de NIST (Institutul Național de Standarde și Tehnologie din SUA), e baza de date centrală care adună toate CVE-urile, le clasifică, le atribuie scoruri de severitate și furnizează metadate. E sursa la care se uită automatizările, scanerele de vulnerabilități și echipele de securitate din întreaga lume.

De ce contează pentru tine? Pentru că software-ul pe care îl folosești — Windows, Chrome, Android, aplicații de banking, platforme de cumpărături — primește patch-uri în funcție de CVE-urile din NVD. Dacă NVD publică o vulnerabilitate critică, automatizările companiilor generează alerte, echipele opresc sistemele pentru patch-uri, furnizorii de cloud aplică remedieri. Totul e construit pe încrederea că datele din NVD sunt corecte.

Dovezile că CVE-urile sunt false — caz concret cu caz

Cercetătorii JFrog au publicat o analiză detaliată pe 30 iulie 2026 în care au trecut prin fiecare CVE și au demonstrat punct cu punct de ce sunt fabricații. Metodologia lor a fost meticuloasă: au clonat repository-ul oficial SQLite, au construit versiunile menționate în containere Docker izolate, au rulat codul PoC sub AddressSanitizer (un instrument care detectează erori de memorie) și au auditat metadata din NVD și GHSA (GitHub Security Advisory).

Rezultatul? Niciun CVE nu a trecut testul realității.

CVE-2026-51302 — Scor 9.8 „Critical”: o funcție care nu există

Acest CVE raporta un bug de tip Use-After-Free (UAF — eliberare după utilizare) în funcția exprComputeOperands() din SQLite 3.41. Sună concret, sună tehnic, sună plauzibil. Problema? Funcția exprComputeOperands() nu există în SQLite 3.41. A fost adăugată abia la mijlocul lui 2025, într-o versiune mult mai nouă. E ca și cum ai raporta un bug la un model de mașină care încă nu a fost lansat.

Red Hat, unul dintre cei mai mari furnizori de soluții open-source, a luat inițial CVE-ul și i-a dat scorul maxim: 10.0 Critical. Apoi, după verificări, a scăzut la 7.6 High. Unii furnizori au ajustat. Alții, probabil, nu.

CVE-2026-51303 — Scor 9.8: patch-ul era inventat

Acest CVE avea și un „patch” atașat — un diff (diferență de cod) între versiunile 3.51.2 și 3.51.3 din SQLite. Cercetătorii JFrog au comparat cele două versiuni și au constatat că nu există nicio modificare în fișierul src/expr.c. Niciuna. Diff-ul era fabricat.

CVE-2026-51300 — Scor 9.1: linii citate fără legătură

Acest CVE menționa liniile 1012 și 1026 din fișierul expr.c ca locații ale vulnerabilității. Cercetătorii au verificat: linia 1012 era un comentariu în cod, iar linia 1026 era o alocare de memorie banală. Nici urmă de vulnerabilitate.

CVE-2026-51297 — Scor 8.8: o funcție care nu există

CVE-ul raporta un bug în funcția jsonBlobEdit() din SQLite 3.41.0. Funcția pur și simplu nu există în acea versiune. Nici în alte versiuni.

CVE-2026-51296 — Scor 7.5: linii dincolo de fișier

Acesta e poate cel mai ridicol exemplu. CVE-ul raporta un bug la liniile 3555 și 3575 din fișierul json.c. Problema? Fișierul json.c din SQLite 3.41.0 are doar 2.706 linii. Liniile citate pur și simplu nu există — fișierul se termină cu aproape 850 de linii înainte de locația menționată.

CVE-2026-51304 — Scor 7.5: semnătură de funcție inventată

Semnătura funcției raportate în acest CVE pur și simplu nu corespunde cu nicio funcție reală din codul sursă SQLite.

Tabelul complet al problemelor

CVE	Scor NVD	Problema descoperită
CVE-2026-51302	9.8 Critical	`exprComputeOperands()` nu există în SQLite 3.41
CVE-2026-51303	9.8 Critical	Patch-ul (diff 3.51.2 → 3.51.3) e fabricat — nicio modificare în `expr.c`
CVE-2026-51300	9.1 Critical	Liniile 1012 și 1026 din `expr.c` sunt un comentariu și o alocare de memorie
CVE-2026-51297	8.8 High	`jsonBlobEdit()` nu există în SQLite 3.41.0
CVE-2026-51296	7.5 High	Liniile 3555 și 3575 din `json.c` — fișierul are doar 2.706 linii
CVE-2026-51304	7.5 High	Semnătura de funcție raportată nu există în cod

Testarea cu GPTZero: Cercetătorii JFrog au rulat textul avertismentelor prin GPTZero, un detector de text generat de AI. Rezultatul: probabilitate ridicată de generare automată. Stilul era omogen, formulările repetitive, structura artificială — semnele clasice ale „AI slop”.

De ce e o problemă gravă

La prima vedere, ai putea spune: „OK, au fost greșeli, s-au corectat.” Dar impactul real e mult mai mare.

Timp și resurse pierdute

Când NVD publică un CVE cu scor 9.8, companiile nu stau pe gânduri. Echipele de securitate opresc alte activități, echipele de infrastructură aplică patch-uri de urgență, managerii primesc alerte peste noapte. Automatizările programate să reacționeze la CVE-uri critice intră în acțiune. Totul costă timp, bani și energie — pentru o problemă care nu există.

Eroarea de încredere

NVD e considerat sursa de adevăr în securitate. Dacă publică CVE-uri false, întregul sistem de încredere se zguduie. Echipele de securitate încep să se întrebe: „Câte dintre CVE-urile pe care le-am tratat până acum erau false?” Și nu au cum să afle ușor.

Urmări în lanț

Când furnizori mari ca Red Hat preiau un CVE din NVD și îi dau scor maxim, informația se propagă automat la milioane de utilizatori. Scanerele de vulnerabilități generează rapoarte, sistemele de management patching intră în acțiune, echipele raportează către clienți. Retragerea acestor informații e lentă și incompletă — multe sisteme nu primesc actualizările de retragere.

Deschidere către atacuri

Da, ai citit bine. CVE-urile false pot fi folosite ca armă. Un atacator poate crea un CVE fals pentru un software al unui concurent, să-i forțeze să piardă timp cu investigații și patch-uri inutile, sau să creeze confuzie care să mascheze un atac real care se desfășoară în paralel. În securitatea cibernetică, confuzia e un vector de atac.

Dacă te interesează cum funcționează atacurile reale din spațiul open-source, vezi și articolul despre exploatarea zero-day pe GitHub și cum te protejezi.

Ce înseamnă pentru tine ca utilizator, developer sau companie din România

S-ar putea să crezi că asta e o problemă „de americani” sau „de companii mari”. Nu e. Iată de ce.

Dacă ești utilizator obișnuit

Telefonul tău, browserul tău, aplicațiile tale — toate folosesc SQLite. Când producătorii primesc alerte de CVE-uri critice, uneori aplică patch-uri grabite care pot introduce noi probleme. Alteori, echipele de dezvoltare își mută atenția de la vulnerabilități reale la false. Impactul indirect ajunge la tine prin calitatea software-ului pe care îl folosești.

Dacă ești developer

Dacă folosești scanere de dependențe (Dependabot, Snyk, Trivy) — ceea ce ar trebui — CVE-urile false apar automat în rapoartele tale. Pierzi timp investigând, confirmând că nu e o problemă reală, dezactivând alerte false. Într-un proiect cu zeci de dependențe, asta se adună.

Dacă ai o companie sau lucrezi în IT în România

Companiile care respectă standarde precum ISO 27001 sau SOC 2 sunt obligate să trateze CVE-urile critice într-un interval dat. Un CVE fals cu scor 9.8 declanșează proceduri de urgență — uneori în weekend, uneori cu costuri de consultant extern. Când se dovedește că era fals, nu poți recupera acele ore.

Vrei să înțelegi mai bine cum funcționează „AI slop” în general? Vezi ghidul despre cum să recunoști conținutul generat de AI și articolul despre etichetarea conținutului generat de AI pe internet.

Cum verifici dacă o vulnerabilitate e reală — pași concreți

Nu trebuie să fii expert în securitate ca să te protejezi. Iată un proces practic pe care îl poți urma.

Verifică sursa CVE-ului. Cine l-a raportat? Un cercetător de securitate cu reputație, un furnizor cunoscut, sau un cont GitHub nou fără istoric? CVE-urile din acest scandal veneau de la un cont anonim.
Caută pe pagina oficială a producătorului. SQLite are o pagină oficială de securitate. Dacă CVE-ul nu apare acolo, e un semn de alarmă major. Niciunul dintre CVE-urile false nu apărea pe pagina SQLite.
Verifică codul sursă citat. Dacă CVE-ul menționează o funcție sau linii de cod, caută în repository-ul oficial. Funcția există? Liniile corespund cu ce se descrie? În scandalul NVD, funcțiile și liniile erau inventate.
Citește PoC-ul (demonstrația). Un PoC real arată concret cum se exploatează vulnerabilitatea. Dacă PoC-ul nu face nimic când îl rulezi (sau dacă nu ai cum să-l rulezi), e suspect.
Caută confirmare independentă. Dacă un singur anunț menționează CVE-ul și nimeni altcineva nu-l confirmă — alte companii de securitate, alte rapoarte — fii sceptic.
Verifică scorul CVSS cu cap. Un scor de 9.8+ pentru un bug minor sau neconfirmat e un semn de alarmă. Scorurile mari sunt pentru vulnerabilități cu impact maxim, exploatabile ușor.
Folosește surse multiple. Nu te baza doar pe NVD. Verifică și GHSA (GitHub Security Advisory), advisoriile furnizorilor, bazele de date precum VulDB sau Rapid7.

Regula de aur: Dacă un CVE sună prea rău ca să fie verificat de alții, verifică-l tu. Nu aplica patch-uri de urgență doar pentru că un scor CVSS e mare — confirmă mai întâi că vulnerabilitatea există.

Cum a fost posibil: sistemul NVD are hibe

E ușor să dai vina pe „AI”, dar problema reală e în sistem. NVD a procesat CVE-urile automat, prin programul ADP, fără verificare manuală aprofundată. Procesul de raportare CVE are câteva slăbiciuni structurale care permit astfel de abuzuri.

Raportarea e deschisă. Orice persoană poate raporta un CVE prin programul CNA (CVE Numbering Authority). Sunt mii de entități autorizate să aloce CVE-uri, iar verificarea calității variază enorm.

Viteza bate acuratețea. Presiunea de a publica rapid CVE-uri noi — pentru că întârzierile pot pune utilizatorii în pericol — înseamnă că verificarea detaliată adesea nu se întâmplă.

Automatizarea nu înlocuiește expertiza. ADP-ul NVD e proiectat să proceseze volume mari de date, nu să valideze tehnic fiecare raport. Când datele de intrant sunt fabricate, automatizarea le procesează la fel de repede.

Aceasta nu e prima dată când bazele de date de securitate sunt manipulate. Am mai văzut tactici similare cu malware ascuns în repository-uri GitHub — vezi articolul despre cele 10.000 de repo-uri GitHub infectate cu troieni.

Ce se întâmplă mai departe: viitorul bazelor de date de vulnerabilități

Scandalul CVE-urilor false pentru SQLite nu e un incident izolat — e un simptom al unei probleme mai mari. Pe măsură ce AI-ul devine mai capabil să genereze text tehnic plauzibil, astfel de atacuri vor deveni mai frecvente și mai greu de detectat.

Ce ar trebui să se schimbe

Verificare tehnică obligatorie. NVD și CISA trebuie să includă pași de validare tehnică în procesul de publicare — nu doar formatul, ci conținutul: funcțiile citate există? Liniile corespund? PoC-ul produce rezultatul descris?

Reputația raportorului. Sistemul trebuie să țină cont de istoricul celui care raportează. Un cont nou, fără activitate, fără legături cu comunitatea de securitate, nu ar trebui să aibă același nivel de încredere ca un cercetător cunoscut.

Retragere rapidă și transparentă. Când un CVE se dovedește fals, retragerea trebuie să fie la fel de rapidă ca publicarea — cu notificări automate către toți consumatorii de date NVD.

Verificare independentă înainte de publicare. Un model în care CVE-urile trec printr-un proces de peer review înainte de a fi marcate „critice” ar reduce drastic incidentele.

Ce poți face tu

Nu aștepta să se schimbe sistemul. Construiește-ți obiceiul de a verifica CVE-urile înainte de a acționa. E mai bine să întârzii un patch cu o zi și să confirmi că vulnerabilitatea e reală, decât să pierzi o zi întreagă tratând o fantomă.

Disclaimer: Acest articol are scop informativ și se bazează pe cercetarea publicată de JFrog Security Research pe 30 iulie 2026. Detaliile tehnice au fost verificate din surse publice. Articolul nu constituie consultanță de securitate pentru cazul tău specific — pentru situații critice, consultă un specialist.

Întrebări frecvente

Ce e un CVE și cine îl creează?

CVE (Common Vulnerabilities and Exposures) e un identificator standardizat pentru vulnerabilități de securitate cibernetică. Fiecare vulnerabilitate cunoscută primește un cod unic — de exemplu CVE-2024-12345 — care e folosit global pentru a comunica despre aceeași problemă. CVE-urile sunt alocate de CNA (CVE Numbering Authority) — entități autorizate de organizația MITRE, care include producători de software, companii de securitate și agenții guvernamentale. NVD (National Vulnerability Database) din SUA preia CVE-urile, le clasifică și le atribuie scoruri de severitate.

SQLite-ul meu e în pericol din cauza acestor CVE-uri?

Nu. CVE-urile erau false — funcțiile, liniile de cod și patch-urile menționate nu corespund realității. SQLite nu are vulnerabilitățile respective. Dacă ai primit alerte de la scanerele tale de securitate, verifică dacă alerta se referă la aceste CVE-uri specifice (CVE-2026-51296 până la CVE-2026-51304). Dacă da, poți să le marchezi ca false. Nu ignora însă alte CVE-uri pentru SQLite — verifică întotdeauna pe pagina oficială de securitate SQLite.

De ce Red Hat a dat scor 10.0 la un CVE fals?

Red Hat folosește datele din NVD ca punct de plecare pentru evaluarea CVE-urilor. Când NVD publică un CVE cu informații care par tehnice și plauzibile — funcții, linii de cod, versiuni afectate — furnizorii preiau și evaluează. Red Hat a ajustat scorul de la 10.0 la 7.6 după verificări proprii, dar viteza de reacție inițială arată cât de multă încredere se pune automat în datele NVD. E un semn că sistemul are nevoie de verificări suplimentare.

Pot folosi AI-ul ca să detectez CVE-uri false?

Parțial, da. Instrumente precum GPTZero pot detecta probabilitatea ca un text să fi fost generat de AI — și în acest caz au confirmat suspiciunile. Dar nu te baza doar pe detectoare AI. Verificarea cea mai sigură rămâne cea tehnică: funcția citată există în codul sursă? Liniile corespund? PoC-ul produce rezultatul descris? Combinația dintre detectarea AI și verificarea tehnică manuală e cea mai bună abordare.

Cum pot fi sigur că CVE-urile pe care le tratez sunt reale?

Nicio sursă nu e 100% sigură, dar poți reduce riscul considerabil: verifică CVE-ul pe pagina oficială a producătorului, caută confirmare din surse independente (două sau mai multe companii de securitate), verifică codul sursă menționat dacă e open-source, și fii sceptic la CVE-uri raportate de conturi fără istoric. Pentru companii, stabilește un proces intern de validare înainte de a activa patch-uri de urgență — chiar și pentru CVE-uri cu scor mare.