MongoDB выпустила версию 8.3.7 с исправлениями 24 уязвимостей и нескольких ошибок надёжности. Самая опасная проблема получила оценку 9,2 из 10 и при определённой конфигурации могла привести к повреждению памяти, поэтому администраторам MongoDB 8.3 стоит запланировать обновление.
Бюллетень HKCERT вывел MongoDB 8.3.7 в свежую повестку безопасности
24 июля 2026 года Гонконгский центр реагирования на компьютерные инциденты HKCERT опубликовал предупреждение о множественных уязвимостях MongoDB. Оно появилось через два дня после выхода MongoDB 8.3.7 и объединило сведения о проблемах, которые разработчики базы данных закрыли в нескольких поддерживаемых ветках.
Сама версия 8.3.7 вышла 22 июля. В официальных примечаниях к выпуску MongoDB 8.3 разработчики называют её обновлением безопасности и надёжности. В changelog перечислены 24 идентификатора CVE, а MongoDB Alerts раскрывает условия эксплуатации и оценки опасности. Рядом в примечаниях к выпуску указан отдельный набор исправлений для планировщика запросов, транзакций, TLS, Queryable Encryption, серверного JavaScript и проверки входных данных.
Для владельца сервера номер патча выглядит небольшим изменением: 8.3.6 сменяется на 8.3.7. Содержимое выпуска гораздо весомее. Несколько ошибок позволяли аварийно завершить процесс mongod, перегрузить память или процессор, обойти отдельные ограничения доступа и раскрыть данные при специально подготовленном запросе.
CVE-2026-13072 получила оценку 9,2 за риск повреждения памяти
Самая серьёзная уязвимость в наборе — CVE-2026-13072 с оценкой CVSS 9,2. Она связана с недостаточной проверкой BSON-данных, поступающих из внешнего источника в режиме Compute Mode. BSON — двоичный формат, в котором MongoDB хранит и передаёт документы.
При выполнении конкретных условий специально сформированные данные могли вызвать повреждение памяти. Ошибка затрагивала MongoDB 8.3 до версии 8.3.7, а исправления для других поддерживаемых веток вошли в MongoDB 8.2.12, 8.0.28 и 7.0.39.
Риск зависит от конфигурации: в описании MongoDB указаны автономный процесс mongod, включённый Compute Mode и обработка внешнего BSON. Такая комбинация встречается реже стандартной установки, но высокая оценка отражает возможные последствия — нарушение целостности памяти и потенциально более тяжёлое развитие атаки.
Ошибки контроля доступа затрагивали RBAC, Atlas Search и агрегации
Сразу несколько исправлений касаются разграничения прав. MongoDB использует RBAC — ролевую модель, где пользователь получает только разрешённые операции с базами, коллекциями и административными функциями. Ошибка в такой проверке опасна тем, что корректно созданная учётная запись может выйти за пределы своей роли.
CVE-2026-13059 получила оценку 8,6. В конфигурациях без строгого режима API пользователь с небольшим набором прав мог добиться несанкционированного чтения или изменения данных через особенности проверки запросов. Уязвимость затрагивала несколько веток MongoDB, включая все версии 8.3 до 8.3.7.
CVE-2026-13057 относилась к Atlas Search. Недостаточная проверка параметров $search.mergingPipeline могла позволить обойти ограничения доступа при определённом запросе. Исправление добавило валидацию стадии объединяющего конвейера.
CVE-2026-13060 была связана с $graphLookup — оператором агрегации для обхода связанных документов. Повторяющиеся поля from в специально составленном запросе могли привести к обращению к коллекции без ожидаемой проверки разрешений.
Отдельный патч для killCursors устраняет сценарий, при котором право на завершение курсора проверялось с учётом пространства имён, указанного клиентом. Курсор хранит состояние чтения результатов, поэтому такая команда должна применяться только к разрешённой операции и корректной базе.
Специальные запросы могли перегрузить память и остановить mongod
Заметная часть бюллетеня посвящена отказу в обслуживании. В этом сценарии атакующий не обязательно получает данные: он формирует запрос, который заставляет сервер расходовать слишком много памяти, процессорного времени или аварийно завершить работу.
CVE-2026-13056 затрагивала выражения $concatArrays и $range. Пользователь с правом чтения мог создать очень большой промежуточный массив и довести процесс до исчерпания памяти. В MongoDB 8.3.7 для таких операций добавили дополнительные проверки потребления ресурсов.
CVE-2026-13064 позволяла вызвать чрезмерную нагрузку на процессор через специально подготовленную схему $jsonSchema. CVE-2026-13065 могла завершить процесс при некорректном выражении sortBy внутри $linearFill, который заполняет пропуски в последовательностях данных.
CVE-2026-13074 затрагивала команду hello, используемую клиентами для определения состояния сервера и топологии кластера. Удалённый клиент без аутентификации мог многократно отправлять awaitable-запросы с очень малым maxAwaitTimeMS, создавая горячий цикл и расходуя вычислительные ресурсы.
Ещё две проблемы касались новых механизмов объединения результатов поиска. Некорректные запросы к $rankFusion и $scoreFusion могли вызвать неограниченный рост памяти. Эти стадии объединяют и ранжируют результаты нескольких поисковых конвейеров, поэтому исправление ограничивает обработку опасных входных данных.
Серверный JavaScript и BSON получили усиленную проверку
MongoDB поддерживает выполнение JavaScript в некоторых выражениях и операциях. Эта возможность расширяет логику обработки данных, но одновременно добавляет отдельный слой исполнения, которому требуется строгая проверка типов, модулей и объектов.
CVE-2026-13066 затрагивала объект DBPointer в серверном JavaScript и могла привести к раскрытию содержимого памяти. CVE-2026-13071 была связана с ошибкой безопасности памяти в $function и могла аварийно завершить процесс. Исправление закрывает сценарий use-after-free, при котором код обращается к уже освобождённому участку памяти.
CVE-2026-13077 касалась обработки BSONColumn с некорректным значением CodeWScope. Специально подготовленный двоичный блок мог вызвать чтение за границами выделенной памяти. CVE-2026-13078 исправляет загрузчик модулей MozJS: при наличии локального доступа серверный JavaScript мог использовать его для чтения файлов.
Для установок, где серверный JavaScript не используется, администраторы часто отключают эту возможность параметром security.javascriptEnabled. Даже при таком ограничении требуется исправленная версия, поскольку MongoDB 8.3.7 закрывает уязвимости и в других подсистемах.
Queryable Encryption получила исправления проверки команд и ресурсов
Queryable Encryption позволяет выполнять запросы по зашифрованным полям, сохраняя содержимое скрытым от сервера в открытом виде. Механизм сложный: клиент, сервер и библиотека libmongocrypt обмениваются служебными структурами и метаданными, которые должны проходить строгую проверку.
В MongoDB 8.3.7 исправлены ошибки в обработке внутренних флагов FLE2, метаданных и коэффициента contention factor. Один сценарий позволял отправить команду записи с некорректными внутренними параметрами, другой создавал чрезмерную нагрузку на ресурсы при обработке зашифрованных запросов.
Отдельная уязвимость в libmongocrypt могла привести к завершению клиентского процесса из-за недостаточной проверки входных данных. Это затрагивает приложения, которые используют автоматическое шифрование полей через официальные драйверы и библиотеку MongoDB.
Патчи одновременно вышли для MongoDB 7.0, 8.0, 8.2 и 8.3
Исправления распределены по четырём актуальным веткам. Для MongoDB 8.3 целевой версией стала 8.3.7, для 8.2 — 8.2.12, для 8.0 — 8.0.28, для 7.0 — 7.0.39. Состав патчей различается, поскольку отдельные функции и уязвимые участки присутствуют не во всех ветках.
Выбирать нужно выпуск внутри используемой ветки. Переход с 8.0 на 8.3 ради одного бюллетеня добавит изменения уровня функциональной версии и отдельную проверку совместимости. Установка 8.0.28 на уже работающий кластер 8.0 сохраняет привычную линию обновлений и закрывает уязвимости, исправленные для этой ветки.
Текущую версию сервера можно проверить командой mongod --version на узле или методом db.version() в mongosh. В replica set и шардированном кластере проверка должна охватить все процессы mongod и mongos: оставшийся узел со старой сборкой сохраняет уязвимый код до завершения поэтапного обновления.
Обновление MongoDB 8.3.7 требует проверки совместимости и резервного плана
MongoDB разрешает понижение только между соседними версиями, а функции, несовместимые с целевой веткой, приходится заранее отключать или удалять. Для обычного патча внутри 8.3 эта оговорка редко становится проблемой, но она влияет на план отката после изменения Feature Compatibility Version или сопутствующей миграции.
Перед развёртыванием 8.3.7 полезно проверить драйверы, резервное копирование, мониторинг и собственные расширения вокруг базы. Затем патч можно провести по стандартной схеме rolling upgrade: последовательно обновлять вторичные узлы replica set, выполнить переключение первичного узла и завершить обновление оставшегося экземпляра. Точный порядок зависит от архитектуры и правил эксплуатации конкретного кластера.
При использовании Atlas обслуживание версий управляется платформой, а окно и статус обновления видны в панели проекта. Для самостоятельно размещённой MongoDB пакет или контейнер должен поступать из официального репозитория, поскольку совпадение номера версии в стороннем образе ещё не подтверждает происхождение сборки.
MongoDB 8.3.7 стала базовой безопасной версией для ветки 8.3
Патч 8.3.7 закрывает широкий набор проблем: повреждение памяти, обход отдельных проверок доступа, отказ в обслуживании, ошибки Queryable Encryption, TLS и серверного JavaScript. Свежий бюллетень HKCERT от 24 июля подтверждает актуальность обновления, а официальный changelog MongoDB даёт точный перечень CVE и исправленных задач.
Для функционирующих систем на базе версии 8.3 есть четкое руководство к действию: все версии ниже 8.3.7 содержат код, который MongoDB официально признала небезопасным. Необходимость обновления зависит от степени доступности сервера извне, задействованных функций и назначенных ролей, однако ждать следующего крупного релиза для установки патча нецелесообразно.
