Проверка конфигурации в MongoDB Server оставляет авторизацию выключенной и допускает отказ в обслуживании

MongoDB раскрыла сведения о двадцати трёх уязвимостях в серверной части своей базы данных. Среди них есть обход проверки прав, раскрытие чужих данных и падение рабочего процесса. Две проблемы не требуют учётной записи вовсе. Исправления вышли сразу в пяти ветках продукта. Среди заявленных последствий значатся нарушение целостности и конфиденциальности данных, обход политики безопасности, удалённый отказ в обслуживании и удалённое выполнение произвольного кода.

Детали уязвимостей

Одна из уязвимостей затрагивает разбор параметров запуска. Код проверки конфигурации неверно учитывает регистр символов. Поэтому параметр, включающий контроль доступа, в отдельных конфигурациях не срабатывает. Сервер поднимается с открытой авторизацией, хотя администратор считает её включённой. Любой, кто дотянется до порта, может выполнять административные операции. Проблема получила идентификатор CVE-2026-82067. Условия для неё специфические, зато последствия затрагивают конфиденциальность, целостность и доступность данных сразу.

Часть уязвимостей вообще не требует входа в систему. На узлах-арбитрах (участниках набора реплик, которые не хранят данные и нужны только для голосования) нарушается проверка внутреннего состояния. Посторонний пользователь отправляет запрос и останавливает процесс. Похожая история с маршрутизатором кластера (компонентом, который распределяет запросы между шардами). Неаутентифицированный клиент передаёт параметры мониторинга соединения, а процесс расходует процессорное время без ограничений. Обе уязвимости ведут к отказу в обслуживании, но данных не раскрывают.

Другая группа ошибок требует учётной записи, а последствия у неё тяжелее. В интеграции с LDAP (протоколом доступа к каталогу пользователей) пул соединений сохраняет прежнюю личность. Поэтому проверка ролей может выполняться от имени другого человека. В итоге учётная запись получает права, которых ей не выдавали. Это уже обход политики безопасности, а не случайный сбой. Проблема проявляется только там, где LDAP-авторизация настроена.

Остальное - ошибки работы с памятью и проверками ввода. В подсистеме учёта памяти при выполнении запросов освобождённая область используется повторно. При неудачном совпадении времени процесс либо падает, либо повреждает память. Настройки хранилища WiredTiger принимаются без должной проверки. Пользователь с правами на запись создаёт коллекцию с несовместимым параметром, и при чтении документов возникает несоответствие типов. Часть таких дефектов навсегда остаётся в метаданных. Тогда сервер падает снова после перезапуска, а сбой расходится по узлам кластера. Оператору приходится вмешиваться вручную. Отдельно отмечен обход выключенного механизма в командах репликации. Учётная запись с расширенными внутренними правами пишет в служебные таблицы хранилища напрямую.

Планировщик запросов тоже пострадал. Целочисленное переполнение при оценке числа вариантов обходит внутренний предел. Специально составленный запрос заставляет сервер безгранично расходовать память. Ещё одна ошибка приводит к чтению за границей буфера, и часть содержимого памяти может попасть в статистику запросов. Индексы 2dsphere (геопространственные) и разбор GeoJSON дают разыменование нулевого указателя. Разбор указателей пути в схеме JSON без ограничения глубины порождает отказ в обслуживании. Поиск совпадений по регулярному выражению ломается на многобайтовых символах UTF-8. В шардированных коллекциях специально составленное значение ключа шарда попадает в служебные запросы как оператор, а не как литерал.

Отдельная группа дефектов связана с правами. Интерфейс диагностики отдаёт учётные данные в открытом виде пользователю с правами мониторинга. Из журналов сервер те же данные вырезает, а здесь проверку не сделал. Логика агрегаций в ряде случаев проверяет не ту операцию, которую выполняет. Из-за этого учётная запись с минимальными правами читает данные чужих коллекций. На маршрутизаторе не скрываются строки поисковых запросов, поэтому пользователь с правами мониторинга видит чужие условия поиска.

Существенная деталь для оценки рисков. Большинство перечисленных уязвимостей требуют действующей учётной записи, часто с правами на запись. Значит, внешний периметр страдает меньше внутреннего. Однако две ошибки эксплуатируются без входа в систему, и именно они опасны для баз, выставленных в интернет. Кроме того, несколько дефектов оставляют после себя устойчивое состояние. Разовый сбой превращается в долгий простой с ручным восстановлением. Сведений об использовании этих уязвимостей в реальных атаках на момент раскрытия не публиковалось. При этом MongoDB хранит данные в компаниях разного масштаба, включая промышленные системы и крупные торговые сервисы. Поэтому даже остановка одного узла обходится дорого.

Исправления доступны в ветках 7.0.41, 8.0.30, 8.2.13, 8.3.9 и в предрелизной 9.0.0-rc2. Обновлять стоит не только основные узлы, но и арбитры, и маршрутизаторы. Проверьте, что контроль доступа действительно включён, а не только прописан в параметрах. Не выставляйте порты базы данных в открытые сети. Сократите круг учётных записей с правами на запись и на создание коллекций. Пользователям управляемого сервиса MongoDB Atlas обновляться вручную не нужно, провайдер делает это на своей стороне.

Поток исправлений такого размера показывает, как много логики в современной базе данных работает с недоверенным вводом. Проверки длины путей, глубины рекурсии, размеров массивов и регистра символов выглядят мелочами. На практике именно они отделяют рабочий сервер от недоступного. Поэтому доступ к базе по сети стоит ограничивать даже внутри периметра, а обновления ставить в день их выхода.

Детали уязвимостей

Ссылки