Read the docs
TI-2026-83204 Aliases CVE-2026-61789GHSA-j55q-p8qc-f6wg

Read-only bypass in DBHub MySQL and MariaDB connectors via comments

Priority MEDIUM 62CWE-436Published · Updated

Key facts

Attack vector
Network
Privileges required
None
User interaction
Passive
Attack complexity
Low
Attack requirements
Present
Impact type
Security bypass
Confidentiality · integrity · availability
None · High · High
Fix status
Fixed

Attack profile from CVSS 4.0 · CNA. Fix status from CNA. Impact type from CWE-863.

Summary

DBHub, a database MCP server, before 0.22.6 can have its read-only SQL validation bypassed on its MySQL and MariaDB connectors. The validator treats every double dash as a comment, while MySQL and MariaDB require whitespace, a control character, or the end of the line after it, so a later write or destructive DDL statement can escape the check (CWE-436). Anyone able to influence the assistant's SQL, including through prompt injection, can modify or drop data within the database account's privileges. CISA SSVC lists exploitation as poc.

Written with Claude Haiku 5.5 from the sources below · 2026-11-06

Description from the CNA

DBHub is a database MCP server for Postgres, MySQL, SQL Server, Oracle, MariaDB, SQLite. Prior to 0.22.6, read-only SQL validation can be bypassed on the MySQL and MariaDB connectors. In `src/utils/sql-parser.ts`, `scanSingleLineComment` treats every double dash as a comment start, whereas MySQL and MariaDB require following whitespace, a control character, or the end of the line. The read-only check in `src/tools/execute-sql.ts` validates split statements with `isReadOnlySQL`, but `src/connectors/mysql/index.ts` and `src/connectors/mariadb/index.ts` execute the original string with `multipleStatements` enabled. A double dash followed by a non-whitespace character can therefore hide a subsequent write or destructive DDL statement from the validator while the database interprets the dashes as minus operators and executes both statements. Anyone able to influence the assistant's SQL, including through prompt injection in content the assistant reads, can bypass read-only mode to modify or drop database data, subject to the database account's privileges. PostgreSQL is not affected by this path because its double-dash parsing agrees with the checker and its connector executes individual split statements. This issue is fixed in version 0.22.6.

Why it matters now

Exploitation Proof of concept CISA SSVC · not in CISA KEV
EPSS 0.00385 32nd percentileScored 2026-11-07
Fix Fixed dbhub (bytebase): 0.22.6

SSVC decision points

CISA ADP · SSVC 2.0.3

Exploitation
Poc
Automatable
No
Technical impact
Total

The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.

Affected products

VendorProductAffected versionsFixed inStatusSource
bytebasedbhubbefore 0.22.60.22.6Patch availableCNA
  • dbhub Vendorbytebase Affected before 0.22.6 Fixed in 0.22.6 Patch available CNA

Remediation

Update DBHub to version 0.22.6, which fixes the issue.

Written with Claude Haiku 5.5 from the sources below · 2026-11-06

  • Fix · CNA dbhub (bytebase) Fixed in 0.22.6

Timeline

  1. 2026-10-30 Threatist record created from CVE-2026-61789
  2. 2026-10-30 Alias added: GHSA-j55q-p8qc-f6wg
  3. 2026-11-01 Priority changed: MEDIUM → LOW
  4. 2026-11-06 CISA SSVC decision points changed
  5. 2026-11-06 Priority changed: LOW → MEDIUM

References

  • TI-2026-44186 DBHub HTTP transport DNS rebinding allows unauthenticated browser-origin SQL execution CVSS 4.0CRITICAL 9.3
  • TI-2026-44228 @bytebase/dbhub's read-only mode does not prevent database writes CVSS 3.1HIGH 7.4
  • TI-2022-13896 bytebase - Improper Authorization CVSS 3.1MEDIUM 4.3
  • TI-2022-13895 bytebase - Improper Authorization CVSS 3.1MEDIUM 4.3
  • TI-2022-26714 Authentication bypass in Bytebase GitLab self-hosted login CVSS 4.0CRITICAL 9.3
  • TI-2026-79259 Authorization bypass in Bytebase exposes other projects' task runs CVSS 4.0MEDIUM 5.3
See all 7 →

Sources