MongoDB повідомила про критичну уразливість CVE-2025-14847 у MongoDB Server, яка відкриває можливість remote code execution (RCE) на стороні сервера бази даних. Особливу небезпеку становить те, що експлуатація не потребує автентифікації та взаємодії з користувачем, що робить уразливі екземпляри MongoDB привабливою ціллю для масових автоматизованих атак.
Суть уразливості CVE-2025-14847 у MongoDB Server
За інформацією команди безпеки MongoDB, проблема класифікується як Improper Handling of Length Parameter Inconsistency — некоректна обробка розбіжностей у параметрі довжини під час обробки даних на сервері. Помилка в логіці роботи з мережевими повідомленнями дозволяє зловмиснику сформувати спеціально підготовлений трафік і домогтися виконання довільного коду на сервері.
Ключовим технічним фактором є некоректна реалізація стиснення з використанням бібліотеки zlib. У певних сценаріях це призводить до доступу до неініціалізованої пам’яті в heap, що у свою чергу може викликати витік внутрішніх даних процесу MongoDB і спростити побудову надійного ланцюжка експлуатації для RCE. Оскільки уразливість експлуатується до етапу автентифікації, достатньо лише мережевого доступу до порту MongoDB.
Роль zlib, витік пам’яті та обхід захистів
Бібліотека zlib широко застосовується для стиснення даних у мережевих протоколах і застосунках. У MongoDB вона використовується для стиснення мережевих повідомлень між клієнтом та сервером, що зменшує обсяг трафіку і затримки. Проте помилки в цій частині коду мають особливо критичні наслідки, оскільки опрацьовують дані безпосередньо з мережі.
У випадку CVE-2025-14847 сервер у відповідь на зловмисно сформований запит може повернути фрагменти неініціалізованої heap-пам’яті. Подібні витоки використовуються для отримання інформації про внутрішню структуру процесу (адреси в пам’яті, об’єкти, маркери), що значно полегшує обхід механізмів на кшталт ASLR та інших засобів захисту пам’яті. Для атакуючого це часто перший крок до перетворення витоку інформації на повноцінний remote code execution.
Уражені та виправлені версії MongoDB Server
Уразливість зачіпає широкий спектр гілок MongoDB Server. Розробники випустили оновлення безпеки і рекомендують якнайшвидше перейти на такі версії:
- MongoDB 8.2.3
- MongoDB 8.0.17
- MongoDB 7.0.28
- MongoDB 6.0.27
- MongoDB 5.0.32
- MongoDB 4.4.30
Якщо інфраструктура працює на попередніх мінорних релізах цих гілок, сервер із високою ймовірністю залишається вразливим до CVE-2025-14847. Враховуючи потенціал RCE у критичній СУБД, оновлення слід розглядати як пріоритетну задачу у плануванні робіт з інформаційної безпеки.
Рекомендовані кроки: оновлення MongoDB та тимчасові заходи
Негайне встановлення виправлених версій MongoDB Server
Найнадійніший спосіб захисту від експлуатації CVE-2025-14847 — оновити MongoDB Server до однієї з виправлених версій (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 або 4.4.30). Перед оновленням доцільно:
- створити актуальні резервні копії даних і конфігурацій;
- перевірити сумісність нової версії з драйверами та застосунками;
- відпрацювати процедуру оновлення на тестовому стенді.
У середовищах із жорсткими SLA рекомендується поетапний підхід: спочатку оновити dev/test/staging, відстежити стабільність та продуктивність, і лише потім переходити до продуктивних кластерів.
Тимчасове пом’якшення ризику: відключення zlib-стиснення
Якщо негайне оновлення MongoDB неможливе, розробники пропонують тимчасове обхідне рішення — відмовитися від використання zlib для стиснення мережевих повідомлень. Для цього при запуску mongod або mongos слід виключити zlib зі списку компресорів:
Через командний рядок:
--networkMessageCompressors snappy,zstdЧерез конфігураційний файл:
net:
compression:
compressors: snappy,zstd
У цьому випадку сервер перестане використовувати zlib-стиснення для мережевих повідомлень, що значно знижує ризик експлуатації CVE-2025-14847 до моменту встановлення офіційних патчів.
Посилення безпеки MongoDB: додаткові рекомендації
Ситуація з MongoDB CVE-2025-14847 підкреслює важливість системного підходу до захисту баз даних, а не лише реагування на окремі уразливості. Рекомендовано:
- максимально обмежити мережевий доступ до MongoDB (firewall, VPN, сегментація за принципом Zero Trust);
- обов’язково вмикати автентифікацію та шифрування трафіку (TLS) навіть для внутрішніх кластерів;
- використовувати централізований vulnerability management для відстеження нових CVE в усіх критичних компонентах;
- регулярно проводити аудит конфігурацій, прав доступу та журналів подій MongoDB;
- реалізувати принцип найменших привілеїв для сервісних облікових записів та застосунків.
Згідно з дослідженням IBM Cost of a Data Breach 2023, середня вартість витоку даних перевищила 4,45 млн доларів США, а уразливості в програмному забезпеченні залишаються однією з ключових причин інцидентів. У контексті MongoDB це означає, що кожен невиправлений сервер може стати точкою входу для компрометації всієї бізнес-критичної інфраструктури.
Наявність критичної уразливості CVE-2025-14847 у широко розповсюдженій СУБД робить швидке оновлення MongoDB Server практично обов’язковою вимогою до безпечної експлуатації. Адміністраторам варто вже зараз перевірити версії всіх екземплярів MongoDB, спланувати оновлення до виправлених релізів, тимчасово відключити zlib-стиснення там, де патчинг відкладається, а також переглянути стратегію захисту баз даних і процеси управління уразливостями, щоб зменшити ризик майбутніх інцидентів.
