Критическая уязвимость в MongoDB Server позволяет неаутентифицированному злоумышленнику отправить два запроса, которые вызывают сбой на сервере базы данных. Сбой происходит только в том случае, если этот сервер впоследствии выбран для перехода на роль основного, при этом он еще не получил некоторые последние изменения. MongoDB, компания-разработчик базы данных, выпустила исправленные версии на этой неделе. Затронутые серверы являются членами репликационного набора — группы серверов MongoDB, которые хранят копии одних и тех же данных. Один член, первичный, выступает в роли основного сервера и обрабатывает все новые записи, в то время как остальные их реплицируют. Если первичный сервер становится недоступным, другие члены проводят выборы для выбора нового первичного. Исследователи из Datadog Security Labs воспроизвели сбой в лаборатории и опубликовали свои выводы вчера. В уязвимых версиях включение аутентификации не останавливает два запроса. Злоумышленник не может заставить целевого члена отстать или выиграть выборы, а также не может видеть, когда это происходит, заявили исследователи. Уязвимость, отслеживаемая как CVE-2026-118383, является использованием после освобождения памяти (use-after-free): сервер в конечном итоге использует память, которую он уже освободил. MongoDB оценила ее в 9,5 из 10 по шкале серьезности CVSS 4.0. Компания заявила, что сама обнаружила уязвимость и “не осведомлена о каких-либо попытках использовать эту уязвимость”. Затронутые члены включают члены шардов и конфигурационных серверов кластеров с шардированием. Автономный mongod, одиночный сервер вне какого-либо репликационного набора, не затронут. Каждая затронутая ветка имеет исправленный выпуск, перечисленный ниже и в записи CVE. Затронуты все предыдущие версии в ветке, начиная с первого выпуска ветки. Кластеры MongoDB Atlas автоматически получают исправленные версии во время обслуживания, заявила компания в своем объявлении о безопасности. Клиенты, которые откладывают обслуживание, должны применить обновление как можно скорее. Развертывания, управляемые самостоятельно, требуют исправленного выпуска на каждом члене репликационного набора. После обновления проверьте версию, которую использует каждый член, включая членов в контейнерах и тех, которые были отключены во время обслуживания. Ветка 8.2 не входит в число перечисленных затронутых версий, а ее последний выпуск — 8.2.12. Однако в коде proof-of-concept, опубликованном на GitHub, сообщается, что версия 8.2.12 все еще демонстрировала ошибку в лабораторном тесте с использованием тестовой настройки. Ветка 8.2 достигла конца жизненного цикла 31 июля, согласно графику жизненного цикла компании. После этой даты версия больше не получает исправлений, включая исправления безопасности. Пока член не может быть обновлен, исследователи советуют ограничить сетевой доступ к базе данных только теми системами, которым он необходим. Это ограничивает круг лиц, которые могут отправлять два запроса, но не устраняет уязвимость. Член, выигравший выборы, сначала догоняет, применяя записи, которые он пропустил, прежде чем принимать новые. Уязвимость находится в процессе очистки, который выполняется по завершении этого этапа догоняния, согласно техническому анализу исследователей Datadog. Два запроса — это команды ping, которые содержат значение readConcern.afterOpTime. Каждый из них просит сервер подождать, пока репликация не достигнет определенной точки, и сервер записывает для него ожидающее уведомление, называемое waiter. Размещение waiters не вызывает сбой сервера. Они не истекают и остаются на месте до перезапуска, отката или ухода члена с роли первичного. Сбой требует, чтобы член, получивший запросы, выиграл последующие выборы, даже если он отстает от другого члена. Когда догоняние завершается, очистка выполняется дважды, повторно используя память, которая уже была освобождена, и новый первичный сервер сбоит до того, как примет какие-либо записи. Как только эти условия выполнены, сбой не зависит от выигрыша гонки по времени, заявили исследователи. В лаборатории исследователи заставили члена отстать и сами инициировали отказ, используя административный доступ для приостановки и остановки процессов mongod. Два запроса поступили только от клиента без учетных данных, и этот клиент не мог записывать в базу данных. В версии 8.0.34 член сбоил с ошибкой сегментации, оставляя лабораторный кластер без первичного сервера. Другое развертывание может выбрать новый первичный сервер и продолжить работу. В исправленной версии 8.0.37 сервер отклонил оба запроса как неавторизованные одновременно, и член продолжал работать. Одна часть исправления позволяет использовать readConcern.afterOpTime только системным пользователям. MongoDB утверждает, что уязвимость также может привести к выполнению произвольного кода в процессе сервера при определенных условиях. Однако в лаборатории “мы не добились выполнения кода”, заявили исследователи. Их результаты также не показывают, как часто атака будет работать в других конфигурациях. Код proof-of-concept воспроизводит ошибку в лабораторном репликационном наборе, по словам его автора. Его надежный режим требует тестовой настройки, которую удаленный злоумышленник не может включить. Заявленное воздействие — сбой или повреждение памяти, без претензий на выполнение кода. Вторая часть исправления предотвращает двойное выполнение очистки, даже когда waiters уже на месте, заявили исследователи. Они сами не тестировали эту часть. В лабораторном тесте proof-of-concept, который проводился с отключенной аутентификацией, исправленная версия 8.0.37 приняла размещенные waiters, но выполнила очистку только один раз. Чтобы обнаружить размещение waiters или сбой, проверьте структурированные журналы сервера на наличие следующих признаков из уязвимого запуска, выполненного исследователями: Обычные выборы или выход из одного этапа догоняния не указывают на эту уязвимость. Запросы также могут поступать до отказа, поэтому проверьте более ранние журналы того же члена. Зависят ли поля запроса от настроек журналирования, а поле attr.remote может показывать адрес обратной петли вместо реального IP-адреса клиента.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Swati Khandelwal
