Опасная уязвимость в MongoDB позволяет анонимным злоумышленникам мгновенно выводить из строя серверы

Исследователи кибербезопасности обнаружили критическую уязвимость типа «отказ в обслуживании» (Denial of Service, DoS) в популярной системе управления базами данных MongoDB. Проблема, получившая идентификатор CVE-2026-25611, позволяет неавторизованным злоумышленникам вызвать аварийное завершение работы практически любого сервера MongoDB, доступного из интернета. Эта находка затрагивает корпоративные развертывания и облачные сервисы, включая MongoDB Atlas, что делает её серьёзной угрозой для бизнес-непрерывности тысяч компаний по всему миру.

Детали уязвимости

Уязвимость была выявлена старшим исследователем безопасности компании Cato CTRL Виталием Симоновичем (Vitaly Simonovich). Её корень кроется в функции сжатия данных OP_COMPRESSED, которая является частью сетевого протокола MongoDB. Данная функция была добавлена в версии 3.4 и включена по умолчанию начиная с релиза 3.6, что означает широкий охват потенциально уязвимых систем. Эксперты классифицировали проблему как CWE-405, то есть асимметричное потребление ресурсов, и присвоили ей высокие баллы по шкале CVSS: 8.7 для CVSS 4.0 и 7.5 для CVSS 3.1.

Механизм атаки основан на фундаментальной ошибке в логике проверки данных. Когда сервер MongoDB получает сжатое сообщение, он сначала считывает из заголовка пакета поле "uncompressedSize", декларирующее размер данных после распаковки, и немедленно выделяет под них оперативную память указанного объёма. Только после этого происходит фактическая распаковка и проверка соответствия реального размера данных заявленному. Этим и пользуется злоумышленник: отправляя специально сформированный пакет размером около 47 килобайт, в заголовке которого указан нереалистично большой размер, например, 48 мегабайт, атакующий заставляет сервер резервировать огромный блок памяти под практически пустые данные.

Это создаёт колоссальный коэффициент усиления атаки, достигающий 1027 к 1. Простыми словами, отправив данные, сопоставимые по объёму с коротким электронным письмом, злоумышленник может вынудить сервер выделить память, достаточную для хранения целого аудиоподкаста. Уязвимая функция "SharedBuffer::allocate(uncompressedSize)" в файле "message_compressor_manager.cpp" выделяет память на строке 158, в то время как валидация происходит лишь на строке 175, когда ресурсы уже безвозвратно потреблены.

Самым опасным аспектом этой уязвимости является полное отсутствие необходимости в аутентификации. Эксплойт воздействует на этапе разбора сетевого протокола, который происходит до каких-либо проверок учетных данных. Следовательно, под угрозой оказывается каждая MongoDB-система, чей порт 27017 доступен из глобальной сети. Масштабируемость атаки напрямую зависит от объёма оперативной памяти целевого сервера и ограничивается лишь возможностью установить множество одновременных TCP-соединений. Например, для вывода из строя инстанса с 512 МБ ОЗУ достаточно примерно 10 соединений, передающих в сумме менее 500 КБ данных. Мощный корпоративный сервер с 64 ГБ памяти может быть обрушен примерно 1363 соединениями, передающими всего около 64 МБ трафика, что легко осуществимо даже с обычного домашнего интернет-канала.

По данным аналитиков, в настоящее время в открытом доступе в интернете находится более 207 000 экземпляров MongoDB. Для специалистов по информационной безопасности ключевыми индикаторами возможной атаки являются нехарактерно высокое количество TCP-подключений к порту 27017 с одного IP-адреса, появление в трафике пакетов OP_COMPRESSED с кодом операции 2012, в которых заявленный размер несжатых данных превышает 10 МБ при общем размере пакета менее 100 КБ, а также резкие скачки потребления памяти процессом "mongod". Косвенными признаками в системных журналах могут быть события, связанные с работой механизма Out-Of-Memory Killer в Linux, и аварийное завершение процесса MongoDB с кодом 137, что сигнализирует о принудительном завершении из-за нехватки памяти.

Компания MongoDB оперативно отреагировала на сообщение об уязвимости, переданное через программу Bug Bounty, и выпустила исправления в версиях 7.0.29, 8.0.18 и 8.2.4. Патч изменяет порядок операций, добавляя проверку соответствия размера данных до выделения памяти, что полностью устраняет проблему. Организациям настоятельно рекомендуется немедленно обновить все развернутые экземпляры СУБД до защищённых версий.

В качестве временных мер снижения риска до применения обновлений эксперты советуют категорически избегать открытия порта 27017 для доступа извне (правило "0.0.0.0/0"), использовать брандмауэры для строгого ограничения доступа по IP-адресам и, для пользователей MongoDB Atlas, активировать приватные конечные точки вместо публичного доступа. Дополнительной линией обороны может стать настройка ограничений на потребление памяти на уровне операционной системы, например, с помощью механизма контрольных групп (cgroups) в Linux, что позволит локализовать последствия атаки и предотвратить полный крах сервера.

Детали уязвимости

Ссылки