MongoDB исправила ошибку в репликации: сервер падает без учётной записи

MongoDB выпустила исправления для уязвимости CVE-2026-118383 в MongoDB Server. Ошибка работы с памятью в механизме репликации позволяет удалённому клиенту без учётной записи уронить сервер, а в отдельных случаях, по оценке вендора, выполнить код в его процессе. Под удар попадают участники набора реплик, включая узлы шардов и серверы конфигурации, но одиночные экземпляры mongod не затронуты. Вендор оценил проблему в 9,5 балла по CVSS 4.0 и отнёс её к критическим.

Что известно об ошибке в репликации MongoDB

Суть ошибки

Проблема находится в компоненте репликации и проявляется на этапе догоняющей репликации, catch-up. Так называют момент, когда новый основной узел набора реплик получает изменения, пропущенные за время выбора, и только после этого начинает принимать записи. Набор реплик (replica set) - это группа серверов MongoDB, которые хранят копии одних данных и выбирают основной узел для записи.

В конце догоняющей репликации сервер очищает служебные ожидания, оставленные клиентскими запросами. Из-за ошибки очистка запускается дважды, и второй проход работает с уже освобождённой памятью. Это use-after-free, CWE-416: обращение к памяти после её освобождения. В результате процесс падает с нарушением доступа, а при определённых условиях, как указывает вендор, в том же процессе может быть выполнен код.

Как атакующий готовит сбой

Отдельная опасность в том, что подготовительная часть не требует аутентификации. Клиент отправляет на доступный участник набора реплик два запроса ping с параметром readConcern.afterOpTime. Каждый такой запрос создаёт ожидание, waiter - уведомление о том, что запрос ждёт достижения определённой точки репликации. MongoDB принимает ping до входа в систему, поэтому включённая аутентификация не мешает оставить такие ожидания.

Дальше сервер должен сам попасть в нужное состояние. Нужны отставание одного участника от остальных и выборы, в которых отставший узел становится основным. Атакующий не управляет ни тем, ни другим: и отставание, и смена основного узла случаются естественно, например при обслуживании или сбое. Зато после того как оба условия выполнены, сбой уже не зависит от гонки по времени. Очистка просто запускается дважды, и процесс падает до того, как новый основной узел примет первую запись.

Исследователи Datadog Security Labs воспроизвели падение на MongoDB Server 8.0.34. В лабораторной установке между подготовкой и сбоем прошло около 40 секунд, но это время задавали сами исследователи, поэтому для реальной атаки оно ничего не говорит. В их тестовом кластере после падения не осталось основного узла; в другом развёртывании сервер может выбрать новый и продолжить работу.

Затронутые версии

Уязвимы участники наборов реплик, включая узлы шардов и серверы конфигурации в шардированных кластерах. Одиночный mongod не выполняет догоняющую репликацию основного узла и под действие ошибки не попадает. Затронуты ветки 9.0.0-9.0.6, 8.3.0-8.3.15, 8.0.0-8.0.36, 7.0.0-7.0.47, 6.0.0-6.0.29, 5.0.0-5.0.34 и 4.4.0-4.4.31.

Исправленные выпуски: 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 и 4.4.32. Проверять версию нужно на каждом участнике, включая контейнеры и узлы, которые были выключены во время обслуживания. Кластеры MongoDB Atlas вендор обновляет автоматически в рамках планового обслуживания; тем, кто откладывает обслуживание, он советует не тянуть с установкой исправления.

Насколько это опасно

Вендор оценил уязвимость в 9,5 балла по CVSS 4.0 и в 9,0 по CVSS 3.1. Атака идёт по сети, учётная запись и действия пользователя не нужны. Сложность высокая: атакующий не контролирует выборы и отставание, поэтому сбой не гарантирован в каждом кластере. Но там, где условия совпали, отказ наступает надёжно.

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

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

Как заметить эксплуатацию

Первым признаком служат структурированные журналы MongoDB. В уязвимом прогоне каждый подготовительный запрос попадал в журнал как событие COMMAND "Slow query" с идентификатором 51803. Полезные поля - attr.command.ping, attr.command.readConcern.afterOpTime, attr.command.maxTimeMS, attr.errName со значением MaxTimeMSExpired, attr.durationMillis и attr.remote. Стоит искать неаутентифицированные команды с необычным временем операции и истёкшим ожиданием.

Перед падением в журнале появляется последовательность: участник входит в догоняющую репликацию (событие 21359), дважды выходит из неё (21363) в рамках одного перехода, а затем пишет о фатальном сигнале или приводит backtrace с CatchupState::abort_inlock(). Обычные выборы и один выход из догоняющей репликации такую картину не дают. Запросы могут прийти задолго до сбоя, поэтому смотреть нужно и более ранние записи того же участника, а не только события вокруг падения.

Полнота картины зависит от настроек логирования. Клиентские операции попадают в диагностический журнал, когда превышают порог медленных операций или когда включена подробность команд. Выборочная запись медленных операций и внешний конвейер могут отбросить объект команды, а в поле attr.remote иногда оказывается петлевой адрес вместо исходного адреса клиента.

Что делать

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

Если обновиться сразу нельзя, ограничьте сетевой доступ к MongoDB кругом систем, которым он действительно нужен. Это сокращает число клиентов, способных оставить ожидания, но не устраняет саму ошибку. Включение аутентификации подготовительную часть атаки не блокирует: ping принимается до входа в систему.

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