Summary
MongoDB Compass may insert a database name into the initial input of its embedded MongoDB shell without escaping it. Under specific conditions, a user who can create a database on a server connected to Compass may cause content to be evaluated as shell input when the Compass user opens that database's shell.
Affected context
The issue occurs when MongoDB Compass opens its embedded shell from a database view and constructs the shell's initial input using a database name received from the connected server. Risk depends on an attacker being able to create or control a database name and on a Compass user choosing to open the shell for that database.
Exploit preconditions
- Attack surface: Database metadata displayed and processed by the MongoDB Compass desktop client
- Required access: Permission to create databases on a server that the target Compass user connects to
- Trigger point: The target user opens the embedded shell from the affected database's view
- Why exploitation is possible: The database name is interpolated into shell input without adequate escaping, allowing specially crafted metadata to influence evaluation in the Compass process
Why this happens
The underlying bug is an improper separation between data and executable shell input. A database name obtained from a server is inserted into a shell initialization command without applying context-appropriate escaping or treating the value strictly as data. This maps to CWE-94: Improper Control of Generation of Code, because attacker-influenced content can alter code or commands evaluated by the application.
Potential impact
- Arbitrary code or shell input may execute within the MongoDB Compass process
- The attacker could access resources available to the Compass user's operating-system account
- Local files, credentials, or application data may be exposed or altered
- The affected workstation could be used as a foothold for further compromise
General mitigation guidance
Mitigation generally focuses on preserving a strict data boundary between database metadata and shell commands.
Common defensive patterns include:
- Passing database names through structured arguments or APIs rather than string interpolation
- Applying context-specific escaping when values must be embedded in shell input
- Treating server-provided metadata as untrusted input, even when it is displayed in a trusted client
- Avoiding automatic execution of constructed shell content and requiring explicit, reviewed actions
- Running desktop database tools with least privilege and limiting access to sensitive local resources
- Applying server-side permissions that restrict who can create databases
How teams detect issues like this
Detection approaches commonly include:
- Static analysis rules for string concatenation or interpolation into shell, scripting, or command-execution APIs
- Code review checks for server-provided identifiers entering embedded console initialization paths
- Tests using boundary characters and unexpected metadata values to verify that content remains data
- Policy enforcement that restricts dynamic command construction and requires approved escaping or structured APIs
- Endpoint monitoring for unexpected child processes or command activity originating from the database client
Automated code review and application security tools may help identify unsafe data-to-code flows.
