Dbhub
Monthly
DBHub's `readonly = true` option on its `execute_sql` tool fails to enforce read-only database access in versions prior to 0.22.6, because the connector code that would set PostgreSQL `default_transaction_read_only=on` and open SQLite in read-only mode is gated on a configuration value that is never populated. With only a first-keyword classifier left as a guard, any `SELECT` that calls a side-effecting function passes, allowing sequence tampering with an ordinary role and, with a privileged PostgreSQL role, arbitrary host file write via `lo_export`, arbitrary host file read via `pg_read_file`, and remote code execution via `dblink` combined with `COPY ... TO PROGRAM`. The HTTP transport is unauthenticated (CVSS vector PR:N) and binds to `0.0.0.0` by default, so any network caller of `/mcp` can reach the vulnerable tool; CVSS is 7.4 (AV:N/AC:H) and no public exploit code has been identified at time of analysis, though the vendor-released patch 0.22.6 resolves the issue.
Unauthenticated MCP tool invocation in DBHub versions prior to 0.22.5 allows a malicious website to reach the HTTP transport endpoint and dispatch database tool calls against connected Postgres, MySQL, SQL Server, Oracle, MariaDB, or SQLite databases, because the server's Origin-equals-Host check is defeated by DNS rebinding. The flaw applies only when DBHub is launched in the non-default HTTP transport mode (for example --transport http --port 8080); the default stdio transport is unaffected, and exploitation requires a victim's browser to load attacker-controlled content and successfully complete the rebind window, per the independent assessment. No public exploit has been identified at time of analysis, and while the CVSS 4.0 vector scores 9.3, the assessed real-world severity is lower (CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L), with impact bounded by DBHub's configured tool permissions and database credentials - read-only configurations limit exposure to disclosure.
DBHub's `readonly = true` option on its `execute_sql` tool fails to enforce read-only database access in versions prior to 0.22.6, because the connector code that would set PostgreSQL `default_transaction_read_only=on` and open SQLite in read-only mode is gated on a configuration value that is never populated. With only a first-keyword classifier left as a guard, any `SELECT` that calls a side-effecting function passes, allowing sequence tampering with an ordinary role and, with a privileged PostgreSQL role, arbitrary host file write via `lo_export`, arbitrary host file read via `pg_read_file`, and remote code execution via `dblink` combined with `COPY ... TO PROGRAM`. The HTTP transport is unauthenticated (CVSS vector PR:N) and binds to `0.0.0.0` by default, so any network caller of `/mcp` can reach the vulnerable tool; CVSS is 7.4 (AV:N/AC:H) and no public exploit code has been identified at time of analysis, though the vendor-released patch 0.22.6 resolves the issue.
Unauthenticated MCP tool invocation in DBHub versions prior to 0.22.5 allows a malicious website to reach the HTTP transport endpoint and dispatch database tool calls against connected Postgres, MySQL, SQL Server, Oracle, MariaDB, or SQLite databases, because the server's Origin-equals-Host check is defeated by DNS rebinding. The flaw applies only when DBHub is launched in the non-default HTTP transport mode (for example --transport http --port 8080); the default stdio transport is unaffected, and exploitation requires a victim's browser to load attacker-controlled content and successfully complete the rebind window, per the independent assessment. No public exploit has been identified at time of analysis, and while the CVSS 4.0 vector scores 9.3, the assessed real-world severity is lower (CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L), with impact bounded by DBHub's configured tool permissions and database credentials - read-only configurations limit exposure to disclosure.