DBHub EUVD-2026-86326

Requires DBHub to be run with the HTTP transport, which is unauthenticated and binds to 0.0.0.0 by default, exposing /mcp to any network caller. Basic exploitation (bypassing the readonly=true setting on execute_sql via a SELECT that calls a side-effecting function) works against any connected database because the read-only connector enforcement is dead code gated on an unpopulated config value, leaving only a first-keyword classifier. The high-impact outcomes are conditional on the database connection role: an ordinary role permits only limited sequence tampering, whereas a privileged PostgreSQL role is required for arbitrary host file write (lo_export), arbitrary host file read (pg_read_file), and remote code execution (dblink + COPY ... TO PROGRAM). Limiting factors: the worst impacts depend on a privileged DB role, and exposure depends on the operator choosing the HTTP transport rather than stdio; all versions before 0.22.6 are affected.

This is a genuine high-priority issue for anyone running DBHub's HTTP transport, though the raw CVSS 7.4 slightly understates the worst case while overstating the common case. The NVD vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N marks it network-reachable and unauthenticated (PR:N), consistent with the description's statement that the HTTP transport is unauthenticated and binds 0.0.0.0 by default, making /mcp reachable by any network caller. AC:H is defensible because the severe impacts (arbitrary host file read via pg_read_file, arbitrary file write via lo_export, and RCE via dblink + COPY ... TO PROGRAM) require the DBHub connection to run under a privileged database role; with only an ordinary role, impact drops to limited sequence tampering (I:L). I dispute A:N - COPY ... TO PROGRAM yields command execution on the database host, which should carry availability impact (A:H), and one could argue S:C since the executing/impacted component (the DB server host) differs from the vulnerable MCP component. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active exploitation; this is a real, remotely-triggerable design flaw (broken read-only enforcement, CWE-184) rather than a confirmed campaign. Priority is driven by trivial network reachability of the default HTTP binding plus a full RCE path when a privileged DB role is in use - a common real-world configuration for a database tool.

An attacker on the same network (or the internet, where the 0.0.0.0-bound HTTP transport is exposed) sends an MCP request to the unauthenticated /mcp endpoint calling execute_sql, which the operator believes is locked to read-only. They submit a SELECT that invokes a side-effecting function - e.g. dblink() with COPY ... TO PROGRAM - which the first-keyword classifier passes as 'read-only,' achieving arbitrary command execution on the database host when DBHub connects with a privileged role. No public exploit code was identified at time of analysis, but the technique is described concretely in the advisory.