Seturi de replicare MongoDB: use-after-free înainte de autentificare poate bloca serverele (CVE-2026-118383)

Ce s-a întâmplat

Pe 10 noiembrie 2026, MongoDB a făcut public CVE-2026-118383, un use-after-free în componenta de replicare a MongoDB Server. Are scorul 9.0 în CVSS. Defecțiunea poate apărea când un primar nou ales al setului de replicare termină sincronizarea. Cererile care nu necesită autentificare pot să o declanșeze. Rezultatul poate fi oprirea neașteptată a procesului serverului. În anumite condiții, poate duce și la executarea arbitrară de cod în contextul procesului serverului.

Potrivit The Hacker News, riscul vizează un membru al setului de replicare care a rămas în urmă și apoi devine primar, de exemplu în timpul unui failover. MongoDB a lansat remedieri. Vulnerabilitatea nu figurează în catalogul CISA al vulnerabilităților exploatate cunoscute, iar niciuna dintre sursele citate nu raportează atacuri.

Cine este afectat

• Afectat: procesele mongod care rulează ca membri ai unui set de replicare. Aici intră seturile de replicare shard și seturile de replicare config server din clusterele shardate.
• Neafectat: instanțele mongod independente care nu fac parte dintr-un set de replicare.

Defecțiunea poate fi declanșată înainte de autentificare, deci activarea autentificării nu te protejează. Riscul cel mai mare vizează membrii seturilor de replicare accesibili din rețele neandemnate sau de la multe gazde de aplicații.

Ce să faci acum

1. Fă lista membrilor seturilor de replicare. Pe fiecare server MongoDB, verifică dacă mongod rulează ca parte a unui set de replicare (vezi secțiunea următoare). Instanțele independente nu necesită acțiune urgentă pentru acest CVE.
2. Găsește versiunea remediată pentru seria ta. Tichetul MongoDB SERVER-138119 (linkat mai jos) face parte din remediere. Enumeră versiunile remediate 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 și 4.4.32. Compară cu SERVER-138175 pentru a confirma versiunea pentru seria ta.
3. Fă o copie de rezervă a configurației. Salvează /etc/mongod.conf (sau echivalentul tău) și confirmă că există o copie de rezervă recentă a datelor.
4. Actualizează câte un membru pe rând. Începe cu secundarii. Actualizează pachetul (de exemplu apt install mongodb-org sau dnf update mongodb-org), repornește mongod și așteaptă până când membrul apare din nou ca SECONDARY în rs.status(). Apoi rulează rs.stepDown() pe primar și actualizează-l ultimul. În clusterele shardate, actualizează setul de replicare config server și fiecare set de replicare shard.
5. Limitează accesul la rețea. Portul 27017 (sau portul tău personalizat) ar trebui să fie accesibil doar de la serverele de aplicații și de la ceilalți membri ai clusterului. Folosește firewall-ul sau bindIp pentru a impune acest lucru, acum și după actualizare.
6. Urmărește posibilele blocări. Verifică jurnalele mongod și monitorizarea serviciului pentru reporniri neașteptate, mai ales în jurul alegerilor și failover-urilor.

Cum verifici dacă ești afectat

• Verifică versiunea cu mongod --version sau, în mongosh, cu db.version().
• Verifică apartenența la setul de replicare în mongosh cu db.hello().setName. Dacă se returnează un nume, instanța este membru al unui set de replicare și este afectată până la actualizare. Dacă nu se returnează nimic și rs.status() indică faptul că instanța nu rulează cu replicare, este o instanță independentă și nu este afectată.
• Pentru clusterele shardate, rulează verificarea pe fiecare membru shard și pe fiecare membru config server.
• Dacă un membru rulează o versiune mai veche decât versiunea remediată pentru seria lui, actualizează-l.

Surse

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