CVE-2026-61788: Read-Only Bypass in DBHub Database Model Context Protocol Server

DBHub operates as an open-source database Model Context Protocol (MCP) server that exposes database interaction capabilities to network clients. The application facilitates connections to multiple SQL backends, including PostgreSQL, MySQL, MariaDB, and SQLite. To prevent unauthorized data modification, DBHub implements an execute_sql interface exposing a parameter to enforce read-only query execution.

This application-level protection mechanism is bypassed in DBHub versions prior to 0.22.6. The vulnerability allows unauthenticated network actors to submit crafted database queries that circumvent local query validation filters. Consequently, requests labeled as read-only are processed as fully privileged, writable database commands.

The vulnerability is highly critical because DBHub's HTTP transport is unauthenticated by default. Furthermore, the daemon binds to the wildcard network interface (0.0.0.0), exposing the management endpoint to any system capable of routing traffic to the default host port. The combination of unauthorized API access and insecure execution control exposes the underlying databases and hosting infrastructure to complete compromise.

The vulnerability in DBHub stems from a dual-failure architecture that pairs inactive configuration code with a flawed, string-matching input classifier.

The first failure resides within the connection management component (src/connectors/manager.ts). The codebase contained logic intended to initialize underlying database connectors using read-only connection limits (e.g., activating default_transaction_read_only in PostgreSQL or opening SQLite databases in a read-only mode). However, the property flag config.readonly was mapped to a non-existent configuration key (source.readonly). Because of this logical error, the application consistently evaluated config.readonly as undefined, failing to ever enable connection-level or driver-level read-only protections.

The second failure involves the fallback application-level classifier, isReadOnlySQL. Because database-level write restrictions were inactive, the security of the application depended entirely on checking whether queries started with safety-associated keywords such as SELECT or WITH. Attackers can bypass this classifier through three key engine-specific discrepancies:

1. PostgreSQL Side-Effects: PostgreSQL permits nested system function executions and schema mutations within a SELECT statement. Queries such as SELECT lo_export(1234, '/path/file') or SELECT setval(...) begin with the permitted SELECT keyword, allowing them to pass the classifier while executing write operations or modifying local system files.

2. MySQL/MariaDB Comment-Parsing Discrepancies: Under MySQL and MariaDB rules, a double-dash (--) initiates a comment block only when followed by a whitespace character. If followed immediately by a non-whitespace character, the engine interprets it as dual subtraction operators (e.g., 1--1 translates to 1 - (-1)). DBHub's custom pre-parser stripped any query string starting with -- as a comment globally. By submitting a payload such as SELECT 1--1; DROP TABLE users;, the DBHub parser stripped the suffix, saw only SELECT 1, and passed the query. The backend database engine, however, evaluated SELECT 1--1 as the first statement, resolved the statement separator, and proceeded to execute the destructive DROP TABLE command.

3. SQLite PRAGMA Parenthesized Setters: DBHub restricted PRAGMA state modifications by searching for an equal sign (=) in SQLite queries. SQLite allows an alternative parenthesized setter syntax where PRAGMA user_version(1337) behaves identically to PRAGMA user_version = 1337. This alternative syntax bypassed the regex detection, enabling attackers to alter SQLite session parameters.

An analysis of the fix commit (872bb338f7d31f6afe517a076ac3e3edafaaaf08) shows a transition from application-side string matching to native, engine-enforced transaction controls. Below is a conceptual breakdown of the remediation changes implemented across different connectors.

In the PostgreSQL connector (src/connectors/postgres/index.ts), DBHub was patched to wrap query executions in an explicit read-only transaction block whenever the read-only flag is set:

// Patched execution block in PostgreSQL connector
if (options.readonly) {
  // Force PostgreSQL engine to enforce read-only transaction constraints
  await client.query('BEGIN READ ONLY');
  try {
    const result = await client.query(sql);
    await client.query('COMMIT');
    return result;
  } catch (error) {
    try { 
      await client.query('ROLLBACK'); 
    } catch (rollbackErr) {
      // Prevent rollback suppression from hiding original query errors
    }
    throw error;
  }
}

