Десяток спорных CVE в SQLite: почему разработчики не признают уязвимости в JSON-функциях

Что произошло с SQLite

SQLite — это самый распространённый в мире движок баз данных: он встроен в браузеры, мобильные приложения, операционные системы и тысячи настольных программ, а данные хранит в одном компактном файле .sqlite, .db или .sqlite3. Именно поэтому любая новость про «дыру в SQLite» моментально расходится по лентам.

27 и 28 июля 2026 года в публичных базах уязвимостей появилась серия из примерно десятка записей — CVE-2026-51291 … CVE-2026-51304. Все они описывают ошибки класса use-after-free (обращение к уже освобождённой памяти) в старой версии SQLite 3.41: часть — в функциях разбора JSON, часть — в механизме вычисления выражений. Некоторым записям сторонние аналитики присвоили статус «критических» с оценкой CVSS до 9.8.

На первый взгляд — повод для паники. На деле это классический случай, когда громкая формулировка CVE и реальная картина расходятся. Разберём по порядку.

В чём суть заявленных уязвимостей

Записи описывают ошибки работы с памятью в конкретных внутренних функциях SQLite. По описаниям в GitHub Advisory Database и агрегаторах, среди затронутых участков называют:

• функции разбора и извлечения JSON — jsonParseFree(), jsonCacheInsert(), jsonRemove() и связанные с ними;
• вычисление выражений — sqlite3ReleaseTempReg() и exprComputeOperands(), где, по версии авторов, регистр освобождается раньше, чем к нему обращаются.

Теоретический сценарий во всех записях примерно одинаков: специально составленный JSON или SQL-запрос заставляет движок обратиться к освобождённой памяти, что «может привести» к отказу в обслуживании, утечке данных или выполнению кода. Важная оговорка — эксплуатация требует, чтобы приложение выполняло недоверенный SQL или разбирало недоверенный JSON внутри самой СУБД. Для подавляющего большинства программ, которые просто читают и пишут собственный файл базы, это нетипичный сценарий.

Почему разработчики SQLite их не признают

У SQLite давно есть публичная и жёсткая позиция по CVE. На официальной странице о безопасности команда прямо пишет, что не ведёт CVE и не считает их достоверным источником. Дословно:

«Почти все ошибки, о которых сообщают CVE, — это просто ошибки, а не настоящие уязвимости. Называть их уязвимостями — значит растягивать смысл слова, и разработчики SQLite не хотят участвовать в этом обмане».

Там же уточняется, что все CVE об SQLite создаются третьими сторонами, часто без участия основной команды, и «нередко содержат неточности». Проще говоря, появление записи в NVD ещё не означает, что SQLite действительно опасен, — многие такие «уязвимости» ссылаются на давно исправленные баги.

Свежая серия — наглядная иллюстрация. Запись CVE-2026-51298, опубликованная 27 июля, уже к 31 июля была отозвана регистратором с формулировкой: «Дальнейшее расследование показало, что это не проблема безопасности». То есть часть «десятка критических уязвимостей» на поверку оказывается вовсе не уязвимостями.

Дело в старой версии 3.41

Ещё одна деталь, которую теряют пугающие заголовки: вся серия нацелена на SQLite 3.41. Эта версия вышла в начале 2023 года, и с тех пор проект выпустил десятки релизов. Актуальная стабильная версия на момент новости — SQLite 3.53.2 (выпущена 3 июня 2026 года), и в списке официально признанных проблем этих записей нет.

Практический смысл простой: даже если отдельные ошибки в коде трёхлетней давности реальны, современных сборок SQLite они не касаются. А поскольку SQLite почти всегда поставляется «встроенным» внутри другой программы — вместе с браузером, мессенджером или мобильным приложением — свежую версию движка вы получаете вместе с обычными обновлениями софта, часто даже не подозревая об этом.

Что делать прямо сейчас

Отдельной «заплатки для файла базы» тут не нужно — данные в .db или .sqlite сами по себе безопасны. Реагировать стоит только разработчикам и администраторам, у которых SQLite встроен в их продукт:

1. Проверьте версию движка в своём приложении — запросом SELECT sqlite_version(); или по версии подключённой библиотеки.
2. Если это старая ветка (3.41 и близкие), обновите SQLite до актуальной — на момент новости это 3.53.2. Обновление закрывает и настоящие баги, накопленные за три года.
3. Не выполняйте произвольный SQL и не разбирайте JSON из недоверенных источников внутри СУБД без ограничений — это базовое правило независимо от конкретных CVE.
4. Не спешите переписывать риски в отчётах по одной строке из NVD: сверяйтесь с официальной позицией SQLite и статусом записи (не отозвана ли она).

Обычным пользователям, которые открывают файл базы просмотрщиком, делать вообще ничего не нужно. Если же вы только разбираетесь, что за файл перед вами и чем его открыть, пригодятся наши справки — чем открыть файл базы данных MDF и чем открыть файл JSON.

Что это значит для работы с файлами баз данных

Главный вывод у этой истории тот же, что и у недавней шумихи вокруг библиотеки Fastjson: опасность живёт не в формате файла, а в программе, которая его читает. Файл SQLite или документ JSON — это просто структурированные данные; риск появляется лишь тогда, когда их обрабатывает устаревший или уязвимый код.

Но у SQLite есть и второй урок — об информационной гигиене. Поток CVE давно превратился в шумный канал, где рядом с реальными проблемами соседствуют дубликаты, ошибки и уже исправленные баги. Умение отличить настоящую угрозу от раздутого заголовка — такой же навык безопасности, как своевременные обновления. Больше практических правил проверки данных и загрузок — в разделе безопасность файлов.

Источники

• SQLite.org — официальная позиция разработчиков по CVE и список признанных проблем
• GitHub Advisory Database — CVE-2026-51297 (use-after-free в разборе JSON, SQLite 3.41)
• NVD — CVE-2026-51298 (запись отозвана регистратором)