Критична вразливість MongoDB до автентифікації (CVE-2026-118383) може спричинити збій відставлих серверів під час перемикання

MongoDB випустила виправлення для CVE-2026-118383, критичної вразливості MongoDB Server до автентифікації: вона може спричинити збій члена набору реплік, якщо він виграє вибори, перебуваючи позаду за реплікацією, після двох неавтентифікованих запитів. Вразливість є use-after-free, 9,5/10 за CVSS 4.0. Зачеплені члени включають членів набору реплік, а також членів серверів шардів і конфігурації у шардованих кластерах; окремий mongod не зачеплений.

Як працює вразливість

У вразливих версіях увімкнення автентифікації не зупиняє ці два запити. Це команди ping із readConcern.afterOpTime; кожна просить сервер чекати досягнення реплікацією певної точки, створюючи очікуване сповіщення waiter. Waiter-и не спливають і лишаються до перезапуску, відкату або виходу з ролі primary. Збій стається, якщо член, що отримав їх, виграє пізніші вибори, відставши від іншого члена: після завершення наздоганяння очищення виконується двічі, повторно використовує звільнену пам'ять і спричиняє збій нового primary до приймання записів. Дослідники кажуть: після виконання умов збій не залежить від часової гонки, а зловмисник не може змусити цільовий член відстати чи виграти вибори або побачити будь-яку з цих подій.

Зачеплені версії та виправлення

MongoDB випустила виправлення для кожної зачепленої гілки; усі попередні версії гілки зачеплені аж до першого випуску. Самокеровані розгортання потребують виправленого випуску на кожному члені набору реплік; після оновлення адміністратори мають перевірити версію кожного члена, включно з контейнерними й офлайн-членами. Кластери MongoDB Atlas отримують виправлення під час обслуговування; клієнти, що відкладають обслуговування, мають оновитися якнайшвидше. Гілка 8.2 не входить до переліку зачеплених версій; її найновіший випуск 8.2.12, але proof of concept на GitHub повідомляє, що 8.2.12 все ще відтворював помилку в лабораторному тесті з налаштуванням лише для тестування. Гілка 8.2 досягла кінця життєвого циклу 31 липня за графіком компанії.

Виявлення та пом'якшення

Доки член не оновлено, дослідники радять обмежити мережевий доступ до бази даних лише потрібним системам; це обмежує відправників двох запитів, але не виправляє вразливість. Для пошуку підсадки або збію перевірте структуровані журнали: запис COMMAND Slow query з ID 51803 для неавтентифікованого ping із readConcern.afterOpTime, що завершився MaxTimeMSExpired; член, який входить у primary catch-up з ID 21359 і двічі виходить із нього з ID 21363 в одному переході; фатальний сигнал або зворотне трасування з CatchupState::abort_inlock() після цих виходів. Запити можуть надійти до перемикання, тому перевірте також раніші журнали того самого члена.

Твердження про виконання коду

MongoDB каже, що за певних умов вразливість може спричинити довільне виконання коду в процесі сервера. У лабораторії дослідники не досягли виконання коду; їхні результати не показують частоту успіху атаки в інших конфігураціях. Код proof of concept відтворює помилку в лабораторному наборі реплік; його надійний режим потребує налаштування лише для тестування, яке віддалений зловмисник не може увімкнути; заявлені наслідки: збій або пошкодження пам'яті. У лабораторному тесті proof of concept з вимкненою автентифікацією виправлена 8.0.37 прийняла підсаджені waiter-и, але виконала очищення лише один раз.

Джерела: The Hacker News