# 54 из 55: как нейросеть придумала критическую уязвимость в SQLite, а мир поверил

Уязвимость с оценкой 10 из 10 — это функция, которой в этой версии SQLite попросту не существовало. Именно так выглядела самая опасная из 55 «уязвимостей», которые компания JFrog взялась проверить в конце июля. И, да, это пост для бизнесменов.

## Что произошло

Новый аккаунт на GitHub за несколько дней опубликовал 55 отчётов об уязвимостях в SQLite, библиотеке libraw и звуковом декодере для Arduino. Автоматика национальной базы уязвимостей NVD и агентство CISA присвоили части отчётов официальные номера CVE, а три проблемы получили статус критических. Самой опасной, CVE-2026-51302, компания Red Hat сначала выставила максимум по шкале CVSS, 10 из 10, а через пару дней снизила оценку до 7,6. По остальной пачке фейковых отчётов оценки от разных площадок доходили до 9,8.

## Как это раскрыли

Специалисты JFrog взяли официальный код SQLite нужных версий, собрали его в чистом окружении и прогнали через эксплойты, приложенные к отчётам. Ни один не сработал. Причина простая. Функция, которую якобы ломает CVE-2026-51302, появилась в SQLite только в середине 2025 года, а отчёт описывает версию 3.41.0, где её физически ещё не было. В другом отчёте цитировались номера строк кода, которых нет и не может быть, потому что файл короче. В третьем «патч» между версиями, на который ссылался отчёт, вообще не менял затронутый файл. Когда исследователи склеили все 55 отчётов в один текст и прогнали через детектор ИИ-контента, тот выдал предупреждение, что текст похож на написанный языковой моделью.

## Почему это вообще прошло

Заявку на CVE можно подать через публичную форму MITRE без проверки личности и без обязательного доказательства. До 2024 года эксперты национальной базы уязвимостей вручную разбирали каждую заявку, но после того как поток отчётов резко вырос, ручную проверку фактически свернули. CISA и другие организации пытаются закрывать эту дыру своими силами, но объём их пока не пускает. В итоге правдоподобно звучащий текст от нейросети проходит весь путь: номер CVE, оценка критичности, попадание в базы, на которые ссылаются сканеры безопасности по всему миру.

## При чём тут бизнес

Если в компании есть система, которая автоматически заводит тикет на «критическую уязвимость» и требует немедленного патча, вы только что увидели сценарий, в котором она среагирует на пустоту. Хуже, если патчить будет не разработчик, а ИИ-агент. Он не найдёт функцию из отчёта, но по инструкции всё равно начнёт что-то менять в рабочем коде, чтобы закрыть тикет. Правки ради бага, которого никогда не было, стоят вполне реальных денег и реального времени команды.

Это и есть та самая новая абстракция, которую вам сейчас продают. Раньше подрядчик обещал написать код. Сегодня код умеет писать нейросеть, поэтому вам предлагают следующий слой: просканировать систему на «дырочки», найти точки неэффективности, поставить ещё один контур защиты. Часть этой работы настоящая и нужная. Но эта же ниша отлично годится для продажи воздуха, потому что цифра «10 из 10» пугает человека без технического образования сильнее любого аргумента.

## Три вопроса перед оплатой

Прежде чем платить за срочное устранение «критической» уязвимости, стоит спросить подрядчика или свою ИТ-команду:

1. Есть ли эта проблема на официальной странице безопасности вендора, а не только в сторонней базе?
2. Приложен ли рабочий пример эксплойта или ссылка на реальный коммит с исправлением?
3. Совпадают ли данные в разных базах, или там пустые поля и противоречия?

Три вопроса и есть весь чек-лист, который отделяет реальную защиту от красиво оформленного счёта.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Наши площадки:
Telegram | ВКонтакте | Дзен | RuTube | YouTube | Max | Закрытый чат