ainews
LLM-спам в CVE: как фейковые уязвимости SQLite получили критический статус
GitHub-аккаунт опубликовал 50+ фейковых CVE для SQLite, сгенерированных нейросетью. NIST и CISA автоматически присвоили им критические оценки (вплоть до 10.0), но проверка JFrog показала: код из описаний вообще не существует в указанных версиях. Из 55 заявок реальной оказалась только одна. Система публикации CVE сломана — любой может отправить выдумку, и она попадёт в базы данных уязвимостей без верификации.
Если вы разработчик, DevOps или отвечаете за безопасность — вы больше не можете слепо доверять CVE. Если вы бизнес — вы тратите деньги на фейковые алерты. Если вы инвестор — перед вами рынок, где доверие к базовой инфраструктуре рушится.
Что случилось: новый аккаунт на GitHub опубликовал серию advisory с критическими уязвимостями SQLite (CVE-2026-51302 и другие). NIST и CISA автоматически присвоили им максимальные оценки угрозы — вплоть до 10.0 баллов. Но когда исследователи JFrog решили проверить детали, выяснилось: большинство описаний — чистая выдумка.
Примеры:
- Функция exprComputeOperands() из отчёта о CVE-2026-51302 вообще не существовала в SQLite 3.41 — её добавили только в 2025 году.
- Упомянутая функция jsonBlobEdit() появилась позже заявленной версии.
- Строки кода из описаний ссылаются на комментарии или вообще не существуют (файл на 2706 строк, а в отчёте фигурируют строки 3555 и 3575).
- PoC-запросы либо падают на стадии парсинга, либо выполняются без ошибок — заявленные баги не воспроизводятся.
Корень проблемы: MITRE позволяет отправлять CVE через публичную форму без проверки личности. NIST с февраля 2024 года перестал глубоко анализировать заявки из-за перегрузки, и система превратилась в конвейер: правдоподобное описание проходит в базы данных без верификации. Из 55 advisory от этого аккаунта реальной оказалась только одна уязвимость.
Автор: Сергей Ефимов · Источник: hnrss.org
Разработчикам. Если вы поддерживаете SQLite или зависите от него — не паникуйте из-за новых CVE без проверки деталей. Смотрите на исходники, ищите патчи в официальном репозитории и требуйте PoC. Автоматические сканеры уязвимостей теперь могут генерировать ложные срабатывания на промышленных масштабах.
Бизнесу. Компании тратят ресурсы на расследование несуществующих угроз, потому что системы безопасности доверяют официальным базам CVE. Нужны процессы ручной верификации критических алертов и внутренние политики приоритизации — не всё из NVD теперь достоверно. Риск: регуляторные требования могут заставить патчить фантомные уязвимости.
Инвесторам. Экосистема кибербезопасности перегружена и автоматизирована до критической точки. Растёт спрос на инструменты верификации CVE, threat intelligence с человеческой экспертизой и платформы для фильтрации шума. Уязвимость самой инфраструктуры CVE — это долгосрочный риск для всей индустрии, но и возможность для стартапов, которые решат проблему доверия.
- CVE Verification as a Service: платформа с экспертами, которая проверяет реальность критических уязвимостей до того, как компании начнут тратить ресурсы на патчинг
- AI-детектор LLM-спама в advisory: инструмент для автоматического выявления признаков сгенерированных нейросетью CVE (несуществующие функции, несоответствие версиям)
- Threat Intelligence фильтр для DevSecOps: плагин для CI/CD, который отсеивает недостоверные CVE из сканеров вроде Dependabot или Snyk
- Консалтинг по приоритизации уязвимостей: помощь компаниям в создании процессов ручной верификации критических CVE и снижении шума от автоматических алертов
- Платформа для краудсорсинговой верификации CVE: комьюнити исследователей проверяет реальность заявок и голосует за достоверность
- Система CVE теряет доверие индустрии — если фейки становятся нормой, компании начнут игнорировать реальные угрозы
- NIST и CISA могут ужесточить процесс подачи CVE, что замедлит публикацию настоящих критических уязвимостей
- Юридические риски: компании могут столкнуться с требованиями регуляторов патчить несуществующие баги, если они попали в официальные базы
- Атаки через шумовую завесу: злоумышленники могут специально генерировать фейковые CVE, чтобы замаскировать реальные эксплойты в потоке информации
Это не баг, это фича современной системы CVE. Когда любой может отправить описание уязвимости через форму, а NIST с февраля 2024 перестал проверять заявки вручную из-за перегрузки — мы получаем конвейер фейков. LLM-генерация делает этот спам правдоподобным: функции, строки кода, технические термины. Но стоит открыть исходники — и всё разваливается: функций нет в той версии, строки кода ведут в никуда, PoC не воспроизводятся.
Для индустрии это катастрофа: компании тратят ресурсы на расследование фантомных угроз, автоматические сканеры генерируют шум, а реальные баги тонут в потоке. Но это и возможность: рынок отчаянно нуждается в инструментах верификации CVE, фильтрации спама и threat intelligence с человеческой экспертизой. Если вы думаете про стартап в кибербезопасности — вот ваша проблема.
Комментарии