KEVWire

Security intelligence, with context.

Response snapshot Nov 2, 2026, 20:01 UTC

Back to the wire
Permalink
VulnerabilityGHSA-j656-3hf2-fvjc

DBHub: MySQL and MariaDB comment interpretation bypasses read-only SQL validation

The read-only mode can be bypassed on the MySQL and MariaDB connectors. In read-only mode a caller can still execute arbitrary write and DDL statements (for example DROP TABLE), which defeats the protection that read-only mode is meant to provide when a database is exposed to an AI agent.

At a glance

Exploited
Not known
Severity
Not scored yet
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: @bytebase/dbhub: 0.22.6. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-j656-3hf2-fvjc (opens a new tab)

What happened

The read-only mode can be bypassed on the MySQL and MariaDB connectors. In read-only mode a caller can still execute arbitrary write and DDL statements (for example DROP TABLE), which defeats the protection that read-only mode is meant to provide when a database is exposed to an AI agent.

Root cause

The problem is a mismatch between how DBHub's SQL parser handles single-line comments and how MySQL and MariaDB actually parse them.

In src/utils/sql-parser.ts, scanSingleLineComment treats "--" as the start of a comment no matter what character follows it. MySQL and MariaDB only begin a "--" comment when the two dashes are followed by whitespace, a control character, or the end of the line. Otherwise the dashes are read as two minus signs and the rest of the line is ordinary SQL.

Continue reading

The read-only check in src/tools/execute-sql.ts splits the input and validates each statement with isReadOnlySQL, but the connector then executes the original, unmodified string. The MySQL and MariaDB connectors open their connection pool with multipleStatements: true (src/connectors/mysql/index.ts:54 and src/connectors/mariadb/index.ts:53) and run the whole string in a single call.

Because of this, the following payload:

SELECT 1--1;DROP TABLE victim

is seen by DBHub as a single SELECT statement, since everything after "--" is treated as a comment and the read-only check passes. MySQL and MariaDB instead parse it as "SELECT 1 - -1" followed by "DROP TABLE victim" and execute both statements.

Proof of concept

1) DBHub's own parser. Running splitSQLStatements and isReadOnlySQL from this repository on the payload returns a single statement and readOnly = true, so the query is allowed in read-only mode. The same code correctly rejects "SELECT 1; DROP TABLE victim", which confirms that the "--1" is what gets through.

2) Execution. Connecting to MariaDB 11.4 with mysql2 and multipleStatements: true (the same option the connector uses) and sending the payload returns 2 for the first statement, which confirms "--" was not treated as a comment, and then drops the table. The table exists before the call and is gone afterwards.

Impact

Read-only mode is the control operators rely on to let an assistant read from a database without being able to change it. With this bypass, anyone who can influence the SQL the assistant sends, most realistically through prompt injection in content the assistant reads, can perform writes and destructive DDL against MySQL and MariaDB. PostgreSQL is not affected by this path, because it treats "--" as a comment regardless and executes each split statement individually.

Affected code (current main, commit e99c3aa9, package version 0.22.3)

- src/utils/sql-parser.ts — scanSingleLineComment does not require whitespace after "--" - src/tools/execute-sql.ts — validates the split statements but executes the original string - src/connectors/mysql/index.ts and src/connectors/mariadb/index.ts — multipleStatements: true

Suggested fix

The most reliable fix is to stop executing the original string: run only the statements that were validated, and disable multipleStatements on the MySQL and MariaDB connections unless it is genuinely required. As defense in depth, make the comment scanner dialect-aware so that for MySQL and MariaDB "--" only starts a comment when it is followed by whitespace, a control character, or the end of the line, similar to the handling already in place for MySQL conditional comments.

Affected package ranges reported by GitHub: @bytebase/dbhub: < 0.22.6

Related technology

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-j656-3hf2-fvjc (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-j656-3hf2-fvjc, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, November 2). DBHub: MySQL and MariaDB comment interpretation bypasses read-only SQL validation. https://kevwire.com/record/GHSA-j656-3hf2-fvjc

MLA

"DBHub: MySQL and MariaDB comment interpretation bypasses read-only SQL validation." KEVWire, 2 Nov. 2026, kevwire.com/record/GHSA-j656-3hf2-fvjc.

Chicago

KEVWire. "DBHub: MySQL and MariaDB comment interpretation bypasses read-only SQL validation." Last modified November 2, 2026. https://kevwire.com/record/GHSA-j656-3hf2-fvjc.

Evidence summary (plain text)

DBHub: MySQL and MariaDB comment interpretation bypasses read-only SQL validation (Nov 2, 2026).
The read-only mode can be bypassed on the MySQL and MariaDB connectors. In read-only mode a caller can still execute arbitrary write and DDL statements (for example DROP TABLE), which defeats the protection that read-only mode is meant to provide when a database is exposed to an AI agent.

Root cause

The problem is a mismatch between how DBHub's SQL parser handles single-line comments and how MySQL and MariaDB actually parse them.

In src/utils/sql-parser.ts, scanSingleLineComment treats "--" as the start of a comment no matter what character follows it.
Sources:
GitHub-reviewed advisory GHSA-j656-3hf2-fvjc: https://github.com/advisories/GHSA-j656-3hf2-fvjc
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: GHSA-j656-3hf2-fvjc.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Nov 2, 2026, 19:45 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are coming as part of KEVWire Premium: join the waitlist. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail