Restoring someone else's dump can create a root account

On 3 November 2026, MongoDB published four security advisories at once. Not one of the four is patched on your database. All four are fixed by moving Database Tools to version 100.20.1: that handful of command-line binaries — mongodump, mongorestore, mongofiles, mongoimport — which don't live on the server but on the laptop of whoever does the restores, in the container image that runs the nightly backup, and on the jump host everyone goes through. Your cluster can be fully up to date and still have all four.

What the advisory actually says

The serious one of the four is CVE-2026-119675, and it's worth reading as published, because the short version doesn't stand on its own. Per the advisory, mongorestore "inconsistently handles the system.buckets. prefix when validating collection names in an untrusted dump", and therefore "a specially crafted collection name can bypass special-collection guards and operator namespace filters, causing a restore to create an unauthorized user-chosen database account, including an account with the root role".

The project changelog is more explicit about the mechanism than the advisory is. The ticket that closes it is titled, word for word, "mongorestore should reject crafted collection names that resolve to $admin.system.auth collections". The name didn't land in some arbitrary collection: it resolved into the collection where Mongo keeps its users. There's no privilege escalation and no memory corruption here: the file carries documents, the tool writes them where it's told, and where it's told is the account register.

There are two preconditions and both matter. First, the dump has to come from outside your control. Second, whoever restores it does so "using credentials with sufficient user-management privileges on the destination deployment". Neither is exotic. Most people restore with whatever account is to hand, and the account to hand is usually the one that can do everything.

The other three are the same idea

All four were published the same day, the same hour, and all four close in 100.20.1. The scores are the ones MongoDB assigned as CNA, in both versions of the scale:

The right-hand column has one oddity: within this same batch, from the same vendor on the same day, the two versions of the scale disagree in opposite directions. The mongorestore one is 5.2 under CVSS 4.0 and 8.6 under 3.1; the mongofiles one is 5.9 under 4.0 and 4.8 under 3.1. Anyone filtering on "7 and above" will see one, two or none, depending on where they pull the number from.

Of the three lesser ones, the most operationally dizzying is CVE-2026-119674, a scrawny 2.1: mongorestore mis-decodes a collection's original name when the dump's filename has been truncated, and the documents land in a different collection than intended. The advisory adds two consequences no two-digit number conveys: "when both collection names resolve to the same destination, backed-up documents may be omitted", and "use of --drop can also replace the unintended destination collection". Translated: a restore that finishes without an error, with data missing, and a --drop that takes out something you never meant to touch.

The mongofiles one (CVE-2026-119672) is almost elegant in its smallness. When retrieving a file by its identifier (get_id), the tool uses the filename stored in the database as its output destination, if you don't pass --local. Anyone who can edit that metadata sets the name to a hyphen, and the next legitimate download no longer writes a file: it writes to standard output. If that output is being captured somewhere the attacker can reach — a pipeline log, say — they get the contents. One hyphen. And it reaches back to version 3.1.4, from a numbering scheme that predates these tools being split off into the 100.x series.

The trust ran the other way

We're used to thinking about database security in one direction: the server distrusts the client, demands credentials, constrains its roles. These four run the other way. Here the client believes what comes from the other side: a collection name written inside a file, a filename returned by the server, a hyphen that turns out to mean "write to the screen". The tool acts as interpreter between two worlds, and it trusts the wrong one.

That reading isn't our inference: it's in the 100.20.1 changelog, released on 2 November 2026, a day before the advisories. Among the closed tasks there are three security fixes with no CVE assigned. The third explains why mongoimport is in the batch too: it is titled "Mongoimport allows query-operator injection into the selector". The other two set the pattern. One is titled "Mongodump: validate server-returned collection names to prevent path traversal": meaning that in the dumping direction too, not just restoring, a server you don't control could make your mongodump write outside the target directory. The other, "Redact secrets from connection strings in error messages": the connection string, password and all, was showing up in error messages. Error messages from an automated job go to the log, and more people read the log than read the database.

Why your scanner will find nothing

Two of the four vectors are AV:L, local. All four need a human in the loop: UI:P in 4.0, UI:R in 3.1. That changes the arithmetic of exposure. With an exposed service, what you count is the days between a patch shipping and a patch landing; here there is nothing to count, because nothing is listening on a port. The window doesn't open on the day of the advisory: it opens the next time somebody runs a restore. That could be this afternoon or it could be in March.

