SQLite и критичните CVE уязвимости: Реални заплахи или генериран от ИИ шум?

Публикувано от Svetni.me Editorial на 3 август 2026 г.

През последните години изкуственият интелект улесни автоматизацията на множество процеси, но същевременно създаде и нови предизвикателства за сигурността. Наскоро в публичното пространство се появи нова вълна от фалшиви сигнали за пропуски в сигурността, описвани като ИИ спам (AI slop) — автоматично генерирано съдържание с ниско качество, което имитира реални технически анализи. Киберсигурността се оказа пряка жертва на този феномен, след като в края на юли 2026 г. потребителски профил в GitHub публикува десетки несъществуващи уязвимости в популярни софтуерни продукти с отворен код [1, 4].

Един от основните обекти на тази кампания беше SQLite — най-широко използваната библиотека за управление на релационни бази данни в света. Профил с име programmervuln/cveadvisory- качи база данни с доклади, които бързо бяха класифицирани от Националната база данни за уязвимости на САЩ (CVE / NVD) като критични [1, 4]. Първоначално някои от тези доклади дори получиха максимален рейтинг на опасност 10.0 (Critical) от големи дистрибутори на софтуер като Red Hat. Детайлно разследване на изследователския екип на JFrog Security Research обаче показа, че тези твърдения са изцяло измислени [1].

SQLite CVE LLM Slop Hero
Изображение: Svetni.me / ИИ генерирано изображение

Как бяха открити фалшификатите?

За да проверят достоверността на публикуваните доклади, изследователите от JFrog създадоха строго изолирана работна среда за тестване [1]. Първо, те анализираха официалния софтуерен код на SQLite, като изтеглиха конкретните версии, посочени в докладите (3.41.0, 3.51.2 и 3.51.3). Този сравнителен анализ веднага разкри технически несъответствия между твърденията на откривателя и реалния код.

След това официалните издания на SQLite бяха компилирани в чисти Docker контейнери, за да се избегне влиянието на външни фактори. В тези среди изследователите пуснаха SQL заявките от предоставените Proof-of-Concept (PoC) сценарии. За откриване на евентуални проблеми с паметта беше използван инструментът AddressSanitizer (ASan). Резултатите бяха категорични — нито един от тестваните сценарии не предизвика срив на програмата или изтичане на памет.

Накрая екипът анализира текстовете на докладите с инструмента GPTZero за засичане на генерирано от ИИ съдържание [5]. Обединяването на текстовете от десетките публикации веднага задейства алармите за автоматично генериран текст. Всички индикации сочеха, че някой е използвал голям езиков модел (LLM), за да изфабрикува технически звучащи доклади за уязвимости.

Анатомия на шестте фалшиви уязвимости в SQLite

Разследването на JFrog се фокусира върху шест конкретни CVE записа, които илюстрират типичните грешки на генеративния изкуствен интелект при симулация на софтуерен анализ [1].

CVE-2026-51302: Несъществуваща логика (9.8 Critical)

Този доклад твърди, че в SQLite възниква грешка от тип Heap Use-After-Free (UAF). Проблемът уж се появява, когато функцията sqlite3ReleaseTempReg() оставя висящ указател в regFree1, който по-късно се достъпва от exprComputeOperands().

Основният проблем с това твърдение е, че функцията exprComputeOperands() изобщо не съществува в SQLite версия 3.41.0. Тя е добавена в много по-късен етап от разработката през 2025 г. [6, 7]. Освен това вътрешната логика на sqlite3ReleaseTempReg() изобщо не разпределя или освобождава динамична памет от хийпа. Тя просто рециклира индексни регистри в масив за повторна употреба:

/* expr.c:6562, SQLite 3.41.0 */
void sqlite3ReleaseTempReg(Parse *pParse, int iReg){
  if( iReg ){
    sqlite3VdbeReleaseRegisters(pParse, iReg, 1, 0, 0);
    if( pParse->nTempReg < ArraySize(pParse->aTempReg) ){
      pParse->aTempReg[pParse->nTempReg++] = iReg;
    }
  }
}

