DBHub HTTP mode DNS rebinding: a malicious web page can run SQL on your database through your browser

Who is affected

DBHub, made by Bytebase, is a database MCP server (MCP is a protocol that lets AI assistants call external tools) for Postgres, MySQL, SQL Server, Oracle, MariaDB and SQLite. The npm package is @bytebase/dbhub.

The maintainer advisory lists the affected range as 0.22.4 and earlier with 0.22.5 as the patched version, matching the CVE record’s “before 0.22.5”; the version the advisory actually tested is 0.21.2.

For the attack to work, the victim must also open an attacker-controlled web page, the victim’s machine must be able to reach the DBHub HTTP server, and the attacker must control a hostname they can re-point at that server. Vendor docs also warn that HTTP mode binds to 0.0.0.0 by default, exposing it on every network interface.

How it works

Two gaps stack up here:

1. No authentication (CWE-306). In the tested version, the HTTP-mode /mcp endpoint accepted tool calls without any token (an access pass), secret or CSRF-style credential.
2. A weak origin check (CWE-346). The server tried to block browser requests from other websites, but it only confirmed that the hostnames in the Origin header (which site the request came from) and the Host header (which host it is addressed to) were the same. It did not check them against an explicit allow-list.

DNS rebinding exploits the second gap: the attacker gets the victim to open their page, then re-points their own domain at the DBHub server. The browser’s requests now carry the attacker’s domain in both Origin and Host, so they match and are treated as trusted. The vendor advisory says a malicious website can reliably call DBHub’s MCP tools from the victim’s browser this way, with no prompt injection and no AI model involved.

Impact: with the demo configuration, the demo SQLite database can be read and written; with a real database, contents can be read and listed, and possibly written, depending on DBHub’s tool permissions and the database credentials. No source claims operating-system code execution (our analysis: the known impact is running SQL and MCP tools through DBHub).

The flawed approach (conceptual illustration, not the original source code):

// Only checks that the two headers agree
if (hostname(req.headers.origin) === hostname(req.headers.host)) {
  allow(); // after DNS rebinding both are the attacker's domain, so they still match
}

A safer approach (conceptual illustration):

// Host must be on an explicit allow-list, and a valid token is required
if (allowedHosts.includes(hostname(req.headers.host)) && validToken(req)) {
  allow();
} else {
  reject(403);
}

The actual fix is PR #340, merged on 2026-06-24. According to its commit message, the new version no longer just checks that the two headers match; every request’s Host (and Origin, when present) must be on an explicit host allow-list, which includes loopback addresses by default. The “safer approach” above illustrates the principle; PR #340 says token authentication was out of scope and tracked in issue #66, and it was later added as --auth-token by PR #390, available from 1.2.0.

Timeline

Per the npm registry and GitHub advisory timestamps, the maintainer published the security advisory about 3 minutes after 0.22.5 reached npm; the CVE record was not published until 2026-09-24, three months after the advisory.

Further reading

• Scoring differences: the CNA (GitHub) gives CVSS 4.0 9.3 and GitLab gives CVSS 3.1 9.8, while the vendor advisory recommends High, possibly Critical with production or broadly privileged credentials. TheHackerWire labels it “Info”, which conflicts with every other source. NVD has not analysed it yet.
• User interaction: the CVSS vector says no user interaction (UI:N), yet the advisory’s scenario needs the victim to open an attacker’s page. We think the UI:N rating is debatable.
• PoC disagreement: the vendor advisory includes a reproducible PoC and CISA’s SSVC data marks exploitation as “poc” (also automatable, technical impact “total”); TheHackerWire says no public exploit code is confirmed.
• Exploitation: not in CISA KEV as of 2026-09-25; no source reports exploitation in the wild, and there is no evidence of zero-day use.
• No source says when the vulnerable code was introduced.
• Related weakness types: CWE-306, CWE-346.