Шесть новых уязвимостей SQLite оказались выдуманными. Но до того, как это выяснилось, они успели получить номера CVE, попасть в Национальную базу уязвимостей США и системы автоматического анализа безопасности.
Одной из них даже присвоили оценку 9,8 из 10 по шкале критичности CVSS. Почти максимальная опасность. Это когда возможна утечка данных, отказ в обслуживании и удалённое выполнение кода.
Представьте реакцию команды 😅 Сканер находит критическую уязвимость в зависимости, сборка краснеет, релиз останавливается, разработчики начинают искать способ обновиться или закрыть дыру.
А дыры... Не существует)
История началась с того, что неизвестный автор опубликовал на GitHub более 50 описаний уязвимостей. Вот тот самый репо.
Исследователи JFrog решили проверить шесть CVE, якобы обнаруженных в SQLite. Они собрали заявленные версии базы в изолированных контейнерах, запустили примеры эксплуатации под AddressSanitizer и изучили исходный код.
Результат получился впечатляющим:
– упомянутых функций не существовало в заявленных версиях SQLite;
– номера строк указывали за пределы файлов;
– описанные исправления никогда не вносились;
– часть PoC содержала невалидный SQL;
– ни один из примеров не вызвал обещанную ошибку.
После более широкого аудита выяснилось, что из 55 опубликованных описаний 54 были полностью выдуманы. Ещё одно основывалось на реальном баге, но содержало непроверенные CVE-данные.
JFrog предполагает, что описания были сгенерированы при помощи LLM. С этим уже согласились и разработчики SQLite и на официальной странице проекта шесть CVE помечены как несуществующие баги и вероятные галлюцинации ИИ. Сами записи начали удалять из баз.
И вот здесь начинается самое интересное.
Во многих компаниях новые CVE автоматически попадают в сканеры, CI, отчёты и задачи для разработчиков.
А – автоматизиция. Например, в TELUS Dependabot постоянно проверяются зависимости и при обнаружении уязвимости создаёт предупреждение и рекомендует исправляющий PR. В Synergy проверки Dependabot автоматически запускаются при создании каждого PR. А JFrog Xray можно настроить так, чтобы по данным об уязвимости система создала задачу в Jira, запретила скачивание библиотеки или остановила сборку.
Поэтому ошибочная CVE, прошедшая проверку используемой платформы, способна превратиться не просто в строчку в базе, а в настоящий PR, задачу для разработчика или заблокированный релиз.
Получается почти идеальный цикл:
1. ИИ придумывает уязвимость.
2. Автоматическая система принимает её за настоящую.
3. Другой ИИ-агент пытается найти несуществующую функцию и написать для неё патч.
4. Команда тратит вполне настоящее рабочее время.
Походу, одного номера CVE и высокой оценки теперь недостаточно. Для свежих уязвимостей придётся проверять подтверждение от разработчиков проекта, ссылку на исправляющий коммит, затронутые версии и воспроизводимость PoC.
Добро пожаловать в эпоху, когда security-сканеру тоже нужен фактчекинг 🙂
📎 Расследование JFrog: https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/
📎 Позиция SQLite: https://sqlite.org/cves.html