Тестовете на PoC заявката потвърдиха, че кодът работи коректно без никакви сривове.

CVE-2026-51303: Призрачни корекции (9.8 Critical)

Докладът описва уязвимост, при която функцията ExprListDelete() освобождава дъщерни възли, без да изчиства обратните връзки в родителските структури. Твърди се, че проблемът е коригиран в пач за версия 3.51.3.

Техническият анализ показва, че в структурите Expr, Select или Window няма указатели за обратни връзки, които да доведат до такова състояние. Най-неоспоримото доказателство за лъжата е сравнението на промените (diff) между версии 3.51.2 и 3.51.3. Във файл src/expr.c няма нито един променен ред код, което означава, че рекламираната корекция е изцяло измислена. Самият тестов сценарий е невалиден SQL код, който се отхвърля още на ниво синтактичен анализатор.

CVE-2026-51300: Грешни адресни редове (9.1 Critical)

Докладът твърди, че се получава UAF уязвимост във функцията sqlite3ExprDelete(), тъй като левият указател (pLeft) не се изчиства. Посочват се конкретни редове 1012 и 1026 в софтуерния файл expr.c.

При проверка на кода се вижда, че посочените редове съдържат съответно коментар и извикване на функция за заделяне на памет, които нямат нищо общо с pLeft или логиката по изтриване. Макар че функцията sqlite3ExprDelete() се извиква при грешки за недостиг на памет (OOM), тя се намира в края на своя жизнен цикъл и указателят никога не се използва повторно:

/* expr.c:1330, SQLite 3.41.0 */
void sqlite3ExprDelete(sqlite3 *db, Expr *p){
  if( p ) sqlite3ExprDeleteNN(db, p);
}

Тестовете с реален SQL код се изпълниха успешно без изтичане на памет или необичайно поведение.

CVE-2026-51297: Несъответствие на версиите (8.8 High)

Според описанието, функцията jsonParseFree() оставя висящи указатели, които по-късно се достъпват неправилно от функцията jsonBlobEdit().

И тук ИИ моделът е допуснал логическа грешка, смесвайки версии. Функция с име jsonBlobEdit() не съществува в посочената версия 3.41.0, тъй като е част от по-новата JSONB функционалност. В изследваната версия функцията jsonParseFree() се извиква единствено в деструктори, където обвиващата структура се унищожава веднага. Всякакви опити за стартиране на предоставения тестов код водят до моментална грешка за невалиден JSON формат.

CVE-2026-51296: Невъзможни номера на редове (7.5 High)

Докладът твърди, че има UAF проблем във функцията jsonRemoveFunc на редове 3555 и 3575 във файла json.c.

Това е една от най-очевидните индикации за халюцинация на изкуствен интелект. В SQLite версия 3.41.0 целият файл src/json.c съдържа само 2706 реда код. Редове с номера 3555 и 3575 изобщо не съществуват физически. Самата функция се намира около ред 1500, а проверката на кода показа, че управлението на паметта там е напълно безопасно.

CVE-2026-51304: Липсващи аргументи и зануляване на указатели (7.5 High)

Твърди се, че извикването на sqlite3ExprListDelete(pOrderBy) освобождава сортиращия списък, но следващият код продължава да чете полето pOrderBy->nExpr.

На първо място, посочената функция няма сигнатура с един аргумент — тя задължително изисква и указател към базата данни (sqlite3 *db). На второ място, разработчиците на SQLite използват добри практики за програмияне и незабавно зануляват указателите след освобождаване:

/* select.c:3761, SQLite 3.41.0 */
sqlite3ExprListDelete(db, pPrior->pOrderBy);
pPrior->pOrderBy = 0;   /* Указателят е изчистен незабавно; използването му е невъзможно */

