Шесть критических и высоких записей о якобы найденных дырах в SQLite оказались технически несостоятельными, но успели пройти заметную часть отраслевого конвейера. Для тех, кто опирается на базы уязвимостей, это плохая новость: фейковые CVE теперь могут выглядеть достаточно правдоподобно, чтобы тратить время разработчиков, AppSec-команд и ИБ-служб на разбор несуществующих проблем.
О проблеме как пишет The Register, рассказали исследователи JFrog. Они разобрали пакет из 54 CVE, опубликованных через малозаметный GitHub-репозиторий. Шесть записей касались SQLite и получили оценки CVSS от 9,8 до 7,5. На бумаге это выглядело как набор неприятных багов уровня “надо срочно чинить”. На практике, по данным JFrog, воспроизвести уязвимости не удалось. В одном случае описание use-after-free ссылалось на функцию, которой в указанной версии SQLite вообще не было. В другом источники указывали на строки кода, не связанные с заявленной проблемой. Proof-of-concept, приложенный к одной из записей, просто выполнял корректный SQL-запрос без утечек памяти и без ошибок.
Остальные четыре SQLite-CVE из того же набора, по результатам проверки JFrog, были устроены примерно так же: убедительный текст, громкая оценка риска и нулевая техническая опора. Еще 49 записей из того же репозитория касались библиотеки libraw и Arduino-проекта ESP32-audioI2S. Их исследователи не прогоняли с той же глубиной, но заявили, что и там картина похожая: почти все сообщения выглядят столь же поддельными, за исключением одного случая, где в основе, по их словам, был реальный баг, но обвязанный непроверенными CVE-метаданными. Иными словами, проблема уже не сводится к чьей-то небрежности в оформлении. Похоже, что генеративные модели сильно удешевили выпуск правдоподобного мусора, а вот цена проверки осталась прежней: читать код, собирать нужную версию, гонять PoC, смотреть логи, пытаться воспроизвести поведение.
Здесь самое неприятное даже не в самих фальшивках, а в том, как далеко они сумели пройти. По словам JFrog, часть этих записей появилась в NVD с дополнительным обогащением от CISA. Red Hat изначально даже присвоила одной из записей максимальные 10,0 балла CVSS, а затем снизила оценку. На рассылке Openwall инженер Oracle Solaris Алан Куперсмит напомнил неприятную, но важную деталь: MITRE и многие другие CNA во многом работают на доверии к заявителю, особенно если речь идет о стороннем коде. Проверить каждое сообщение самостоятельно они часто не могут. Раньше роль страховочной сетки в этой схеме играл NIST, который вручную просматривал и дополнял записи в National Vulnerability Database. Но именно эта страховка уже давно работает с перегрузкой.
Перегрузка там не символическая, а вполне измеримая. К концу 2024 года в очереди NIST скопилось более 17 тысяч необработанных CVE, хотя агентство собиралось расчистить завал до конца 2024 финансового года с помощью подрядчиков. К концу 2025-го хвост вырос уже более чем до 27 тысяч записей, следует из отчета инспектора Министерства торговли США, опубликованного в мае 2026 года. Тот же отчет прямо говорил о слабом стратегическом управлении и не слишком решительных действиях, из-за которых деньги на расчистку бэклога тратились без ожидаемого эффекта. На языке практики это означает простую вещь: в нынешнем конвейере нет обязательной точки, где каждая заявленная уязвимость должна быть независимо подтверждена до попадания в широкий оборот.
Для русскоязычной IT-аудитории вывод довольно приземленный. Если у вас сборка рисков, приоритизация патчей или контроль поставки завязаны на автоматическое поглощение CVE из внешних баз, фейковые CVE становятся операционной проблемой, а не курьезом из англоязычной повестки. Команда начинает тратить часы на тикеты, которых не должно было быть. Разработчики дергаются из-за “критических” SQLite-дыр, которых не существует. Продуктовые и инфраструктурные команды получают ложный шум в сканерах, а менеджеры видят всплеск high/critical-рисков там, где надо было бы чинить что-то реальное. JFrog советует хотя бы на базовом уровне фильтровать свежие записи: смотреть, подтвердил ли проблему сам вендор; есть ли в ссылках коммит, pull request или другой проверяемый артефакт; не выглядят ли метаданные подозрительно неполными; соответствуют ли упомянутые функции и строки кода реальному устройству проекта. Для зрелых команд это не откровение, но теперь это уже не best practice, а гигиена выживания.
Любопытно и то, что мотивация авторов таких вбросов пока остается предметом догадок. В JFrog предполагают два сценария: кто-то пытается нарастить себе портфолио “исследователя”, штампуя фальшивые находки, или же кто-то сознательно влияет на работу автоматических систем, которые определяют, какие CVE считать значимыми. Обе версии пока не подтверждены, но даже без точного ответа проблема уже видна. Генеративный ИИ почти обнулил стоимость создания убедительно написанного advisory, а стоимость его верификации не сдвинулась. Это плохая математика для всей отрасли: атакующему или троллю достаточно минут, защитнику по-прежнему нужны часы.
Если эта асимметрия сохранится, рынок уязвимостей будет все сильнее напоминать спам-фильтр, который вынужден работать внутри критической инфраструктуры разработки. И тогда главным дефицитом станут не новые сканеры и не очередные дашборды, а доверие к самим данным, на которых строится управление рисками. Подробности истории собраны в материале .