Executive brief
Bytebase DBHub is a code library for executing SQL queries against databases. When the read-only mode is enabled on the execute_sql tool to prevent data modification, it can be bypassed using database functions like lo_export, pg_read_file, and dblink that perform writes or execute commands despite appearing as SELECT statements. Attackers can modify data, write files to the database server, read sensitive host files, or execute arbitrary code—especially dangerous when DBHub is configured with privileged database credentials or exposed via the unauthenticated HTTP interface.
Technical details
The vulnerability stems from two root causes: (1) a configuration pathway that never activates connection-level read-only enforcement in PostgreSQL (default_transaction_read_only), SQLite (readOnly mode), or MySQL/MariaDB (START TRANSACTION READ ONLY), leaving only a keyword-based classifier as protection; and (2) the classifier checks only the first SQL keyword, allowing any SELECT statement to pass even when it calls side-effecting functions. Functions like setval() (sequence modification), lo_export() (arbitrary file write), pg_read_file() (arbitrary file read), and dblink_exec() with COPY TO PROGRAM (remote code execution) all bypass the read-only check. The HTTP transport is unauthenticated and binds to 0.0.0.0 by default, making this remotely exploitable via /mcp endpoint or through MCP clients. The issue affects all versions up to 0.22.2 on PostgreSQL, SQLite, and MySQL/MariaDB.
Affected products
- Bytebase DBHub up to and including 0.22.2
Timeline
- 2026-09-24: disclosed
- 2026-09-24: patched: Fix available in PR#342 adds engine-level read-only enforcement and classifier hardening