Een nieuw MongoDB pre-auth lek kan database-servers laten crashen wanneer een replica-setlid later wordt gekozen als nieuwe primaire. Het gaat om CVE-2026-118383, een kwetsbaarheid die ervoor zorgt dat MongoDB geheugen opnieuw gebruikt dat al vrijgegeven is. Dat kan leiden tot een fatale crash, waardoor uw omgeving mogelijk tijdelijk zonder primaire komt te zitten.
MongoDB heeft eerder deze week een fix uitgebracht. Dat is belangrijk, want onderzoekers van Datadog Security Labs hebben de issue in een lab gereproduceerd en laten zien dat het probleem ook optreedt wanneer authenticatie is ingeschakeld—mits u nog niet op de gepatchte versie zit.
Wat doet het MongoDB pre-auth lek precies?
De kern van het probleem is een use-after-free in de server. Bij een specifieke volgorde van gebeurtenissen gebruikt MongoDB intern geheugen dat al niet meer geldig is. In de praktijk betekent dit: een aanvaller kan zonder geldige inloggegevens twee verzoeken sturen die de crash triggeren, maar de daadwerkelijke gevolgen vallen pas later wanneer de betreffende server overgenomen wordt.
Belangrijk detail uit de analyse: het gaat om leden die onderdeel zijn van een replica set. Binnen zo’n groep is er één primary die nieuwe writes verwerkt en andere leden die data repliceren. Als de primary uitvalt, volgt een verkiezing om een nieuwe primary aan te wijzen. Juist op dat moment kan het kwetsbare lid problemen krijgen.
Wanneer gebeurt de crash en wie loopt risico?
Volgens de onderzoekers crasht het getroffen lid alleen in scenario’s waarin het later de rol van primary krijgt terwijl het nog niet alle recente updates heeft verwerkt. Dat maakt de impact indirect: de aanvaller kan niet afdwingen dat een bepaald lid achterblijft of een verkiezing wint, en ook niet exact zien wanneer de relevante failover plaatsvindt.
De kwetsbaarheid raakt:
- Replica set leden in getroffen versies
- Sharded clusters: zowel shard– als config server-leden
Niet getroffen is een standalone mongod (een losse server buiten een replica set). Met andere woorden: uw exacte risicoprofiel hangt sterk af van uw MongoDB-topologie.
Waarom werkt “authenticatie aan” niet als volledige bescherming?
Een opvallende conclusie uit de reproductie: het MongoDB pre-auth lek wordt niet gestopt door het inschakelen van authenticatie. Dat betekent niet dat authenticatie nutteloos is, maar wel dat je niet kunt rekenen op “auth aan = veilig”.
Wat wél helpt als tijdelijke maatregel is netwerkbeperking (daarover straks meer). Voor echte bescherming is de upgrade naar de gepatchte releases nodig.
Hoe ziet een poging tot misbruik eruit?
Datadog Security Labs beschrijft twee specifieke verzoeken (“ping”-commando’s) die een veld meenemen: readConcern.afterOpTime. Met die waarde vraagt de client de server om te wachten tot replicatie een bepaald punt heeft bereikt. De server legt vervolgens een interne wachtrij-achtige structuur vast, een waiter, als pending notificatie.
Op zichzelf zorgt het plaatsen van die waiters niet direct voor een crash. Ze vervallen ook niet; ze blijven aanwezig tot het kwetsbare lid herstart, terugrolt, of afziet van de primary-rol. De crash treedt op wanneer de server later een catch-up uitvoert en de cleanup-logica twee keer wordt geraakt in een situatie waar geheugen opnieuw wordt hergebruikt.
Effect op productie: mogelijk crash of zelfs code-executie
MongoDB beoordeelde de ernst met 9,5/10 volgens CVSS 4.0. Dat is geen vrijblijvende score: de server kan in bepaalde omstandigheden tot een fatal crash leiden. In het lab leidde dat tot een segmentation fault waardoor er tijdelijk geen primary beschikbaar was.
Daarnaast geeft MongoDB aan dat het lek in bepaalde voorwaarden mogelijk kan resulteren in arbitrary code execution. In de labresultaten van de onderzoekers werd echter geen code execution bereikt. Ook is niet bekend hoe vaak het in andere setups praktisch succesvol zou zijn.
Wat zegt MongoDB over fixes en getroffen versies?
MongoDB publiceerde aangepaste versies eerder deze week. Per release-branch geldt dat elke eerdere versie binnen dezelfde branch kwetsbaar kan zijn, terug tot de eerste release van die branch. De broninformatie noemt dat de fix ook geldt voor leden in replica sets en relevante componenten van ge-sharde clusters.
Een extra aandachtspunt: de 8.2-branch wordt niet genoemd als getroffen. De nieuwste 8.2-release is 8.2.12. Toch meldt de proof-of-concept dat 8.2.12 in een labtest nog steeds het buggedrag vertoonde met een test-only instelling. Omdat de exacte omstandigheden van de test-only modus niet zomaar te repliceren zijn in echte aanvalsscenario’s, is het raadzaam om de officiële MongoDB advisering en lifecycle-informatie te volgen bij uw upgradeplanning.
Atlas en self-managed: zo pak je het aan
Voor MongoDB Atlas-klanten geldt dat fixed versies doorgaans automatisch worden meegenomen tijdens onderhoud. Voor organisaties die hun omgeving self-managed draaien, ligt de verantwoordelijkheid bij het eigen upgradeproces: u moet de gepatchte release op alle replica set leden installeren.
Na de upgrade is het verstandig om per lid te controleren welke versie er draait. Dat geldt extra voor omgevingen met containers en voor leden die tijdens onderhoud offline waren.
Tijdelijke mitigatie: beperk netwerktoegang
Als u een upgrade (nog) niet direct kunt doorvoeren, adviseren de onderzoekers om het netwerkverkeer naar de database te beperken tot alleen systemen die het nodig hebben. Daarmee verkleint u de kans dat externe partijen de twee speciale verzoeken kunnen sturen. Dit lost de kwetsbaarheid niet structureel op, maar verlaagt wel het directe aanvalsoppervlak.
Het helpt dus als “tussenstap”, niet als definitieve oplossing.
Zo kun je in logs aanwijzingen vinden
Volgens de onderzoekers kun je mogelijke signalen achterhalen via structured logs. Ze noemen daarbij specifieke logevents uit hun kwetsbare runs. Let op: welke velden je ziet hangt af van je logginginstellingen, en een IP-adres kan in sommige gevallen als loopback verschijnen.
Check bijvoorbeeld op:
- Een COMMAND “Slow query”-entry (ID 51803) voor een unauthenticated ping met readConcern.afterOpTime, eindigend met MaxTimeMSExpired
- Logevents rond primary catch-up (ID 21359) en vervolgens het twee keer exit-gedrag in één overgang (ID 21363)
- Een fatal signal of backtrace met CatchupState::abort_inlock() na die exits
Een normale verkiezing of slechts één catch-up exit wijst niet per se op het lek. Bovendien kunnen de twee verzoeken ook binnenkomen voor het failovermoment, dus bekijk logcontext rond het betreffende lid over een bredere tijdspanne.
Praktische checklist voor security teams
Als je snel wilt handelen, kun je dit als volgorde gebruiken:
- Inventariseer welke MongoDB servers draaien in replica sets en welke deel uitmaken van sharded clusters.
- Bepaal de versies van elk replica set lid (incl. leden in containers en offline instances).
- Upgrade naar de gepatchte MongoDB releases zoals MongoDB in de security announcement vermeldt.
- Beperk netwerktoegang als er een korte overgangsperiode is tot de upgrade.
- Controleer logs op de beschreven signalen rond slow query entries, primary catch-up transitions en fatale backtraces.
Als je ook bezig bent met gerelateerde aanvalspaden rond database- en applicatielaag kwetsbaarheden, kan het helpen om breder te kijken naar recente exploitation van internet-facing diensten. Zo behandelen we op de site bijvoorbeeld Node.js HTTP/2 fixes met meerdere kwetsbaarheden en wat dat betekent voor patchprioriteit. Dat is een ander product, maar de aanpak (inventariseren, patchen, mitigeren, controleren) is vergelijkbaar.
Conclusie
De MongoDB pre-auth lek (CVE-2026-118383) is vooral gevaarlijk omdat de servercrash pas zichtbaar wordt bij failover naar een kwetsbaar replica-setlid. Authenticatie aan is geen garantie dat u beschermd bent. De juiste stap is daarom: upgrade naar de door MongoDB gepubliceerde fixed versies en controleer per lid dat de update echt is doorgevoerd.
Tot die tijd kunt u met netwerkbeperking de kans op misbruik verlagen, maar reken niet op tijdelijke mitigatie als eindoplossing.
Bron: https://thehackernews.com/2026/11/critical-pre-auth-mongodb-flaw-cve-2026.html
