Две команды до сбоя: критическая уязвимость в MongoDB

CVE-2026-118383 получила оценку 9,5 из 10 по шкале CVSS 4.0. Уязвимость в MongoDB Server позволяет клиенту без учётных данных отправить два запроса, которые при определённом развитии событий приведут к аварийному завершению сервера. MongoDB сообщила, что обнаружила проблему сама и ей «не известно о попытках воспользоваться этой уязвимостью». При некоторых условиях возможен и запуск произвольного кода в процессе сервера, однако Datadog Security Labs не смогла добиться выполнения кода в лаборатории, а опубликованный эксплойт на это не претендует.

Риск касается участников репликационных наборов MongoDB. В такой группе серверов основной узел, primary, принимает новые записи, а остальные копируют изменения. Если основной узел становится недоступен, участники выбирают нового. Перед тем как принимать записи, победивший узел догоняет пропущенные изменения. Уязвимость затрагивает также участников шардированных кластеров, включая серверы шардов и конфигурационные серверы. Отдельный mongod, не входящий в репликационный набор, ей не подвержен.
Причина сбоя — ошибка класса use-after-free: сервер обращается к памяти после её освобождения. Злоумышленник отправляет два ping с параметром readConcern.afterOpTime. Каждый запрос просит дождаться определённой точки репликации, и сервер создаёт для него ожидающее уведомление — waiter. Сами по себе эти уведомления сервер не обрушивают и не истекают по времени: они сохраняются, пока участник не перезапустится, не выполнит откат или не перестанет быть основным.
Для сбоя узел должен сначала получить запросы, затем отстать от другого участника и позднее выиграть выборы, оставаясь позади. Когда новый primary завершает догоняющую синхронизацию, очистка запускается дважды и повторно использует уже освобождённую память. Сервер падает до того, как успевает принять записи. По словам исследователей, после выполнения этих условий сбой не зависит от гонки за время. Но атакующий не может сам заставить узел отстать или выиграть выборы и не видит, когда именно происходят эти события.
Datadog Security Labs воспроизвела сбой в лаборатории и опубликовала результаты вчера; календарная дата в сообщении не указана. Исследователи использовали административный доступ, чтобы приостанавливать и останавливать процессы mongod, намеренно создавая отставание и переключение основного узла. Без учётных данных работал только клиент, отправлявший два запроса; записывать данные в базу он не мог. На MongoDB 8.0.34 участник завершился с ошибкой сегментации, и в лабораторном кластере не осталось primary. В другой конфигурации основной узел мог бы выбраться заново, и кластер продолжил бы работу.
В исправленной версии 8.0.37 оба запроса сразу отклонялись как неавторизованные, а участник продолжал работать. По объяснению исследователей, одна часть исправления разрешает использовать readConcern.afterOpTime только системным пользователям. Другая не даёт очистке выполниться повторно, даже если waiters уже созданы; эту часть команда Datadog самостоятельно не проверяла. В отдельном лабораторном тесте с отключённой аутентификацией версия 8.0.37 приняла созданные уведомления, но выполнила очистку только один раз. Эти результаты не позволяют оценить, как часто атака сработает в других средах.
MongoDB выпустила исправления ранее на этой неделе, но календарная дата не приведена. Исправленный выпуск для каждой затронутой ветки указан в записи CVE и объявлении компании; уязвимы все более ранние версии ветки, начиная с её первого выпуска. В качестве примеров указаны уязвимая 8.0.34 и исправленная 8.0.37. Полный перечень затронутых веток и номера исправлений для каждой из них в доступных данных не приведены.
В перечне затронутых версий нет ветки 8.2, последним выпуском которой указан 8.2.12. При этом автор опубликованного на GitHub доказательства концепции сообщает, что 8.2.12 проявила ошибку в лабораторном тесте с настройкой, предназначенной только для тестирования. Надёжный режим PoC требует именно такой настройки, которую удалённый атакующий включить не может. Автор описывает последствия как сбой или повреждение памяти, но не заявляет о выполнении кода. Ветка 8.2 достигла конца жизненного цикла 31 июля; год не указан. После этого версии ветки больше не получают обновлений, в том числе исправлений безопасности.
Кластеры MongoDB Atlas, согласно объявлению компании, получают исправленные версии автоматически во время обслуживания. Клиентам, отложившим обслуживание, следует установить обновление как можно скорее. При самостоятельном управлении обновить нужно каждый узел репликационного набора, а затем проверить реально работающую версию на каждом участнике, включая контейнеры и серверы, которые были выключены во время обслуживания. Пока обновить узел невозможно, исследователи советуют ограничить сетевой доступ к базе системами, которым он действительно нужен. Это сокращает круг возможных отправителей, но не устраняет уязвимость. Одна лишь включённая аутентификация на уязвимой версии два запроса не блокирует.
Для поиска возможной эксплуатации исследователи предлагают проверить структурированные журналы. Ищите запись COMMAND "Slow query" с ID 51803: в ней должен фигурировать неаутентифицированный ping с readConcern.afterOpTime, завершившийся MaxTimeMSExpired. Затем проверьте, не входил ли узел в режим догоняющей синхронизации primary catch-up — событие ID 21359 — и не выходил ли из него дважды при одном переключении: выход обозначается ID 21363. После таких записей подозрительным будет фатальный сигнал или трассировка стека с CatchupState::abort_inlock(). Обычные выборы или одиночный выход из режима догоняющей синхронизации сами по себе не указывают на эту уязвимость. Запросы могли поступить задолго до переключения, поэтому нужно просмотреть более ранние журналы того же участника. Набор видимых полей зависит от настроек логирования, а attr.remote может содержать адрес loopback, а не настоящий IP клиента.