CVE-2026-119674 in Database Tools
Summary
by MITRE • 11/03/2026
MongoDB Database Tools mongorestore incorrectly URL-decodes an original collection name read from metadata when the corresponding dump filename has been truncated. A database user who can create and populate a suitably encoded collection can cause a later authorized directory restore to write those documents into a different collection that the user cannot modify directly. When both collection names resolve to the same destination, backed-up documents may be omitted; use of --drop can also replace the unintended destination collection. Exploitation requires an operator to restore the affected collection from a directory dump with write access to the destination. This issue affects MongoDB Database Tools versions 100.0.2 through versions before 100.20.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in MongoDB Database Tools involves a critical logic flaw within the mongorestore utility, specifically concerning how collection names are processed during directory-based restores. The core technical issue stems from an incorrect URL-decoding mechanism applied to original collection names extracted from metadata when the corresponding dump filename has been truncated or altered. In standard operation, mongoreuse relies on mapping filenames in a backup directory to specific database collections for restoration. However, under certain conditions where file paths are manipulated or naturally shortened, the tool fails to correctly reconcile the encoded name stored in the BSON metadata with the actual filesystem path. This discrepancy creates an opportunity for collection name collision and misdirection during the restore process.
From an operational security perspective, this flaw allows a database user who possesses write access to create and populate collections with specially crafted names that exploit this decoding error. When such data is backed up using mongodump and subsequently restored via mongorestore from a directory dump, the utility may incorrectly resolve the target collection name due to the truncation mismatch. Consequently, documents intended for one collection are written into a different collection entirely. This behavior effectively bypasses standard access control mechanisms because the attacker does not need direct write permissions on the destination collection; instead, they leverage the mongorestore process itself as an intermediary vector to inject data or overwrite content in collections where they lack explicit privileges.
The impact of this vulnerability is significant for environments relying on automated backup and restore procedures. If both the intended source collection name and the misdirected target resolve to the same destination due to encoding ambiguities, backed-up documents may be silently omitted, leading to data loss or inconsistency during recovery operations. Furthermore, if an operator utilizes the --drop flag during restoration, which is common practice for full database resets, the unintended destination collection will be dropped and replaced with the attacker-controlled content. This can result in severe integrity violations, unauthorized privilege escalation through data injection, or denial of service via destructive overwrites of critical system collections.
This issue falls under CWE-20 Improper Input Validation as it relates to mishandling encoded input during file path resolution, and aligns with ATT&CK techniques involving Data Injection for persistence or impact. The vulnerability affects MongoDB Database Tools versions 100.0.2 through those prior to version 100.20.1. Mitigation strategies primarily involve upgrading the affected tools to a patched version where the URL-decoding logic has been corrected to ensure consistent mapping between metadata and filesystem paths regardless of filename truncation. Additionally, administrators should enforce strict least-privilege principles for database users performing restore operations and validate backup integrity before relying on them in production environments. Regular auditing of restoration logs can also help detect anomalous collection name resolutions that may indicate exploitation attempts.