# Reported issues for mongo-scout-mcp

Pod holds 16 of 22 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [mongo-scout-mcp](/mcp/mongo-scout-mcp).

## Most discussed

### sec: redact connection strings in error output and logs

## Summary

The MongoDB connection URI (which may contain credentials) is exposed in multiple ways:

1. **Process arguments**: Visible in `/proc/<pid>/cmdline` on Linux since the URI is passed as a CLI argument
2. **Error messages**: MongoDB error messages often include the URI and are written to stderr without redaction in `src/index.ts`
3. **Log files**: `logToolUsage` in `src/utils/logger.ts` writes full tool arguments to disk without sanitization

## Proposed Fix

1. Support `MONGODB_URI` en

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/37) · 2026-02-27 · closed · 1 comment

### sec: enforce upper bounds on query result limits

## Summary

Several tools have no maximum cap on the `limit` parameter:

| Tool | Default | Max enforced |
|---|---|---|
| `find` | 10 | **None** |
| `textSearch` | 10 | **None** |
| `exportCollection` | none | **None** |
| `findRecent` | 100 | **None** |
| `findInTimeRange` | 100 | **None** |
| `inferSchema` (sampleSize) | 100 | **None** |

An agent could request `limit: 10000000`, causing memory exhaustion or excessive data transfer.

## Proposed Fix

Add `.max()` to all Zod limit/sampleSize s

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/35) · 2026-02-27 · closed · 1 comment

### fix: security gaps in profiler filters, projections, monitoring bounds, export limits, field names, and logging

## Security Findings

Six verified vulnerabilities ranging from High to Low-Medium severity.

### 1. HIGH — getProfilerStats accepts raw filters without operator blocking
- `monitoring.ts:~485`: `filter` passed directly to `.find(filter)` without `preprocessQuery()` / `assertNoDangerousOperators()`
- Allows `$where`/`$function`/`$accumulator`/`$eval` in profiler queries

### 2. HIGH — cloneCollection/exportCollection/analyzeQueryPerformance: unvalidated projections
- `data-quality.ts:~318`: proj

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/45) · 2026-02-28 · closed · 0 comments

### sec: validate nested collection name params (relationshipMapper)

## Summary

Follow-up from #34 / PR #42.

`wrapServerWithNameValidation` validates top-level collection name params, but `relationshipMapper` in `src/tools/data-quality.ts` accepts `foreignCollection` nested inside `relationships[]`:

```typescript
relationships: z.array(z.object({
  localField: z.string(),
  foreignCollection: z.string(),  // nested — not caught by wrapper
  foreignField: z.string(),
  as: z.string().optional(),
})),
```

A payload like `{ relationships: [{ foreignCollection: "

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/43) · 2026-02-27 · closed · 0 comments

### sec: preprocess textSearch filter consistently

## Summary

In `src/tools/advanced-operations.ts`, the `textSearch` tool spreads user-provided `filter` directly into the query without passing it through `preprocessQuery()`:

```typescript
const query: any = { $text: { $search: searchText } };
if (filter) Object.assign(query, filter);
```

Every other tool that accepts a filter runs it through `preprocessQuery()` first. This inconsistency means:
- ObjectId string-to-ObjectId conversion does not happen for textSearch filters
- Any future filter

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/36) · 2026-02-27 · closed · 0 comments

### sec: validate collection and database names

## Summary

Collection names across all tools are `z.string()` with no restrictions. Database names in tools like `getDatabaseStats` and `getProfilerStats` are similarly unrestricted.

## Attack Vector

An agent could access:
- `system.profile` — read profiling data (contains query details, auth info)
- `system.js` — stored JavaScript functions (in read-write mode: inject server-side JS)
- `system.users` / `admin.system.users` — authentication data
- `local.oplog.rs` — replication oplog
- Any da

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/34) · 2026-02-27 · closed · 0 comments

### sec: gate runAdminCommand write-capable commands in read-only mode

## Summary

`runAdminCommand` in `src/tools/monitoring.ts` is **not** marked as `writeOperation = true`, so it is registered even in read-only mode. Several allowed admin commands can **modify server state**:

| Command | Effect |
|---|---|
| `profile` | Enables profiling — writes to `system.profile`, degrades performance |
| `validate` with `repair: true` | Can modify/repair data |

Additionally, information-leaking commands are available:
- `getCmdLineOpts` — exposes server startup configurati

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/33) · 2026-02-27 · closed · 0 comments

### sec: validate bulkWrite sub-operations

## Summary

The `bulkWrite` tool in `src/tools/advanced-operations.ts` accepts `operations: z.array(z.record(z.any()))` and passes them **directly** to `db.collection(collection).bulkWrite(operations)` with zero validation.

## Current State

- No filter validation (empty filters allowed — could delete/update all documents)
- No operation type restriction
- No `shouldBlockFilter()` check (unlike `updateMany`/`deleteMany` which do check)
- No limit on number of operations
- No dangerous operator 

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/32) · 2026-02-27 · closed · 0 comments

## Most recent

### sec: block dangerous MongoDB query operators ($where, $function, $accumulator)

## Summary

No tool in the codebase blocks dangerous MongoDB query operators that enable **arbitrary server-side JavaScript execution**. The following operators pass through unchecked to the MongoDB server:

| Operator | Where it can appear | Risk |
|---|---|---|
| `$where` | Any filter/query | Executes arbitrary JS on the MongoDB server |
| `$function` | Aggregation `$expr`, `$addFields` | Executes arbitrary JS on the MongoDB server |
| `$accumulator` | Aggregation `$group` | Executes arbitrary

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/31) · 2026-02-27 · closed · 0 comments

### sec: block write-capable aggregation stages ($out, $merge) in pipeline validator

## Problem

The `aggregate` tool is registered as a read operation, making it available in read-only mode. However, users can pass write-capable aggregation stages (`$out`, `$merge`) through it, effectively bypassing read-only enforcement.

The pipeline validator (`src/utils/pipeline-validator.ts`) currently only validates stage count and expensive stage limits — it does not check for write-capable stages.

## Impact

- In read-only mode, a user (or an AI assistant via prompt injection) could ex

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/29) · 2026-02-27 · closed · 0 comments

### Log logger failures to stderr instead of silently swallowing them

## Problem

In `src/utils/logger.ts` (lines 18, 31, 51), all file I/O errors during logging are silently swallowed:

```typescript
} catch (error) {
  // Silently fail - logging is non-critical
}
```

While the comment notes that logging is non-critical, completely silent failures make it impossible to diagnose logging system problems — such as filesystem permission issues, disk-full conditions, or misconfigured log directories.

## Fix

At minimum, write a single `console.error` (or `process.st

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/23) · 2026-02-07 · closed · 0 comments

