3vulnerabilities
- Critical1 (33.3%)
- High1 (33.3%)
- Medium0 (0.0%)
- Moderate1 (33.3%)
- Low0 (0.0%)
bytebase-dbhub
Ecosystem: npm
Downloads: 152.31 K
- 1CriticalAffects 1 version
- 1HighAffects 1 version
- 0MediumAffects 0 versions
- 1ModerateAffects 1 version
- 0LowAffects 0 versions
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 1 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 1
- Low: 0
- 2 vulnerabilities
- Critical: 1
- High: 1
- Medium: 0
- Moderate: 0
- Low: 0
Vulnerabilities (3)
Known vulnerabilities affecting bytebase-dbhub, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-j656-3hf2-fvjc | Moderate | DBHub: MySQL and MariaDB comment interpretation bypasses read-only SQL validationThe 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 "--" co |
| GitHub (opens in a new tab) | |
| GHSA-fm8p-53ww-hf6w | Critical | DBHub HTTP transport DNS rebinding allows unauthenticated browser-origin SQL execution### Summary DBHub `0.21.2` exposes an unauthenticated HTTP MCP endpoint when started with the documented HTTP transport mode, for example `--transport http --port 8080`. The HTTP server attempts to protect browser-origin access by checking whether the `Origin` hostname equals the `Host` hostname, then reflecting the validated `Origin` into `Access-Control-Allow-Origin`. This does not stop DNS rebinding. After an attacker-controlled hostname rebinds to a victim-accessible DBHub HTTP server, both `Origin` and `Host` can contain the attacker-controlled hostname, so DBHub accepts the request and |
| GitHub (opens in a new tab) | |
| GHSA-mwwr-p57h-56pf | High | @bytebase/dbhub's read-only mode does not prevent database writes### Summary Setting `readonly = true` on the `execute_sql` tool does not make the connection read-only. The connectors are written to set PostgreSQL `default_transaction_read_only=on` (and open SQLite in `readOnly` mode), but that code is gated on a config value that is never populated, so it never runs. The only thing left enforcing read-only is a classifier that inspects the first keyword of each statement. Any `SELECT` that writes or has side effects through a function call passes it. With an ordinary role this allows sequence tampering; with a privileged role it allows writing arbitrary |
| GitHub (opens in a new tab) |
- GHSA-j656-3hf2-fvjcModerateDBHub: MySQL and MariaDB comment interpretation bypasses read-only SQL validation
< 0.22.6
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 "--" co
CVE: CVE-2026-61789
- GHSA-fm8p-53ww-hf6wCriticalDBHub HTTP transport DNS rebinding allows unauthenticated browser-origin SQL execution
< 0.22.5
### Summary DBHub `0.21.2` exposes an unauthenticated HTTP MCP endpoint when started with the documented HTTP transport mode, for example `--transport http --port 8080`. The HTTP server attempts to protect browser-origin access by checking whether the `Origin` hostname equals the `Host` hostname, then reflecting the validated `Origin` into `Access-Control-Allow-Origin`. This does not stop DNS rebinding. After an attacker-controlled hostname rebinds to a victim-accessible DBHub HTTP server, both `Origin` and `Host` can contain the attacker-controlled hostname, so DBHub accepts the request and
CVE: CVE-2026-61742
- GHSA-mwwr-p57h-56pfHigh@bytebase/dbhub's read-only mode does not prevent database writes
< 0.22.6
### Summary Setting `readonly = true` on the `execute_sql` tool does not make the connection read-only. The connectors are written to set PostgreSQL `default_transaction_read_only=on` (and open SQLite in `readOnly` mode), but that code is gated on a config value that is never populated, so it never runs. The only thing left enforcing read-only is a classifier that inspects the first keyword of each statement. Any `SELECT` that writes or has side effects through a function call passes it. With an ordinary role this allows sequence tampering; with a privileged role it allows writing arbitrary
CVE: CVE-2026-61788