And there's a detail that seals it, and it's the one that turns this into an inventory problem rather than a patching one. On Ubuntu's security tracker, the priority assigned to CVE-2026-119675 is medium, and the status of the mongo-tools package is "not in release" for 22.04, 24.04, 26.04 and 26.10; it's only pending evaluation on 18.04 and 20.04. On a modern Ubuntu your package manager neither installs nor updates this package, because it doesn't ship it. Somebody downloaded it by hand, or it came in inside a container image. Your unattended upgrades will never touch it. It's the same dynamic we described with PostgreSQL 14 going end of life: what isn't in the inventory has nobody to warn it.

Where does someone else's dump come from?

"Untrusted dump" sounds like a lab exercise until you start listing where the dumps you restore actually come from. Moving data between systems is our day job — integrations and ETL — and the real list is shorter and more uncomfortable than it looks:

The third is the one that really matters, because it's the one that turns a 5.2 into a continuity problem. If you're restoring at three in the morning from a copy of a system that has just been attacked, you're executing content of dubious origin with the account that can do everything, in the only environment you have left standing. It's the argument we already made when we wrote about why restoring isn't recovering, and this time the vendor has put it in writing in an advisory.

When this is NOT urgent

We say this because the opposite would be easy to sell. If the only dumps you restore were produced by your own cluster, if the account you restore with can't manage users, and if you don't use mongofiles at all, the realistic risk from these four is very low and there's nothing to touch today: it goes into your normal window and that's that. A 2.1 and a 1.0 are not an emergency just because they come with a CVE number attached.

What makes it urgent is one specific combination: you restore files you didn't generate, with an account that can create users, and you do it straight against an instance that matters. If all three are true in your shop, the four CVEs stop being a footnote and the root-account one becomes the shortest path anyone has into your database without picking a fight with your firewall. And the fix isn't a project: it's a binary.

The inventory: six checks

None of them changes anything and none of them needs you to buy anything. They're ours, not the advisory's:

Number 2 is the one that almost never has an answer, and it's the interesting one. Number 1 is answered in thirty seconds and gives false comfort: the laptop of the person looking is up to date, and the container that actually does the restoring is running a fourteen-month-old image.

What we take from this

We're not a MongoDB consultancy and we won't pretend to be. What we do every day is move data between systems that weren't talking to each other — integrations and ETL, with their backup jobs and their test restores — and there the pattern in these four CVEs is an old acquaintance: the connector. The binary that translates between two sides, that nobody inventoried because it doesn't occupy a port, and that gets updated whenever somebody remembers. Half the world takes care of database engines. Connectors get whoever remembers.

That's why the recovery drills we build into a disaster recovery plan run every quarter and against a stopwatch. A real drill answers question 2 above without anybody asking it, because it forces you to open up the machine the restore actually runs from. Our last full recovery rehearsal came in at fourteen minutes — internal figure, a test and not a promise. And the value of timing it isn't only the stopwatch: a drill forces you to write down the list of machines and versions the restore runs from, which is almost never written down anywhere.

Sources (verified on 2026-11-07): verbatim descriptions, publication dates (2026-11-03), CVSS 4.0 and 3.1 vectors and scores assigned by MongoDB as CNA, affected version ranges and the fixed version (100.20.1) for all four CVEs — NVD, CVE-2026-119675, CVE-2026-119674, CVE-2026-119673 and CVE-2026-119672; the list of all four advisories with their titles and affected products — MongoDB Alerts; the 100.20.1 release date (2026-11-02) and the verbatim titles of tickets TOOLS-4352, TOOLS-4417, TOOLS-4422, TOOLS-4446 and TOOLS-4448 — the mongo-tools changelog; assigned priority and the per-release status of the mongo-tools package — 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. The comparison table, the reading about the direction of trust, the list of dump origins and the six checks are our own work. The fourteen-minute figure is an internal record from one of our own drills, not a service guarantee. Photograph: "Interior of StorageTek tape library at NERSC (2)", by Derrick Coetzee, CC0 via Wikimedia Commons, cropped and brightened by us.