CVE-2026-61788: 
JavaScript 취약성 분석 및 완화

CVE-2026-61788 is a read-only mode bypass vulnerability in DBHub, a database MCP (Model Context Protocol) server supporting PostgreSQL, MySQL, SQL Server, Oracle, MariaDB, and SQLite. Setting readonly = true on the execute_sql tool fails to enforce read-only access due to a misconfigured code path that is never executed, leaving only a weak keyword-based classifier as the sole enforcement mechanism. All versions prior to 0.22.6 of the @bytebase/dbhub npm package are affected. The vulnerability was originally published on June 24, 2026, and assigned a CVE on September 24, 2026, with a CVSS v3.1 base score of 7.4 (High) (GitHub Advisory, Bytebase Advisory).

The vulnerability stems from two compounding flaws classified as CWE-184 (Incomplete List of Disallowed Inputs), CWE-636 (Not Failing Securely), and CWE-863 (Incorrect Authorization). First, the database-level read-only enforcement is effectively dead code: PostgresConnector.connect() sets default_transaction_read_only=on only when config.readonly is truthy, but ConnectorConfig.readonly is populated solely from source.readonly, which can never be set because SourceConfig has no readonly field and the TOML loader explicitly rejects it at the source level. Second, the only active enforcement — the areAllStatementsReadOnly() classifier — only inspects the first keyword of each SQL statement and never examines function calls within SELECT statements. This allows SELECT-prefixed statements invoking side-effecting PostgreSQL functions (e.g., setval(), lo_export(), pg_read_file(), dblink_exec()) to pass the classifier unchallenged. Additionally, the HTTP transport binds to 0.0.0.0 and is unauthenticated by default, making the /mcp endpoint reachable by any network caller (GitHub Advisory, Bytebase Advisory).

With an ordinary database role, an unauthenticated network attacker can tamper with database sequences (e.g., via SELECT setval()), undermining data integrity. With a privileged role — common in practice since DBHub is frequently configured with admin DSNs — the attacker can write arbitrary files to the server via lo_export, read arbitrary host files (including /etc/passwd) via pg_read_file, and achieve full remote code execution on the database host via dblink_exec combined with COPY ... TO PROGRAM. The attack surface extends to any network caller of the unauthenticated /mcp endpoint, as well as malicious MCP clients or prompt injection attacks targeting agents wired to DBHub (Bytebase Advisory, GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of active in-the-wild exploitation at this time (GitHub Advisory). However, the advisory itself includes detailed PoC SQL payloads demonstrating the bypass, lowering the barrier for exploitation. The EPSS score is approximately 0.003 (0.3%), reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Reconnaissance: Identify internet-facing or network-accessible DBHub instances running versions prior to 0.22.6. The HTTP transport binds to 0.0.0.0 by default on a configurable port (e.g., 8080), so scanning for open ports with the /mcp endpoint is sufficient.
2. Confirm unauthenticated access: Send an HTTP request to the /mcp endpoint — no credentials are required. Confirm the DBHub instance is reachable and the execute_sql tool is available.
3. Bypass read-only classifier with sequence tampering (any role): Submit a SELECT-prefixed statement that calls a write-effecting function, bypassing the keyword classifier:

   SELECT setval('users_id_seq', 1);

   This passes the classifier as read-only but modifies the sequence on the server.
4. Escalate to file write (privileged role): If the database role has superuser or pg_write_server_files privileges, write arbitrary files to the server:

   SELECT lo_export(lo_from_bytea(0, decode('48656c6c6f0a','hex')), '/tmp/dbhub_poc');

5. Read arbitrary host files (privileged role): Exfiltrate sensitive files from the database host:

   SELECT pg_read_file('/etc/passwd');

6. Achieve remote code execution (privileged role with dblink): Execute arbitrary OS commands on the database host using dblink and COPY ... TO PROGRAM:

   SELECT dblink_exec('dbname=app', $$COPY (SELECT 1) TO PROGRAM 'id > /tmp/pwned'$$);

   This runs the shell command as the PostgreSQL service account (Bytebase Advisory, GitHub Advisory).

• Network: Unexpected HTTP POST requests to the /mcp endpoint from untrusted or external IP addresses; outbound connections from the database host to unknown external IPs following DBHub activity.
• Logs: PostgreSQL query logs showing SELECT setval(...), SELECT lo_export(...), SELECT pg_read_file(...), or SELECT dblink_exec(...) statements executed under a read-only tool context; DBHub access logs showing repeated or anomalous calls to execute_sql with function-based SELECT payloads.
• File System: Unexpected new files in world-writable directories (e.g., /tmp/) created by the PostgreSQL service account; files matching patterns like /tmp/dbhub_poc or /tmp/pwned.
• Process: Unusual child processes spawned by the PostgreSQL backend process (e.g., sh, bash, id, curl, wget) as a result of COPY ... TO PROGRAM execution.
• Database: Unexpected changes to sequence values (e.g., users_id_seq reset to anomalous values); new large objects created in PostgreSQL (pg_largeobject table entries) not associated with normal application activity (Bytebase Advisory).

Upgrade DBHub (@bytebase/dbhub) to version 0.22.6 or later, which adds engine-level read-only enforcement per tool (PostgreSQL BEGIN READ ONLY, SQLite query_only, MySQL/MariaDB START TRANSACTION READ ONLY) and hardens the SQL classifier (GitHub Advisory). If immediate patching is not possible, restrict network access to the DBHub HTTP transport (which listens on 0.0.0.0 by default) to trusted networks only using firewall rules or network segmentation. Additionally, ensure the database role used by DBHub is minimally privileged — specifically, it should not have access to dangerous functions such as lo_export, pg_read_file, pg_execute_server_program, or the dblink extension, which are required for the most severe exploitation paths (Bytebase Advisory).