Read-Only Bypass via Aggregation Pipeline in DocumentDB MCP Server
First seen Aug 6, 2026 · Updated Aug 6, 2026 · CVSS 5.5
The AWS Labs DocumentDB MCP Server before version 1.0.12 fails to properly enforce read-only mode when processing certain aggregation pipeline stages, allowing an authenticated MCP client to perform unintended write operations on the connected database. This is a logic flaw in authorization enforcement rather than a novel AI-specific attack, but it is significant because agents and LLM-driven clients often rely on the read-only flag as a safety boundary to prevent destructive actions. Exploitation requires an already-authenticated client, limiting severity, but the impact on data integrity could be substantial in agentic workflows that assume read-only guarantees.
Technical Analysis
The DocumentDB MCP Server exposes an aggregation pipeline tool intended to allow read-only querying when configured in restricted mode. Certain aggregation stages (e.g., write-capable stages such as $merge or $out) are not properly filtered or validated by the server's read-only enforcement logic, letting an authenticated MCP client construct a pipeline that performs writes despite the read-only flag being set. This crosses the trust boundary between the MCP client (potentially an LLM agent operating under the assumption that read-only mode prevents state changes) and the underlying database, granting write/modify capability where only read access was intended. The attacker gains unauthorized data modification capability, which in agentic pipelines could lead to data corruption, unauthorized state changes, or serve as a stepping stone for further compromise if the agent's outputs or decisions depend on database integrity. No sandbox escape or cross-agent propagation is involved; impact is confined to the connected database resource.
Affected Systems
AWS Labs DocumentDB MCP Server; protocols: MCP
Detection Signatures
- Aggregation pipeline requests containing write-capable stages ($merge, $out, $out-equivalent) submitted to an MCP server configured in read-only mode
- Audit logs showing write operations (inserts/updates/collection creation) originating from sessions or API keys tagged as read-only
- Monitor DocumentDB/MCP server logs for pipeline stage names inconsistent with declared read-only tool permissions
- Alert on MCP tool invocations where declared tool capability metadata says 'read-only' but resulting database operation type is write
Remediation Steps
- 1
Upgrade DocumentDB MCP Server
Update to AWS Labs DocumentDB MCP Server version 1.0.12 or later, which fixes the authorization bypass in the aggregation pipeline tool.
- 2
Enforce database-level access controls
Do not rely solely on application-layer read-only flags; configure database user roles/permissions to be genuinely read-only at the DocumentDB IAM/role level as defense in depth.
- 3
Audit and validate pipeline stages
Implement server-side allowlisting of permitted aggregation stages for read-only sessions, explicitly rejecting write-capable stages like $merge and $out.
- 4
Review logs for exploitation
Audit historical MCP server logs for any write operations executed under sessions configured as read-only to identify potential prior exploitation.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.