Почему уязвимость MongoBleed в MongoDB опаснее, чем кажется

MongoBleed — это критическая уязвимость в MongoDB, официально зарегистрированная как CVE-2025-14847.

Она затрагивает практически все версии MongoDB, выпущенные с 2017 года. С ее помощью удаленный атакующий может читать произвольные участки памяти сервера.

Проблема скрывалась в обработке сжатых сообщений zlib на сетевом уровне. Уязвимость уже исправлена в актуальных версиях, но старые релизы — 3.6, 4.0 и 4.2 — патчей не получат. Все потому что они находятся в статусе EOL.

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

В чем суть бага

MongoDB использует собственный бинарный протокол и формат BSON. Сообщения могут передаваться в сжатом виде — в таком случае клиент сам указывает размер данных после распаковки.

Ошибка заключалась в том, что сервер без проверки доверял этому значению. Атакующий мог указать, что сообщение после распаковки весит, например, 1 МБ, хотя реально там был 1 КБ.

MongoDB выделяла в памяти большой буфер, распаковывала туда данные и оставляла остальное пространство заполненным «мусором» из неинициализированной памяти.

Почему это приводит к утечке данных

MongoDB написана на C++, а значит память после malloc не очищается автоматически.

И в том «мусоре», который заполнил излишек памяти, могут оказаться фрагменты предыдущих операций: пароли, токены, ключи API, пользовательские данные, IP-адреса и конфигурация системы.

Дальше вступает в игру BSON. Поля в нем хранятся как C-строки с \0 в конце. Если отправить специально сформированное сообщение без нулевого байта, сервер будет читать память дальше — пока не наткнется на первый \0. А затем вернет эту строку в сообщении об ошибке клиенту.

В итоге сервер сам отдает атакующему куски своей памяти.

Эксплуатация без логина и пароля

Самое неприятное — уязвимость срабатывает до аутентификации. Разбор входящего сообщения происходит раньше, чем проверка прав доступа. Это значит, что для атаки достаточно сетевого доступа к MongoDB. Логин, пароль и любые учетные данные не нужны.

С учетом того, что поисковики вроде Shodan находят более 200 000 MongoDB-инстансов, доступных из интернета, масштаб проблемы становится очевиден.

Почему 8 лет — это катастрофа

По данным исследователей, баг появился еще в 2017 году, начиная с MongoDB 3.6. Он существовал почти 8 лет. Насколько активно его использовали — неизвестно, но с учетом простоты эксплуатации трудно поверить, что им никто не воспользовался.

Исправление оказалось размером буквально в одну строку. Тем не менее, публичная коммуникация со стороны MongoDB выглядела сдержанной.

Сначала вышел CVE, затем — патч, а полноценное объяснение появилось позже. В компании заявили, что не нашли признаков эксплуатации, но подтвердить это задним числом практически невозможно.

Почему MongoBleed — тревожный сигнал

MongoBleed не то чтобы опасна утечкой данных. Она скорее показывает, насколько уязвимыми могут быть низкоуровневые оптимизации, сделанные ради производительности. Один неверный допуск и база данных превращается в источник утечек на уровне памяти.