В начале недели в GitHub появился репозиторий, авторы которого опубликовали серию бюллетеней об уязвимостях в SQLite. Всего там было заявлено более 50 CVE, и большинство из них, как выяснилось при проверке, не имеют отношения к реальности. Национальная база уязвимостей NVD и Агентство по кибербезопасности CISA оперативно присвоили этим записям высокие баллы, однако последующий аудит показал, что описания содержат ссылки на несуществующие функции, выдуманные патчи и некорректные номера строк кода.
Одним из наиболее показательных примеров стал CVE-2026-51302. В бюллетене утверждалось, что в SQLite 3.41 существует ошибка использования после освобождения (обращение к уже удалённой области памяти) в функции, которой в этой версии не было. Функция, о которой шла речь, появилась в кодовой базе только спустя несколько лет, поэтому заявленный механизм атаки не мог реализоваться в принципе. Другой CVE, CVE-2026-51303, ссылался на исправление в версии 3.51.3, однако сравнение исходников показало, что в этой версии не менялся ни один из заявленных файлов. Приведённый в бюллетене код эксплойта не только не вызывал ошибок, но и не проходил стадию синтаксического разбора SQL-запроса.
Исследователи, проводившие проверку, использовали изолированное окружение: они клонировали официальный репозиторий SQLite, собирали указанные версии в контейнерах и запускали все предоставленные PoC-сценарии под инструментом AddressSanitizer, который отслеживает ошибки работы с памятью. Ни один из шести детально разобранных CVE не подтвердился. В части описаний фигурировали номера строк, выходящие за пределы файлов, в других случаях функции существовали, но с другим количеством аргументов. Например, для CVE-2026-51296 указывались строки 3555 и 3575 в файле json.c, тогда как в целевой версии этот файл содержал всего 2706 строк.
Отдельного внимания заслуживает оценка со стороны Red Hat. Изначально компания присвоила CVE-2026-51302 максимальный балл 10.0 по шкале CVSS и статус Critical, однако уже на следующий день снизила его до 7.6 (High). Такая динамика подтверждает, что даже крупные организации не всегда могут оперативно отличить реальную уязвимость от грамотно составленной фикции.
Возникает закономерный вопрос, как подобные записи проходят модерацию в национальных базах. Процесс подачи сведений о CVE через публичную форму MITRE не требует подтверждения личности автора и не предусматривает обязательной проверки работоспособности приложенного эксплойта. Раньше NIST выполняла функцию фильтра: специалисты вручную анализировали каждое поступление, проверяли его согласованность и только потом публиковали. Однако в феврале 2024 года, столкнувшись с резким ростом числа заявок, NIST фактически приостановила глубокую проверку. CISA и другие авторизованные издатели данных попытались взять эту работу на себя, но общий конвейер оказался перегружен, а целостность процесса нарушена. В результате правдоподобно звучащая подделка может попасть в такие базы, как GHSA, и затем распространиться по корпоративным сканерам безопасности.
Особую опасность это представляет для систем автоматического анализа уязвимостей. Если организация доверяет критическим оценкам из внешних источников и автоматически открывает тикеты на устранение, то фейковый CVE способен запустить цепочку ложных действий. AI-агент, предназначенный для поиска и исправления ошибок, может начать искать несуществующую функцию в коде, генерировать патч или рекомендовать изменения, которые не имеют отношения к реальной безопасности. Вместо того чтобы помогать специалистам, такие системы будут вводить их в заблуждение и тратить ресурсы на несуществующую проблему.
В данной ситуации эксперты советуют придерживаться нескольких принципов. Прежде всего, не следует доверять новым CVE, опубликованным неизвестными или непроверенными источниками. Нужно сверяться с официальными бюллетенями производителя, в случае SQLite это страница sqlite.org/cves.html, и проверять, есть ли в описании ссылка на коммит или запрос на изменение кода. Пустые поля CPE в метаданных, противоречия между заявленной версией и описанием, а также упоминания функций, которых нет в указанной версии, должны вызывать подозрение. Если есть возможность, любой критический CVE стоит воспроизвести в изолированной среде с помощью приложенного PoC до того, как начинать планировать работы по исправлению.
Масштаб проблемы подтверждается широким анализом: из 55 бюллетеней, опубликованных тем же GitHub-аккаунтом, только один содержал реальный дефект, остальные были полностью сфабрикованы. Это наглядная иллюстрация того, как слабости системы приёма CVE позволяют генерировать мусорные записи, которые затем попадают в авторитетные базы данных и вводят в заблуждение специалистов по безопасности во всём мире. Пока процесс не станет более строгим, подобные случаи будут повторяться, а доверие к системе идентификации уязвимостей продолжит снижаться.
