CVE-2026-61789: 
JavaScript Analyse et atténuation de la vulnérabilité

CVE-2026-61789 is a read-only SQL validation bypass vulnerability in DBHub, a database MCP (Model Context Protocol) server by Bytebase. It affects the MySQL and MariaDB connectors in all versions prior to 0.22.6 of the @bytebase/dbhub npm package. The vulnerability allows attackers who can influence the SQL queries processed by the DBHub assistant — including via prompt injection — to bypass read-only mode and execute arbitrary write or destructive DDL statements against MySQL or MariaDB databases. It was published on October 30, 2026, with a fix released in version 0.22.6. It carries a CVSS v4.0 base score of 6.1 (Medium) (GitHub Advisory, Bytebase Security Advisory).

The root cause is an interpretation conflict (CWE-436) combined with incorrect authorization (CWE-863) arising from a mismatch between DBHub's SQL parser and MySQL/MariaDB's actual comment syntax. In src/utils/sql-parser.ts, the scanSingleLineComment function treats any -- sequence as a comment start, but MySQL and MariaDB only recognize -- as a comment when followed by whitespace, a control character, or end-of-line — otherwise the dashes are treated as minus operators. The read-only check in src/tools/execute-sql.ts validates split statements using isReadOnlySQL, but the MySQL and MariaDB connectors (src/connectors/mysql/index.ts and src/connectors/mariadb/index.ts) execute the original, unmodified SQL string with multipleStatements: true enabled. This means a payload like SELECT 1--1;DROP TABLE victim is seen by DBHub's validator as a single read-only SELECT statement (everything after -- treated as a comment), while MySQL/MariaDB parse it as SELECT 1 - -1 followed by DROP TABLE victim and execute both. PostgreSQL is unaffected because its -- parsing matches DBHub's checker and its connector executes individually split statements (Bytebase Security Advisory, Fix PR #342).

Successful exploitation allows any party able to influence the SQL sent by the DBHub assistant — most realistically through prompt injection in content the assistant reads — to bypass read-only mode restrictions and execute write (INSERT, UPDATE, DELETE) or destructive DDL (e.g., DROP TABLE) statements against MySQL or MariaDB databases. The actual damage is bounded by the privileges of the database account used by DBHub, but could include unauthorized data modification, data deletion, or schema destruction. Confidentiality impact is rated None (the bypass does not expose data), while integrity and availability impacts are both rated High (GitHub Advisory, Bytebase Security Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires the ability to influence the SQL queries processed by the DBHub assistant, which is most realistically achieved through prompt injection in content the assistant reads (e.g., malicious data in a database record or document the AI agent processes). No threat actor attribution has been reported (GitHub Advisory, Feedly).

1. Identify a target: Locate a DBHub instance (versions < 0.22.6) configured with a MySQL or MariaDB backend operating in read-only mode, where the attacker can influence the SQL queries sent by the AI assistant (e.g., via prompt injection in database content or documents the assistant processes).
2. Craft the bypass payload: Construct a SQL string that exploits the comment-parsing discrepancy, such as SELECT 1--1;DROP TABLE victim or SELECT 1--1;UPDATE users SET password='hacked' WHERE id=1. The --1 sequence (double dash followed by a non-whitespace character) is treated as a comment by DBHub's parser but as minus operators by MySQL/MariaDB.
3. Inject the payload: Deliver the crafted SQL to the DBHub assistant through prompt injection — for example, by embedding the payload in a database record, document, or other content that the AI agent will read and incorporate into a SQL query.
4. Bypass read-only validation: DBHub's isReadOnlySQL validator sees only SELECT 1 (treating --1;DROP TABLE victim as a comment) and allows the query through read-only mode.
5. Achieve write execution: The MySQL/MariaDB connector executes the original string with multipleStatements: true, causing the database to interpret --1 as arithmetic and execute both SELECT 1 - -1 and the hidden write/DDL statement, resulting in unauthorized data modification or destruction (Bytebase Security Advisory, Fix PR #342).

• Database Logs: MySQL/MariaDB general query logs showing multi-statement executions containing patterns like -- followed immediately by a non-whitespace character (e.g., SELECT 1--1;DROP TABLE ... or SELECT 1--1;UPDATE ...) originating from the DBHub service account.
• Database Logs: Unexpected DDL statements (DROP, CREATE, ALTER) or DML writes (INSERT, UPDATE, DELETE) executed by the DBHub database user during periods when read-only mode should have been enforced.
• Application Logs: DBHub application logs showing SQL queries passed to MySQL/MariaDB connectors that contain --[non-whitespace] patterns followed by semicolons and write statements.
• Database State: Unexplained table drops, schema changes, or unauthorized data modifications in MySQL/MariaDB databases connected to DBHub, particularly when the DBHub instance is configured in read-only mode.

The primary remediation is to upgrade DBHub (@bytebase/dbhub) to version 0.22.6 or later, which enforces read-only mode at the database engine level (using START TRANSACTION READ ONLY for MySQL/MariaDB) in addition to fixing the -- comment scanner to require whitespace/control character/EOL after double dashes, matching MySQL/MariaDB engine behavior. As a defense-in-depth measure, apply the principle of least privilege to database accounts used by DBHub to limit the potential damage from SQL or prompt injection attacks. Until patching is possible, consider restricting the content the DBHub assistant can read to trusted sources to reduce prompt injection risk (Bytebase Security Advisory, v0.22.6 Release, Fix PR #342).

The vulnerability was reported by security researcher canolgun and acknowledged by Bytebase maintainer tianzhou, who merged the fix (PR #342) on June 24, 2026. The fix was comprehensive, addressing not only this bypass but also related read-only enforcement issues across multiple database connectors (PostgreSQL, SQLite, MySQL, MariaDB). No significant broader media coverage or social media discussion has been identified beyond the GitHub advisory and pull request (Bytebase Security Advisory, Fix PR #342).