Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. 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…
Recommended action: Upgrade to 0.22.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Setting readonly = true on the executesql tool does not make the connection read-only. The connectors are written to set PostgreSQL defaulttransactionreadonly=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 files on the server (loexport), reading arbitrary host files (pgreadfile), and remote code execution (dblink + COPY ... TO PROGRAM). The HTTP transport is unauthenticated and binds to 0.0.0.0 by default, so this is reachable by any network caller of /mcp. Details Two problems combine. 1. The database-level read-only control is dead code. PostgresConnector.connect() only enables it when config.readonly is truthy…
Recommended action: Upgrade to 0.22.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 dispatches MCP tool calls. As a result, a malicious website can deterministically invoke DBHub MCP tools from the victim's browser without prompt injection or model involvement. With the default demo configuration this can read and write the demo SQLite database; with a real configured database, the same primitive can read, enumerate, and potentially write database contents depending on DBHub's configured tool…
Recommended action: Upgrade to 0.22.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.