### Validate admin command parameters, not just command names

## Problem

In `src/tools/monitoring.ts:210-228`, `runAdminCommand` checks the command name against a whitelist but does not validate the command's parameters:

```typescript
const commandName = Object.keys(command)[0]?.toLowerCase();
if (!commandName || !allowedCommands.includes(commandName)) {
  // blocked
}
// But no validation of command[commandName] contents
```

While the whitelist limits which commands can run, whitelisted commands may still accept dangerous nested parameters that could h

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/22) · 2026-02-07 · closed · 0 comments

### Set up CI with GitHub Actions

## Problem

There is no CI/CD configuration in the project — no GitHub Actions, no automated testing on PRs, no release pipeline. Combined with the lack of tests, this means regressions can ship silently.

## Recommendation

1. Add a basic GitHub Actions workflow that runs on PRs and pushes to main:
   - `pnpm install`
   - `pnpm build` (TypeScript compilation check)
   - `tsc --noEmit` (type checking)
   - `pnpm test` (once tests exist)
   - Lint check (ESLint)
2. Consider adding a release work

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/21) · 2026-02-07 · closed · 0 comments

### Add complexity limits for aggregation pipelines

## Problem

In `src/tools/document.ts:97`, the `aggregate` tool accepts arbitrary pipeline arrays with no validation of depth or stage count:

```typescript
const result = await db.collection(collection).aggregate(pipeline, options).toArray();
```

A deeply nested or excessively complex pipeline could exhaust MongoDB server resources (CPU, memory), acting as a potential DoS vector — especially in a context where an AI assistant constructs pipelines.

## Recommendation

1. Cap the maximum number 

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/20) · 2026-02-07 · closed · 0 comments

### Add try/finally for aggregation cursor cleanup in data-quality tools

## Problem

In `src/tools/data-quality.ts` (~line 1253), aggregation cursors in `findOrphans` and similar functions are not wrapped in try/finally blocks:

```typescript
const orphans = await collectionObj.aggregate(pipeline).toArray();
const countResult = await collectionObj.aggregate(countPipeline).toArray();
```

While `toArray()` closes the cursor on success, if an error occurs mid-execution (e.g., network timeout), the cursor could leak on the MongoDB server, eventually leading to resource 

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/19) · 2026-02-07 · closed · 0 comments

### Fix potential infinite loop in exploreRelationships cycle detection

## Problem

In `src/tools/data-quality.ts` (~line 1665), the `exploreDocumentRelationships` function uses a `visited` Set for cycle detection:

```typescript
const docKey = \`\${rootCollection}:\${rootDoc._id}\`;
if (visited.has(docKey)) {
  return { document: rootDoc, circular: true };
}
```

The issue is that `rootDoc._id` could be an ObjectId object, and string interpolation may produce inconsistent keys for the same document depending on how it's accessed. This can cause cycle detection to f

[Read the thread](https://github.com/bluwork/mongo-scout-mcp/issues/18) · 2026-02-07 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/bluwork/mongo-scout-mcp/issues).