Přeskočit na obsah
Centoculus
cs

Bezpečnostní upozornění · Kritická

Repliky MongoDB: použití po uvolnění před ověřením může shodit servery (CVE-2026-118383)

· 3 minuty čtení · Centoculus Security Team

Známo od

Dotčené: Členové replikačních sad MongoDB Serveru, včetně členů shardových a konfiguračních replikačních sad shardovaných clusterů. Samostatná instance mongod ohrožena není.

Co se stalo

Dne 10. listopadu 2026 MongoDB zveřejnila CVE-2026-118383, použití po uvolnění (use-after-free) v replikační komponentě MongoDB Serveru. Má hodnocení 9.0 podle CVSS. Chyba může nastat, když nově zvolený primární uzel replikační sady dokončí doplnění zpoždění. K jejímu vyvolání stačí požadavky, které nevyžadují ověření. Výsledkem může být neočekávané zastavení procesu serveru. Za určitých podmínek může také vést ke spuštění libovolného kódu v kontextu procesu serveru.

Podle serveru The Hacker News je riziko pro člen replikační sady, který zaostal a poté se stal primárním uzlem, například při přepnutí role (failover). MongoDB vydala opravy. Zranitelnost není uvedena v katalogu známých zneužívaných zranitelností agentury CISA a žádný ze zdrojů neuvádí útoky.

Kdo je ohrožen

  • Ohroženo: procesy mongod běžící jako členové replikační sady. Patří sem replikační sady shardů a konfigurační replikační sady shardovaných clusterů.
  • Neohroženo: samostatné instance mongod, které nejsou součástí replikační sady.

Chybu lze vyvolat před ověřením, takže zapnutí ověřování vás neochrání. Nejvyššímu riziku jsou vystaveny členové replikačních sad, které mohou dosáhnout nedůvěryhodné sítě nebo mnoho aplikačních serverů.

Co udělat hned

  1. Sestavte seznam členů replikačních sad. Na každém serveru MongoDB zjistěte, zda mongod běží jako součást replikační sady (viz následující sekce). Samostatné instance pro tuto CVE nevyžadují naléhavý zásah.
  2. Najděte opravenou verzi pro vaši řadu vydání. Úkol MongoDB SERVER-138119 (odkaz níže) je součástí opravy. Uvádí opravené verze 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 a 4.4.32. Porovnejte to s SERVER-138175 a potvrďte verzi pro svou řadu.
  3. Zálohujte konfiguraci. Uložte /etc/mongod.conf (nebo váš ekvivalent) a ověřte, že existuje aktuální záloha dat.
  4. Aktualizujte po jednom členu. Začněte sekundárními uzly. Aktualizujte balíček (například apt install mongodb-org nebo dnf update mongodb-org), restartujte mongod a počkejte, dokud člen v rs.status() znovu nezobrazí stav SECONDARY. Poté spusťte rs.stepDown() na primárním uzlu a aktualizujte jej jako poslední. U shardovaných clusterů aktualizujte konfigurační replikační sadu a každou replikační sadu shardu.
  5. Omezte síťový přístup. Port 27017 (nebo váš vlastní port) by měl být dostupný pouze z aplikačních serverů a ostatních členů clusteru. Vynucujte to pomocí firewallu nebo nastavení bindIp, a to jak nyní, tak po aktualizaci.
  6. Sledujte pády. Kontrolujte logy mongod a monitorování služeb a hledejte neočekávané restarty, zejména kolem voleb a přepnutí rolí.

Jak ověřit, zda jste ohrozeni

  • Verzi zjistíte příkazem mongod --version, nebo v mongosh příkazem db.version().
  • Členství v replikační sadě ověřte v mongosh příkazem db.hello().setName. Pokud je vrácen název, instance je členem replikační sady a je ohrožena, dokud nebude aktualizována. Pokud nic nevrátí a rs.status() oznámí, že instance neběží s replikací, jde o samostatnou instanci, která ohrožena není.
  • U shardovaných clusterů proveďte kontrolu na každém členu shardu i každém konfiguračním členu.
  • Pokud je člen na starší verzi, než je opravená verze pro jeho řadu vydání, aktualizujte jej.

Zdroje

Další zdroje (2)

Pokud provozujete databáze, zkontrolujte také

Související příspěvky