For SQLite connectors (src/connectors/sqlite/index.ts), the patch applies structural query-level locks, toggling PRAGMA query_only = ON before executing client commands, and reverting it securely inside a finally block:

// Patched execution block in SQLite connector
if (options.readonly) {
  await db.run('PRAGMA query_only = ON;');
}
try {
  return await db.all(sql);
} finally {
  if (options.readonly) {
    await db.run('PRAGMA query_only = OFF;');
  }
}

To address MySQL implicit commits on Data Definition Language (DDL) operations—where statements like DROP TABLE force a transaction commit and ignore read-only transaction blocks—the parser was supplemented with a hardened scanner. The new scanSingleLineCommentMySQL function correctly mirrors database engine behavior:

// Hardened parser verification for MySQL comment markers
function scanSingleLineCommentMySQL(sql: string, i: number): SQLToken | null {
  if (sql[i] !== "-" || sql[i + 1] !== "-") {
    return null;
  }
  const next = sql[i + 2];
  // MySQL requires whitespace or control characters after -- to treat it as a comment
  if (next !== undefined && next.charCodeAt(0) > 0x20 && next.charCodeAt(0) !== 0x7f) {
    return null; // Evaluated as mathematical operators, not a comment boundary
  }
  // Standard comment processing continues...
}

These modifications ensure that if an attacker attempts to hide stacked DDL commands within a malformed comment block, the database-specific pre-parser fails to strip the text, accurately identifies the presence of multiple statements, and blocks execution before the payload reaches the driver.

To exploit an unpatched DBHub deployment, an attacker must transmit a crafted JSON-RPC request targeting the /mcp HTTP endpoint. The tool name execute_sql is specified along with the readonly: true parameter, simulating a legitimate analytical tool request.

The diagram below outlines the logical path of an exploitation attempt utilizing the MySQL comment parsing mismatch:

A sample exploit payload targeting an unpatched MySQL connector would be structured as follows:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "execute_sql",
    "arguments": {
      "sql": "SELECT 1--1;INSERT INTO users (username, password) VALUES ('malicious_root', 'hash');",
      "readonly": true
    }
  }
}

When processed by an affected system, the custom parser incorrectly identifies the entire segment starting at --1 as a comment, stripping it and validating the single remaining token SELECT 1. The unstripped, full SQL string is then forwarded to the MySQL connection driver, which executes the database modification without restriction.

The security impact of CVE-2026-61788 is classified as High, yielding a CVSS score of 7.4. Although DBHub runs locally as a proxy component, its default configuration binds to 0.0.0.0 without access control mechanisms, exposing database resources to remote networks.

The successful exploitation of this flaw breaks the isolation boundary between analytics workflows and administrative controls. An attacker can write arbitrary data to host database tables, alter configuration variables, or corrupt system logging tables. If DBHub is configured to access databases using highly privileged roles (e.g., postgres or root), the impact extends to the hosting server file system.

On PostgreSQL backends, attackers can leverage administrative functions inside nested SELECT queries to achieve remote code execution. For example, executing a query that calls lo_export allows writing arbitrary binary payloads to host directories, while utilizing COPY ... FROM PROGRAM allows executing system-level commands as the database runtime user. This capability bypasses the read-only policy and leads to host-level compromise.

The primary remediation for CVE-2026-61788 is upgrading DBHub to version 0.22.6 or higher. This version implements correct, engine-specific connection read-only flags and includes the updated SQL pre-parser code to safely handle MySQL and SQLite formatting anomalies.

When immediate patching is not possible, security administrators should apply the following defensive workarounds:

1. Modify Network Bindings: Force the DBHub daemon to bind strictly to the local loopback interface (127.0.0.1) rather than the wildcard interface (0.0.0.0). This restricts access to processes running locally on the system.

2. Network Filtering: Implement firewall rules (e.g., iptables, security groups) to restrict incoming traffic to the TCP port hosting the /mcp endpoint. Access should be permitted only from trusted clients.

3. Enforce Database Least Privilege (PoLP): Configure DBHub connection profiles to use low-privileged database roles. If an application profile requires only read-only access, enforce this restriction directly inside the database management system (DBMS) by revoking INSERT, UPDATE, DELETE, and file-access permissions for that user. This prevents code-level bypasses from translating into state modifications.