Summary
DBHub's readonly = true setting may fail to make database connections read-only, leaving enforcement dependent on a statement classifier that can be bypassed by side effects hidden behind otherwise permitted SQL.
When the unauthenticated HTTP transport is reachable and a caller can submit SQL, this may allow database modification and, depending on database privileges, host file access, file writes, or remote code execution.
Affected context
The issue affects DBHub deployments before the release that corrected the read-only enforcement logic, particularly when:
- The
execute_sqltool is configured withreadonly = true - A connector's database-level read-only setting is not populated or applied
- SQL is permitted based primarily on its first statement keyword
- The HTTP transport is exposed to network callers, including deployments that bind broadly by default
Exploitability and impact depend on the database engine, configured account privileges, network exposure, and enabled database features.
Exploit preconditions
- Attack surface: The DBHub
/mcpHTTP endpoint and its SQL execution tool - Required access: Network reachability to the endpoint; authentication may not be required when the HTTP transport is deployed without an authentication layer
- Trigger point: Submission of SQL while the tool is configured as read-only
- Why exploitation is possible: The connector-level read-only control may not be activated, while first-keyword classification can treat side-effecting function calls within an apparently read-only statement as acceptable
- Privilege dependency: The resulting impact depends on the database role and permissions, ranging from database tampering to host file operations or code execution
Why this happens
The vulnerability combines ineffective enforcement of a security setting with incomplete statement classification. Connector code intended to enable database-native read-only behavior is gated by a configuration value that is not populated, so the stronger control is not applied.
The remaining classifier evaluates the first keyword rather than determining whether the complete statement is side-effect free. A statement beginning with SELECT can therefore invoke functions or features that alter data, access files, or execute other privileged operations. This maps primarily to CWE-863: Incorrect Authorization, with related characteristics of CWE-184: Incomplete List of Disallowed Inputs and CWE-636: Not Failing Securely in the Presence of Invalid Input.
Potential impact
- An attacker may alter database contents or sequences
- An attacker could bypass the intended read-only boundary
- A privileged database role may read arbitrary files from the database host
- A privileged role could write files to the server
- Database features may enable remote code execution under suitable permissions
- An exposed unauthenticated endpoint may permit unauthorized database operations
General mitigation guidance
Mitigation generally focuses on enforcing read-only behavior at the database connection and authorization layers rather than relying solely on SQL keyword inspection.
Defensive patterns include:
- Use database-native read-only transaction or connection controls that are reliably initialized and fail closed
- Apply an allowlist of explicitly supported, side-effect-free operations instead of classifying only the first keyword
- Use dedicated database roles with minimal privileges and no unnecessary file, administrative, or procedural capabilities
- Require authentication and authorization at the MCP transport boundary
- Bind services to restricted interfaces and apply network-level access policies
- Treat tool configuration as security-sensitive and validate it before accepting requests
- Separate query execution from administrative or host-integrated database features
- Prefer secure defaults that reject ambiguous statements and unavailable enforcement mechanisms
How teams detect issues like this
Detection approaches may include:
- Static analysis for read-only flags that are declared but not propagated to connector or transaction initialization
- Code review checks for authorization decisions based only on the first SQL token
- Tests containing side-effecting functions, procedure calls, nested expressions, and database-specific file or program interfaces
- Configuration audits for unauthenticated MCP endpoints, broad bind addresses, and database accounts with excessive privileges
- Runtime monitoring for unexpected write statements, sequence changes, large object exports, host-file access, or program execution initiated by database sessions
- Policy enforcement requiring authentication, restricted network exposure, and least-privilege database roles
Automated security scanners and code-review tools may help identify incomplete query filters and unprotected management endpoints, but database-specific behavioral tests remain important.
