El 3 de novembre del 2026, MongoDB va publicar quatre avisos de seguretat de cop. Cap dels quatre no es pedaça a la teva base de dades. Els quatre s'arreglen actualitzant les Database Tools a la versió 100.20.1: aquell grapat de binaris de línia d'ordres —mongodump, mongorestore, mongofiles, mongoimport— que no viu al servidor, sinó al portàtil de qui restaura, a la imatge del contenidor que fa la còpia de nit i al jump host per on entra tothom. El teu clúster pot estar al dia i tenir-les totes quatre.
El que diu l'avís, sense adorns
El greu dels quatre és la CVE-2026-119675, i convé llegir-la tal qual perquè la frase curta no se sosté sola. Segons la descripció publicada, mongorestore «tracta de manera inconsistent el prefix system.buckets. en validar noms de col·lecció en un bolcat no fiable», i per això «un nom de col·lecció especialment construït pot saltar-se les proteccions de col·leccions especials i els filtres d'espai de noms de l'operador, fent que una restauració creï un compte de base de dades no autoritzat i triat per l'usuari, incloent-hi un compte amb el rol root».
El changelog del projecte és més explícit que l'avís sobre el mecanisme. El tiquet que el tanca es titula, literalment, «mongorestore should reject crafted collection names that resolve to $admin.system.auth collections». El nom no acabava en una col·lecció qualsevol: acabava resolent en la col·lecció on Mongo guarda els usuaris. No hi ha escalada de privilegis ni explotació de memòria: el fitxer porta documents, l'eina els escriu on li diuen, i on li diuen és el padró de comptes.
I la frase que s'emporta el premi, també de la descripció oficial: «Excluding the admin namespace alone does not prevent this behavior.» És a dir, la mitigació que a qualsevol se li acudiria primer —restaurar amb --nsExclude 'admin.*'— no serveix. Està escrit pel fabricant, no és la nostra lectura.
Hi ha dues condicions i totes dues importen. La primera, que el bolcat vingui de fora del teu control. La segona, que qui restaura ho faci «amb credencials amb privilegis suficients de gestió d'usuaris al desplegament de destinació». Cap de les dues és exòtica. La majoria de la gent restaura amb el compte que té a mà, i el que té a mà sol ser el que ho pot tot.
Les altres tres són la mateixa idea
Les quatre es van publicar el mateix dia, a la mateixa hora, i totes es tanquen a la 100.20.1. Les puntuacions són les que els va assignar MongoDB com a CNA, en les dues versions del barem:
| CVE | Eina | De què es refia | Afecta des de | CVSS 4.0 / 3.1 |
|---|---|---|---|---|
| 2026-119675 | mongorestore | el nom de col·lecció que porta el bolcat | 100.4.0 | 5,2 / 8,6 |
| 2026-119672 | mongofiles | el nom de fitxer guardat a la base de dades | 3.1.4 | 5,9 / 4,8 |
| 2026-119674 | mongorestore | el nom original codificat a les metadades | 100.0.2 | 2,1 / 3,7 |
| 2026-119673 | mongofiles | els symlinks del directori de baixada (get_regex) | 100.2.0 | 1,0 / 2,8 |
La columna de la dreta té una raresa: en aquest mateix lot, del mateix fabricant i del mateix dia, les dues versions del barem es contradiuen en sentits oposats. La de mongorestore és un 5,2 en CVSS 4.0 i un 8,6 en 3.1; la de mongofiles, un 5,9 en 4.0 i un 4,8 en 3.1. Qui filtri per «a partir de 7» veurà una, dues o cap segons d'on tregui el número.
De les tres menors, la que fa més vertigen operatiu és la CVE-2026-119674, un 2,1 raquític: mongorestore descodifica mal el nom original d'una col·lecció quan el nom del fitxer del bolcat s'ha truncat, i els documents acaben en una col·lecció diferent de la prevista. L'avís hi afegeix dues conseqüències que cap número de dues xifres no transmet: «quan els dos noms de col·lecció resolen al mateix destí, els documents de la còpia poden ometre's» i «l'ús de --drop també pot reemplaçar la col·lecció de destinació no prevista». Traduït: una restauració que acaba sense error, amb dades que falten, i un --drop que s'endú per davant una cosa que no havies de tocar.
La de mongofiles (CVE-2026-119672) és gairebé elegant pel que té de petita. En recuperar un fitxer pel seu identificador (get_id), l'eina usa com a destinació de sortida el nom de fitxer que està guardat a la base de dades, si no li passes --local. Qui pugui editar aquelles metadades hi posa com a nom un guió, i la següent baixada legítima ja no escriu un fitxer: escriu per sortida estàndard. Si aquella sortida s'està capturant en algun lloc on l'atacant arriba —el log d'un pipeline, per exemple—, s'emporta el contingut. Un guió. I arrossega des de la versió 3.1.4, d'una numeració anterior al fet que aquestes eines se separessin en la sèrie 100.x.
La confiança anava en el sentit contrari
Estem acostumats a pensar la seguretat d'una base de dades en una sola direcció: el servidor desconfia del client, li demana credencials, li limita els rols. Aquestes quatre van a l'inrevés. Aquí el client es creu el que li arriba de l'altra banda: un nom de col·lecció escrit dins d'un fitxer, un nom de fitxer retornat pel servidor, un guió que resulta que significa «escriu per pantalla». L'eina fa d'intèrpret entre dos mons i es refia de qui no hauria.
Aquella lectura no és la nostra deducció: és al changelog de la 100.20.1, publicat el 2 de novembre del 2026, un dia abans dels avisos. Entre les tasques tancades hi ha tres arranjaments de seguretat sense CVE assignada. El tercer explica per què mongoimport també entra al lot: es titula «Mongoimport allows query-operator injection into the selector». Els altres dos situen el patró. Un es titula «Mongodump: validate server-returned collection names to prevent path traversal»: és a dir, també en la direcció de bolcar, no només de restaurar, un servidor que no controles podia fer que el teu mongodump escrivís fora del directori de destinació. L'altre, «Redact secrets from connection strings in error messages»: la cadena de connexió, amb la seva contrasenya a dins, apareixia als missatges d'error. On van els missatges d'error d'una tasca automatitzada és al log, i el log el llegeix més gent que la base de dades.
Per què el teu escàner no trobarà res
Dos dels quatre vectors són AV:L, local. Els quatre necessiten interacció d'una persona: UI:P en 4.0, UI:R en 3.1. Això canvia l'aritmètica de l'exposició. Amb un servei exposat, el que es compta són els dies entre el pedaç i la seva aplicació; aquí no hi ha res a comptar, perquè no hi ha res escoltant en un port. La finestra no s'obre el dia de l'avís: s'obre la pròxima vegada que algú restauri. Pot ser aquesta tarda o pot ser al març.
I hi ha un detall que ho remata, i és el que converteix això en un problema d'inventari i no de pedaços. Al rastrejador de seguretat d'Ubuntu, la prioritat assignada a la CVE-2026-119675 és mitjana, i l'estat del paquet mongo-tools és «no és a la release» per a 22.04, 24.04, 26.04 i 26.10; només queda pendent d'avaluar a 18.04 i 20.04. En una Ubuntu moderna aquest paquet no l'instal·la ni l'actualitza el teu gestor de paquets, perquè no el porta. El va baixar algú a mà, o va entrar dins d'una imatge de contenidor. Les teves actualitzacions desateses no el tocaran mai. És la mateixa dinàmica que explicàvem amb el final de suport de PostgreSQL 14: el que no és a l'inventari no té qui l'avisi.
D'on surt un bolcat «aliè»?
«Bolcat no fiable» sona a laboratori fins que et poses a enumerar d'on arriben els bolcats que restaures. Nosaltres movem dades entre sistemes per viure —integracions i ETL— i la llista real és més curta i més incòmoda del que sembla:
- ·El bolcat que t'envia un client nou per migrar-li l'aplicació. El va generar el seu proveïdor anterior, en una màquina que ningú no ha tornat a mirar.
- ·El bolcat d'un entorn de preproducció que administra l'equip de desenvolupament del client, no tu, i on qualsevol pot crear col·leccions.
- ·El bolcat que recuperes d'una màquina que ja saps compromesa, per aixecar el servei en un altre lloc mentre s'investiga. Aquest és el pitjor, perquè és justament quan vas amb pressa.
- ·El bolcat que baixes d'un bucket d'objectes la llista de permisos del qual ningú no ha tornat a llegir des que es va crear.
El tercer és el que ens interessa de debò, perquè és el que converteix un 5,2 en un problema de continuïtat. Si estàs restaurant a les tres de la matinada des d'una còpia d'un sistema que acaba de ser atacat, estàs executant contingut d'origen dubtós amb el compte que ho pot tot, en l'únic entorn que et queda dret. És l'argument que ja vam fer parlant de per què restaurar no és recuperar, i aquesta vegada el fabricant ho posa per escrit en un avís.
Quan això NO corre pressa
Ho diem perquè seria fàcil vendre el contrari. Si els únics bolcats que restaures els va produir el teu propi clúster, si el compte amb què restaures no pot gestionar usuaris, i si no fas servir mongofiles per a res, el risc realista d'aquestes quatre és molt baix i no cal tocar res avui: entra a la teva finestra normal i prou. Un 2,1 i un 1,0 no són una emergència per molt que portin les sigles CVE davant.
El que ho fa urgent és una combinació concreta: restaures fitxers que no has generat tu, amb un compte que pot crear usuaris, i ho fas directament contra una instància que importa. Si les tres coses són certes a casa teva, les quatre CVE deixen de ser una nota al peu i la que crea comptes root es converteix en el camí més curt que té algú per entrar a la teva base de dades sense barallar-se amb el teu tallafoc. I l'arranjament no és un projecte: és un binari.
El cens: sis comprovacions
Cap no modifica res i cap no necessita comprar res. Són nostres, no de l'avís:
- 1.Executa
mongorestore --versional lloc des del qual restaures de debò. No al teu portàtil d'avui: al lloc on es va fer l'última restauració. - 2.Fes la llista d'on més viu aquell binari: portàtils de l'equip, imatges de contenidor del pipeline, el contenidor que llança la còpia nocturna, el jump host, la màquina d'un proveïdor. Que en surti un número.
- 3.Mira els rols del compte amb què restaures. Si pot gestionar usuaris, la condició prèvia de l'avís ja està complerta. Aquella és la que s'arregla avui i de franc.
- 4.Restaures un bolcat de fora primer contra una instància aïllada i d'un sol ús, i després mous les dades? Si la resposta és no, aquell és el canvi de procediment amb més retorn de tota la llista.
- 5.Si fas servir
mongofiles, comprova que totes les crides passen--localamb una destinació explícita. El mateix avís situa la fallada justament en el cas en què no s'especifica--local. - 6.Busca al log del teu pipeline la cadena de connexió de Mongo. Si apareix amb la contrasenya a dins, tens un segon problema que no porta CVE i que hi és des de fa més temps.
La número 2 és la que gairebé mai no té resposta, i és la interessant. La 1 es contesta en trenta segons i dóna una falsa tranquil·litat: el portàtil del qui mira està actualitzat, i el contenidor que restaura de debò porta la imatge de fa catorze mesos.
El que ens n'enduem
No som una consultora de MongoDB i no ho fingirem. El que sí que fem cada dia és moure dades entre sistemes que no es parlaven —integracions i ETL, amb les seves tasques de còpia i les seves restauracions de prova— i allà el patró d'aquestes quatre CVE és vell conegut: el connector. El binari que tradueix entre dues bandes, que ningú no va inventariar perquè no ocupa un port, i que s'actualitza quan algú se'n recorda. Dels motors de base de dades se n'ocupa mig món. Dels connectors, qui se'n recordi.
Per això els simulacres de recuperació que posem en un pla de disaster recovery van cada trimestre i amb cronòmetre. Un simulacre de debò contesta la pregunta 2 de la llista de dalt sense que ningú la formuli, perquè obliga a obrir la màquina des de la qual es restaura de debò. El nostre últim assaig de recuperació completa va sortir en catorze minuts —dada interna, prova i no promesa—. I el valor de cronometrar-lo no és només el minuter: un simulacre obliga a escriure la llista de màquines i versions des de les quals es restaura, que gairebé mai no està escrita enlloc.
Fonts (verificades el 07-11-2026): descripcions literals, dates de publicació (03-11-2026), vectors i puntuacions CVSS 4.0 i 3.1 assignades per MongoDB com a CNA, rangs de versions afectades i versió corregida (100.20.1) de les quatre CVE — NVD, CVE-2026-119675, CVE-2026-119674, CVE-2026-119673 i CVE-2026-119672; llistat dels quatre avisos amb els seus títols i productes afectats — MongoDB Alerts; data de la versió 100.20.1 (02-11-2026) i títols literals dels tiquets TOOLS-4352, TOOLS-4417, TOOLS-4422, TOOLS-4446 i TOOLS-4448 — changelog de mongo-tools; prioritat assignada i estat del paquet mongo-tools per release — Ubuntu Security tracker; numeracion separada de las Database Tools a partir de la 100.0.0 (antes compartian version con el servidor) — MongoDB Docs, Database Tools 100.0.0. La taula comparativa, la lectura sobre la direcció de la confiança, la llista d'orígens d'un bolcat i les sis comprovacions són elaboració nostra. La dada dels catorze minuts és un registre intern d'un simulacre propi, no una garantia de servei. Fotografia: «Interior of StorageTek tape library at NERSC (2)», de Derrick Coetzee, CC0 via Wikimedia Commons, retallada i aclarida per nosaltres.
Saps amb quina versió i amb quin compte es restaura a la teva empresa?
Fem el cens de les eines amb què mous i restaures dades, revisem els privilegis d'aquells comptes i cronometrem una recuperació de debò. Amb els teus sistemes, no amb una presentació.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN