В свежем GitHub-репозитории programmervuln/cveadvisory появилась пачка advisory по уязвимостям SQLite — вместе с ещё 50 с лишним CVE. В JFrog считают, что почти всё это LLM-slop. NVD быстро пометила эти CVE как critical, CISA через ADP согласилась. Но когда исследователи JFrog начали проверять, всё развалилось: упомянутый код в указанных версиях не существует или не относится к делу, PoC не вызывают падений, на официальной странице SQLite этих CVE нет, а проверка через Gptzero показывает признаки AI-генерации.
Показателен случай CVE-2026-51302: Red Hat сначала присвоил ему 10.0 Critical, а потом понизил до 7.6 High. По этому CVE заявлен use-after-free через exprComputeOperands(), но этой функции вообще не было в SQLite 3.41 — она появилась только в середине 2025 года. А sqlite3ReleaseTempReg() не освобождает память из кучи, а просто переиспользует номера регистров, так что UAF там невозможен по построению.
CVE-2026-51303 утверждает, что ExprListDelete() не чистит back-reference, и что это пофиксили в 3.51.3. Но diff между 3.51.2 и 3.51.3 вообще не трогает src/expr.c — патча не существует. В CVE-2026-51300 цитируются строки 1012 и 1026, но это комментарий и вызов выделения памяти, ни к какому pLeft они не относятся. CVE-2026-51297 ссылается на jsonBlobEdit(), которой в 3.41.0 тоже не было. CVE-2026-51296 указывает строки 3555 и 3575 в json.c, но в версии 3.41.0 этот файл всего 2706 строк. CVE-2026-51304 использует несуществующую сигнатуру sqlite3ExprListDelete() с одним аргументом, хотя реальная требует sqlite3 *db; в коде указатель сразу зануляется после удаления.
Исследователи проверили всё в изолированных Docker-контейнерах, с чистой сборкой официальных релизов и AddressSanitizer. Ни один PoC не сработал. Проблема системная: форма MITRE не проверяет личность, NIST фактически остановил глубокий анализ ещё в феврале 2024 года, а в пайплайне нигде не требуется ни PoC, ни воспроизведение бага. Аудит 55 advisory из этого репозитория показал: 54 полностью выдуманы, одна содержит реальный баг, но с неподтверждёнными CVE-метаданными.
Такие фейковые CVE заставляют команды тратить время на несуществующие уязвимости и засоряют базы данных. Особенно опасно, когда триаж автоматизирован через AI: агент может искать несуществующую функцию, генерировать патч и уводить команду в сторону. JFrog советует не доверять новым CVE от неизвестных источников, проверять, относится ли уязвимость к вашему окружению, и воспроизводить проблему с PoC в безопасной среде. Findings уже передали в GHSA, Red Hat и NVD.