Исследователи JFrog проверили 55 сообщений об уязвимостях в SQLite, сгенерированных с помощью ИИ, и забраковали 54 из них. Для разработчиков, DevSecOps-команд и тех, кто живёт по CVE-фиду, это неприятный, но полезный сигнал: ИИ-отчёты об уязвимостях уже умеют засорять базы инцидентов почти так же уверенно, как и создавать шум в баг-трекерах.
По данным Habr / Новости, часть этих находок успела пройти формальную бюрократию и получить CVE-идентификаторы через MITRE, а три записи даже добрались до критического статуса. Самый показательный кейс — CVE-2026-51302. В базах Red Hat этой проблеме поставили максимальные 10 из 10, SUSE оценила её в 9,8. На бумаге всё выглядело как кошмар сопровождения: use-after-free в функции exprComputeOperands(), возможность выполнить код через специально подготовленный SQL-запрос, высокий приоритет для реагирования. На практике JFrog не нашла в кодовой базе SQLite 3.41 даже самой функции, вокруг которой была построена история.
Разбор получился почти учебным. В описании CVE утверждалось, что корень ошибки находится в функции sqlite3ReleaseTempReg(), где якобы оставался висячий указатель после освобождения памяти. Но, как указывают исследователи, логика этой функции не связана с освобождением памяти: она лишь помечает ресурс для повторного использования. Иначе говоря, сам класс проблемы не бьётся с архитектурой механизма. Если упростить до бытового языка разработчика: отчёт уверенно объяснял аварию в узле, который вообще не выполняет описанную опасную операцию.
На этом странности не закончились. В других отчётах JFrog нашла стандартный набор симптомов машинной галлюцинации, знакомый уже не только редакторам, но и инженерам безопасности: несуществующие файлы, вымышленные функции, ссылки на строки кода, где нет описанной ошибки, и реальные функции с неверным количеством аргументов. Отдельно проверили прототипы эксплойтов. Результат тоже вышел прозаичным: они не сработали и не вызвали даже аварийного завершения процесса, хотя в описаниях фигурировала перспектива удалённого выполнения кода через SQL-запрос. Для тех, кто строит процессы вокруг автоматического приоритезационного пайплайна, это особенно болезненно: шум выглядит как критическая угроза, но при вскрытии оказывается фанфиком по мотивам исходников.
Проблема здесь не только в одной неудачной серии заявок. Куда неприятнее устройство самой цепочки. MITRE, как следует из публикации, не выполняет полноценную техническую верификацию каждой присланной проблемы. Это означает, что CVE-номер сам по себе не гарантирует, что перед вами воспроизводимая уязвимость, а не убедительно оформленная фантазия модели. Для рынка, привыкшего воспринимать идентификатор как минимум подтверждения существования проблемы, это очень плохая новость. Дальше включается эффект домино: запись попадает в базы поставщиков, получает severity, разлетается по сканерам, SIEM, дашбордам риска и внутренним отчётам для менеджмента. Команда тратит часы не на защиту, а на санитарную обработку входящего потока.
Для экосистемы open source у этой истории есть ещё один неприятный слой. Если ИИ-отчёты об уязвимостях начинают массово попадать в публичные базы, ломается доверие к самому процессу ответственного раскрытия. Разработчики сопровождаемых проектов вынуждены разбирать не только реальные баги, но и синтетические страшилки с «критическим» рейтингом. А если кто-то поверх такого описания запускает ИИ-агента для генерации исправления, то возникает уже следующий риск: патч к несуществующей ошибке. Формально он может выглядеть осмысленно, пройти часть автоматических проверок и даже попасть на ревью. По сути это будет мусорный коммит, который усложняет код, увеличивает поверхность для регрессий и отъедает время у людей, которые вообще-то должны были чинить настоящее.
Сигнал тревоги по поводу таких практик звучит не впервые. В источнике напоминают, что ранее Линус Торвальдс, представляя очередной предварительный выпуск Linux 7.1-rc4, прямо попросил исследователей безопасности не слать в приватный список security@kernel.org отчёты, сгенерированные ИИ. Сам по себе тон этой просьбы показателен: проблема уже вышла из категории теоретической. Когда мейнтейнеры крупнейших проектов начинают отдельно оговаривать, что машинные фантазии не надо маскировать под security research, значит индустрия прошла этап восторга и перешла к этапу фильтрации последствий.
Для русскоязычной IT-аудитории вывод предельно прикладной. Если у вас в процессе есть зависимость от внешних CVE-лент, автоматического сканирования, тикетов от вендоров или полуавтоматической оценки риска, одного факта наличия идентификатора уже недостаточно. Нужны хотя бы базовые проверки: существует ли упомянутая функция, совпадает ли файл, воспроизводится ли сценарий, вообще соответствует ли описание архитектуре компонента. Особенно если речь идёт о популярных библиотеках и встраиваемых БД вроде SQLite, которые легко становятся частью supply chain у сотен внутренних сервисов. ИИ сильно удешевил производство текста, а вместе с ним и производство правдоподобной чепухи. В безопасности это означает простую вещь: дефицит теперь не в алертах, а в верификации.
История с SQLite вряд ли останется единичной. Пока процедуры присвоения идентификаторов и внутренние процессы компаний ориентированы на объём сигналов, а не на глубину проверки, ИИ будет масштабировать не только поиск дефектов, но и выпуск убедительно оформленных несуществующих уязвимостей. Для отрасли главный вопрос уже не в том, можно ли применять модели в security-практике, а в том, где именно должен стоять человек с исходниками, тестом и правом сказать: нет, этой дыры не существует.