Главная история вокруг SQLite сейчас не в том, что библиотека внезапно стала опасной. Важнее другое: несколько устрашающих записей об уязвимостях успели выглядеть как authoritative signal, прежде чем проверка показала, что бага SQLite для исправления нет.

Спокойная проверка CVE: уязвимость помечена как неподтверждённая

JFrog Research разобрала шесть записей — CVE-2026-51296, CVE-2026-51297, CVE-2026-51300, CVE-2026-51302, CVE-2026-51303 и CVE-2026-51304. Они фигурировали как High/Critical в vulnerability metadata, но сейчас NVD показывает их как Rejected. Официальная страница SQLite перечисляет ту же группу с формулировкой “Not a bug in SQLite” и комментарием, что они unreproducible и appear to be AI hallucinations.

Вывод не в том, что CVE надо игнорировать. CVE — это входной сигнал, а не приговор. CVSS помогает расставлять приоритеты, NVD/GHSA/сканеры нужны, но этот случай показывает, что правдоподобный текст может двигаться быстрее, чем reproduction, maintainer confirmation и анализ применимости.

Почему это operational risk

Ложная Critical CVE не безобидна. Она открывает emergency tickets, блокирует релизы, вызывает вопросы клиентов, расходует время security и platform teams, заставляет maintainers писать опровержения. Если политика звучит как “patch every critical within 48 hours”, то несуществующая уязвимость превращается в denial-of-service для процесса vulnerability management.

JFrog проверяла не только описания. Исследователи смотрели исходники SQLite, собирали версии в изолированных Docker environments, запускали PoC под AddressSanitizer и сверяли metadata. Красные флаги оказались фундаментальными: функций нет в целевых версиях, номера строк ведут не туда или за конец файла, SQL невалиден, PoC не падают, заявленный patch не соответствует реальности проекта.

Почему SQLite — хороший пример

SQLite есть почти везде, поэтому “critical SQLite CVE” звучит страшно. Но сама SQLite давно подчёркивает применимость: многие реальные CVE требуют, чтобы атакующий мог выполнять arbitrary SQL или заставить приложение открыть malicious crafted database file. Наличие SQLite в SBOM ещё не означает, что конкретная CVE достижима в вашем продукте.

Теперь добавляется ещё один вопрос: прежде чем разбирать reachability, надо понять, существует ли bug вообще. Для команд это меняет порядок triage: vendor page, affected versions, reproducer, fix commit, attack path и scanner mapping важнее сырого score.

Что делать спокойно

Если сканер внезапно показывает Critical dependency CVE, сначала проверьте официальный источник: maintainer advisory, security page, release note, vendor statement. Затем подтвердите точную версию и компонент. После этого оцените достижимый путь атаки: есть ли untrusted SQL, импорт недоверенных database files, включён ли нужный feature, доступен ли код path.

Не запускайте подозрительные PoC на рабочих машинах. Если нужна проверка, используйте isolated containers и минимум прав. Если CVE rejected или disputed, оформите scanner exception с evidence и expiry: ссылка на NVD rejected status, страницу SQLite, внутреннюю оценку reachability, дату пересмотра. Не делайте вечные suppressions.

Что менять в политике

Security teams стоит завести состояние “unverified critical”. Это не “игнорировать”, а “быстро проверить, но не превращать в панику без evidence”. GRC-политики тоже должны быть context-aware: confirmed exploited risk, vendor-confirmed critical, scanner-only unverified critical, rejected record и non-reachable finding не должны иметь одинаковый SLA.

AI здесь не враг и не авторитет. Он может помогать искать и группировать сигналы, но production-grade advisory требует воспроизведения, evidence и человеческой проверки. Иначе fluent nonsense попадает в машинные процессы и выглядит как команда к действию.

Для пользователей SQLite ближайший вывод спокойный: шесть указанных записей rejected и отмечены SQLite как not bugs. Для security programs урок шире: зрелость — это не максимальная скорость паники, а способность быстро отделять reproducible risk от database noise.