Исследователи из JFrog забраковали 54 из 55 ИИ‑отчётов об уязвимостях в SQLite

Исследователи из компании JFrog провели анализ 55 сгенерированных ИИ отчётов об уязвимостях в SQLite. Он показал, что 54 из них, в том числе критическую проблему, на самом деле вызваны галлюцинациями ИИ‑модели.

Ранее организация MITRE присвоила всем проблемам CVE‑идентификаторы, и три из них получили статус критических. Самой опасной уязвимости (CVE-2026-51302) компания Red Hat присвоила в своих базах уровень 10 из 10, а SUSE — 9.8 из 10. 

Описание уязвимости включало обращение к памяти после её освобождения в функции exprComputeOperands(), приводящее к возможности выполнения кода при выполнении специально оформленного запроса. Однако данной функции не существует в кодовой базе SQLite 3.41. Источником возникновения уязвимости было заявлено оставление висячего указателя в функции sqlite3ReleaseTempReg(), но её логика работы не подразумевает освобождением памяти и ограничивается пометкой памяти для повторного использования. Это делает невозможным возникновение проблем класса use‑after‑free в силу архитектуры.

В других опасными проблемах тоже упоминались несуществующие файлы и функции, строки кода без ошибок или реальные функции, но с другим числом аргументов. Все прототипы эксплойтов тоже оказались нерабочими и не вызывали даже аварийное завершение, несмотря на заявления о возможности выполнении кода через отправку SQL‑запроса.

При этом MITRE не выполняет реальную проверку, что позволяет любому подать заявку на несуществующую проблему. Фиктивные отчёты о критических проблемах же приводят к замусориванию баз данных с информацией об уязвимостях. Если же использовать ИИ для разработки исправлений, то агент на основе предоставленного описания несуществующей ошибки может подготовить патч, принятие которого приведёт к внесению ненужных изменений.

Ранее Линус Торвальдс в анонсе очередного предварительного выпуска ядра Linux 7.1-rc4 призвал исследователей безопасности, которые используют для генерации отчётов об уязвимостях искусственный интеллект, не отправлять их в приватный список рассылки «security@kernel.org». Также он попросил следовать принятым ранее правилам и модели угроз при отправке такой информации.