MongoDB устранила критическую уязвимость CVE-2026-118383 в MongoDB Server. Неаутентифицированный клиент может отправить два специально сформированных запроса, после чего узел способен аварийно завершить работу при последующем избрании primary. Для реализации сценария целевой сервер должен выиграть выборы, оставаясь без части последних изменений, — это существенно ограничивает практическую эксплуатацию.
Компания оценила проблему в 9,5 балла из 10 по CVSS 4.0. Это ошибка use-after-free: процесс сервера обращается к уже освобождённой памяти. MongoDB заявила, что обнаружила дефект самостоятельно и не располагает сведениями о попытках эксплуатации.
Какие развёртывания затронуты
Риск относится к участникам replica set, включая shard server и config server в шардированных кластерах. В replica set один узел выполняет роль primary и принимает новые записи, остальные поддерживают копии данных. При недоступности primary участники выбирают нового лидера.
Автономный процесс mongod, не входящий в replica set, уязвимости не подвержен.
Исправленные выпуски доступны для всех затронутых веток. Проблема касается более ранних версий внутри соответствующей ветки, начиная с её первого релиза. MongoDB не включила версию 8.2 в перечень затронутых. Однако автор опубликованного доказательства концепции сообщил, что в лабораторном тесте с настройками, предназначенными исключительно для тестирования, уязвимость проявлялась и в MongoDB 8.2.12 — последнем выпуске этой ветки.
Поддержка ветки 8.2 завершилась 31 июля, поэтому после этой даты она не получает обновлений, включая исправления безопасности.
Как возникает сбой
Исследователи Datadog Security Labs воспроизвели проблему в лаборатории. По их данным, аутентификация в уязвимых версиях не блокирует два необходимых запроса.
Это команды ping с параметром readConcern[.]afterOpTime. Они требуют ждать, пока репликация достигнет заданной точки, и создают на сервере ожидающее уведомление — waiter. Само создание waiter не приводит к аварийному завершению: такие объекты не истекают и сохраняются до перезапуска узла, отката либо потери им роли primary.
Чтобы произошёл сбой, узел, получивший запросы, должен затем победить на выборах, хотя он может отставать от другого участника. Перед приёмом новых записей избранный primary догоняет репликацию, применяя пропущенные операции. После этого запускается процедура очистки.
При выполнении условий атаки очистка срабатывает дважды и повторно использует освобождённую память. Новый primary падает до приёма хотя бы одной новой записи. По оценке исследователей, после выполнения этих условий результат не зависит от гонки по времени.
При этом удалённый атакующий не может принудить узел отстать по репликации, обеспечить его победу на выборах или определить момент наступления этих событий. Поэтому лабораторное воспроизведение не означает, что отказ будет так же воспроизводим в иных конфигурациях.
Что показали лабораторные проверки
В эксперименте исследователи сами создали отставание и инициировали переключение на резервный узел. Для этого они использовали административные права, чтобы приостановить и остановить процессы mongod. Со стороны клиента без учётных данных поступили только два запроса; этот клиент не мог записывать данные в БД.
На MongoDB 8.0.34 узел завершился с ошибкой сегментации, а лабораторный кластер остался без primary. В другой топологии мог быть избран иной primary, после чего система продолжила бы работу.
В исправленной версии 8.0.37 сервер немедленно отклонил оба запроса как неавторизованные, и узел не остановился. Одна часть исправления ограничивает использование readConcern[.]afterOpTime системными пользователями.
Новости информационной безопасности, технологий и государственного регулирования, а также анонсы новых исследований Tech Threat Lab.
Для разбора таких событий нужны журналы запросов, смены состояния узла и аварийных завершений в одной временной шкале. Эти требования к сбору и сопоставлению событий можно соотнести с описанием на официальной странице Security Capsule SIEM для оценки применимости к требованиям инфраструктуры: в данном случае критично сохранить связь между ping с readConcern[.]afterOpTime, catchup и падением процесса.
MongoDB также указывает, что при определённых условиях дефект способен привести к выполнению произвольного кода в процессе сервера. Исследователи не смогли добиться выполнения кода в лабораторной среде и не оценивали, как часто такой сценарий может сработать в других конфигурациях.
Опубликованное доказательство концепции воспроизводит проблему в лабораторном replica set. Для надёжной работы ему требуется тестовая настройка, которую удалённый атакующий включить не может. Заявленные последствия этого кода — сбой процесса или повреждение памяти; о выполнении кода в нём не говорится.
Вторая часть исправления не позволяет запускать очистку дважды, даже если waiter уже были созданы. Исследователи не тестировали эту часть патча самостоятельно. В отдельном испытании доказательства концепции с отключённой аутентификацией MongoDB 8.0.37 приняла подставленные waiter, но выполнила очистку только один раз.
Обновление и временное ограничение риска
MongoDB Atlas получает исправленные версии автоматически во время технического обслуживания. Организациям, которые ранее отложили такое обслуживание, следует выполнить обновление.
В самостоятельно управляемых развёртываниях исправленный релиз нужно установить на каждом узле replica set. После обслуживания следует проверить фактическую версию на всех участниках, включая контейнерные узлы и серверы, выключенные во время обновления.
До установки обновления исследователи рекомендуют ограничить сетевой доступ к MongoDB только системами, которым он необходим. Это сокращает круг клиентов, способных отправить два запроса, но не устраняет саму уязвимость.
Что проверить в журналах
Для поиска попыток подстановки waiter или последствий сбоя стоит проверить структурированные журналы MongoDB на последовательность признаков, наблюдавшихся исследователями при тестировании:
- запись COMMAND «Slow query» с ID 51803 для неаутентифицированного запроса ping с readConcern[.]afterOpTime, завершившегося ошибкой MaxTimeMSExpired;
- переход участника в режим первичного догоняния с ID 21359 и затем два события выхода из него с ID 21363 в пределах одного перехода;
- фатальный сигнал либо трассировка вызовов, связанная с CatchupState::abort_inlock(), после этих выходов.
Обычные выборы лидера или однократный выход из режима догоняния сами по себе не являются индикаторами CVE-2026-118383. Запросы могут поступить до failover, поэтому стоит просматривать и более ранние записи журнала того же участника.
Наличие параметров запроса в журнале зависит от конфигурации логирования. Кроме того, поле attr[.]remote может содержать loopback-адрес вместо фактического IP-адреса клиента.
Практический вывод: владельцам MongoDB replica set следует установить исправленный выпуск на все узлы, отдельно проверить отключённые и контейнерные экземпляры, а до обновления ограничить доступ к серверу БД. При расследовании уже произошедших отказов нужно сопоставлять журналы ping с readConcern[.]afterOpTime, события catchup и аварийное завершение процесса. Одного факта выборов primary для вывода об эксплуатации недостаточно.