MongoDB реплика сетове: използване след освобождаване преди удостоверяване може да срине сървърите (CVE-2026-118383)

Какво се случи

На 10 ноември 2026 г. MongoDB оповести CVE-2026-118383, използване след освобождаване в компонента за репликация на MongoDB Server. Уязвимостта е оценена с 9.0 по CVSS. Пропускът може да възникне, когато новоизбран първичен член на реплика сет завърши синхронизацията си. Заявки, които не изискват удостоверяване, могат да го задействат. Резултатът може да бъде неочаквано спиране на процеса на сървъра. При определени условия той може също да доведе до изпълнение на произволен код в контекста на процеса на сървъра.

Според The Hacker News рискът засяга член на реплика сет, който е изостанал и след това става първичен, например при превключване при авария. MongoDB е публикувал корекции. Уязвимостта не е включена в каталога на CISA за известни експлоатирани уязвимости, а нито един от източниците не съобщава за атаки.

Кои са засегнати

• Засегнати: процесите mongod, които работят като членове на реплика сет. Това включва реплика сетовете на шардовете и реплика сетовете на конфигурационните сървъри в шардирани клъстери.
• Не са засегнати: самостоятелните инстанции mongod, които не са част от реплика сет.

Пропускът може да бъде задействан преди удостоверяване, затова включването на удостоверяване не Ви защитава. Най-голям е рискът за членовете на реплика сет, достъпни от непроверени мрежи или от много сървъри за приложения.

Какво да направите сега

1. Изброете членовете на реплика сета. На всеки сървър на MongoDB проверете дали mongod работи като част от реплика сет (вижте следващия раздел). Самостоятелните инстанции не изискват спешно действие по този CVE.
2. Намерете коригираната версия за Вашата серия. Задачата MongoDB SERVER-138119 (свързана по-долу) е част от корекцията. Тя изброява коригираните версии 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 и 4.4.32. Сравнете с SERVER-138175, за да потвърдите версията за Вашата серия.
3. Създайте резервно копие на конфигурацията. Запазете /etc/mongod.conf (или еквивалентния файл) и се уверете, че съществува скорошно резервно копие на данните.
4. Актуализирайте по един член наведнъж. Започнете със вторичните сървъри. Актуализирайте пакета (например apt install mongodb-org или dnf update mongodb-org), рестартирайте mongod и изчакайте членът да покаже SECONDARY отново в rs.status(). След това изпълнете rs.stepDown() на първичния сървър и го актуализирайте последен. В шардираните клъстери актуализирайте реплика сета на конфигурационните сървъри и всеки реплика сет на шард.
5. Ограничете мрежовия достъп. Порт 27017 (или Вашият персонализиран порт) трябва да бъде достъпен само от сървърите за приложения и другите членове на клъстера. Използвайте защитната стена или bindIp, за да наложите това, както сега, така и след актуализацията.
6. Наблюдавайте за срив. Проверете логовете на mongod и мониторинга на услугите за неочаквани рестартирания, особено около избори и превключвания.

Как да проверите дали сте засегнати

• Проверете версията с mongod --version или в mongosh с db.version().
• Проверете членството в реплика сета в mongosh с db.hello().setName. Ако се върне име, инстанцията е член на реплика сет и е засегната, докато не бъде актуализирана. Ако не се върне нищо и rs.status() съобщава, че инстанцията не работи с репликация, тя е самостоятелна и не е засегната.
• За шардирани клъстери извършете проверката на всеки член на шард и на всеки конфигурационен сървър.
• Ако даден член е на по-стара версия от коригираната за неговата серия, актуализирайте го.

Източници

• https://nvd.nist.gov/vuln/detail/CVE-2026-118383
• https://jira.mongodb.org/browse/SERVER-138119