Системният срив в обработката на CVE

Този инцидент разкрива сериозен системен проблем в начина, по който се регистрират и проверяват софтуерните уязвимости. Процесът по подаване на CVE през публичните форми на MITRE на практика не изисква верификация на самоличността [1]. Всеки потребител може да попълни описание и да предложи собствена CVSS оценка на риска, без да предоставя работещ код за демонстрация.

В миналото Националната база данни за уязвимости (NVD) на NIST служеше като надежден филтър [1]. Експертите там извършваха ръчен анализ на постъпващите сигнали и ги обогатяваха с данни, преди да ги одобрят. Този модел обаче се срина през февруари 2024 г., когато поради огромен наплив от доклади NIST преустанови задълбочената проверка [2]. Агенции като CISA се опитват да компенсират изоставането чрез свои инициативи, но веригата за сигурност остава фрагментирана и задръстена от хиляди необработени записи.

Опасностите от автоматизираното коригиране с ИИ

Навлизането на неверни данни в публичните бази данни за сигурност създава сериозен риск за бизнеса. Много организации използват автоматизирани скенери, които блокират компилации или отварят задачи за поддръжка веднага щом се появи нов CVE с висок рейтинг. Разследването на JFrog установи, че от 55 доклада, качени от въпросния профил, 54 са напълно измислени [1].

Още по-опасно става, когато се използват ИИ агенти за автоматично отстраняване на уязвимости (auto-remediation). Един ИИ агент, сблъсквайки се с фалшив CVE, може да се опита да намери несъществуваща функция и да генерира пач за код, който не съществува. Вместо да помага на екипите по сигурност, това може да вкара нежелани промени и реални уязвимости в софтуера.

Как да разпознаем генерирания от ИИ спам (AI slop) в CVE базите данни

За да предпазят софтуерните си проекти от фалшиви аларми, екипите за сигурност трябва да следят за няколко основни предупредителни знака [1]:

  • Липса на потвърждение от разработчика: Липса на информация за проблема в официарните страници за сигурност на продукта (например sqlite.org/cves.html за SQLite) [3].

  • Липсваща история на промените: Няма линкове към конкретни commit хешове или Pull Requests в референтните полета на доклада.

  • Противоречия в метаданните: Празни CPE дефиниции за засегнати продукти или версии, които си противоречат с описанието.

  • Несъществуващ код: Препратки към функции, които не съществуват в посочената версия, или към редове код отвъд края на файла.

Заключение и препоръки за сигурност

Случаят с фалшите в SQLite показва, че киберсигурността вече не се бори само с реални заплахи, но и с шума, създаван от изкуствения интелект. Скенерите за уязвимости и публичните бази данни вече не могат да бъдат приемани като абсолютна истина без допълнителна проверка.

Специалистите по сигурност трябва да избягват сляпото доверие на нови CVE доклади от неизвестни източници:

  • Не се доверявайте сляпо: Избягвайте автоматичното пачване или спиране на системи само въз основа на нови CVE доклади от неизвестни източници.

  • Изследвайте контекста: Проверете дали вашата работна среда действително използва засегнатата библиотека по начин, който излага кода на описания риск.

  • Тествайте и възпроизвеждайте: Винаги се опитвайте да възпроизведете проблема с предоставения PoC код в безопасна, изолирана среда.

Изследователите от JFrog вече са докладвали своите разкрития на NVD, Red Hat и GitHub Security Advisories (GHSA) за изчистване на регистрите [1].

Източници:

[1]: JFrog Security Research Blog: SQLite Critical CVEs or LLM Slop?
[2]: NVD Program Transition Announcement - NIST NVD
[3]: SQLite Official CVEs Page
[4]: GitHub Repository: programmervuln/cveadvisory-
[5]: GPTZero AI Detector
[6]: SQLite Commit e24f20a - GitHub
[7]: SQLite Commit 280559b - GitHub