Содержание
А переживать есть из-за чего
MongoBleed — это критическая уязвимость в MongoDB, официально зарегистрированная как CVE-2025-14847.
Она затрагивает практически все версии MongoDB, выпущенные с 2017 года. С ее помощью удаленный атакующий может читать произвольные участки памяти сервера.
Проблема скрывалась в обработке сжатых сообщений zlib на сетевом уровне. Уязвимость уже исправлена в актуальных версиях, но старые релизы — 3.6, 4.0 и 4.2 — патчей не получат. Все потому что они находятся в статусе EOL.
На первый взгляд это выглядит как очередной баг в низкоуровневом коде. На деле — одна из самых опасных уязвимостей для публично доступных баз данных.
В чем суть бага
MongoDB использует собственный бинарный протокол и формат BSON. Сообщения могут передаваться в сжатом виде — в таком случае клиент сам указывает размер данных после распаковки.
Руководство по промптам GPT-5: практики для агентов, кодирования и управляемостиtproger.ru
Ошибка заключалась в том, что сервер без проверки доверял этому значению. Атакующий мог указать, что сообщение после распаковки весит, например, 1 МБ, хотя реально там был 1 КБ.
MongoDB выделяла в памяти большой буфер, распаковывала туда данные и оставляла остальное пространство заполненным «мусором» из неинициализированной памяти.
Почему это приводит к утечке данных
MongoDB написана на C++, а значит память после malloc не очищается автоматически.
И в том «мусоре», который заполнил излишек памяти, могут оказаться фрагменты предыдущих операций: пароли, токены, ключи API, пользовательские данные, IP-адреса и конфигурация системы.
Дальше вступает в игру BSON. Поля в нем хранятся как C-строки с в конце. Если отправить специально сформированное сообщение без нулевого байта, сервер будет читать память дальше — пока не наткнется на первый . А затем вернет эту строку в сообщении об ошибке клиенту.
В итоге сервер сам отдает атакующему куски своей памяти.
Эксплуатация без логина и пароля
Самое неприятное — уязвимость срабатывает до аутентификации. Разбор входящего сообщения происходит раньше, чем проверка прав доступа. Это значит, что для атаки достаточно сетевого доступа к MongoDB. Логин, пароль и любые учетные данные не нужны.
С учетом того, что поисковики вроде Shodan находят более 200 000 MongoDB-инстансов, доступных из интернета, масштаб проблемы становится очевиден.
Почему 8 лет — это катастрофа
По данным исследователей, баг появился еще в 2017 году, начиная с MongoDB 3.6. Он существовал почти 8 лет. Насколько активно его использовали — неизвестно, но с учетом простоты эксплуатации трудно поверить, что им никто не воспользовался.
Что происходит с Huawei и HarmonyOS: сможет ли Китай подвинуть iOS, Android и Linuxtproger.ru
Исправление оказалось размером буквально в одну строку. Тем не менее, публичная коммуникация со стороны MongoDB выглядела сдержанной.
Сначала вышел CVE, затем — патч, а полноценное объяснение появилось позже. В компании заявили, что не нашли признаков эксплуатации, но подтвердить это задним числом практически невозможно.
Почему MongoBleed — тревожный сигнал
MongoBleed не то чтобы опасна утечкой данных. Она скорее показывает, насколько уязвимыми могут быть низкоуровневые оптимизации, сделанные ради производительности. Один неверный допуск и база данных превращается в источник утечек на уровне памяти.