DNS Rebinding Vulnerability in DBHub HTTP Transport
DBHub 0.21.2 fails to securely validate hostnames in its HTTP transport mode, allowing attackers to use DNS rebinding to execute arbitrary SQL queries via a victim's browser.
What's new
- 1. added coverage for dbhub (< 0.22.6) Sep 24, 20:05 via ghsa
DBHub version 0.21.2, when deployed using the --transport http configuration, contains a critical flaw in its DNS rebinding protection mechanism. The server attempts to prevent unauthorized cross-origin requests by validating that the Origin header matches the Host header. However, this check is insufficient as it does not enforce a whitelist of trusted hostnames. An attacker can perform a DNS rebinding attack to cause a victim's browser to resolve an attacker-controlled domain to the IP address where DBHub is running. Because both the Host and Origin headers in the rebind request will match the attacker-controlled hostname, the server erroneously trusts the request. This allows an attacker to interact with the /mcp endpoint and dispatch JSON-RPC tool calls, such as execute_sql, directly from the victim's browser. This vulnerability bypasses traditional local network boundaries and does not require authentication, potentially exposing sensitive database contents to exfiltration.
Attack Chain
- Attacker registers a domain (e.g., dbhub-rebind.example) and configures an authoritative DNS server to provide a short Time-To-Live (TTL).
- Victim is lured to an attacker-controlled website hosted at the attacker's domain, which resolves initially to an attacker-controlled web server.
- Attacker's web server delivers malicious JavaScript to the victim's browser.
- Attacker updates the DNS record for their domain to point to the victim's internal loopback or local network IP where DBHub is running.
- The malicious JavaScript triggers a cross-origin HTTP request to the DBHub server at the attacker's domain (e.g., dbhub-rebind.example:8080).
- DBHub's middleware extracts the
HostandOriginheaders, finds they match the attacker's domain, and validates the request as authorized. - DBHub dispatches the JSON-RPC command, executing arbitrary SQL queries on the connected database.
- Attacker receives query results from the JSON-RPC response via the browser's ability to read the reflected origin, completing the exfiltration.
Impact
Successful exploitation allows unauthenticated execution of SQL queries on databases connected to a DBHub instance. Depending on the server's configured permissions, an attacker can enumerate schemas, read sensitive database contents, and perform write operations. As the interaction occurs through the victim's browser, the attacker can exfiltrate data without needing direct network access to the target machine or bypassing local firewall rules, significantly impacting organizations using DBHub for local database management.
Recommendation
Prioritized actions for security teams:
- Immediately audit all DBHub deployments to identify instances using the
--transport httpconfiguration. - Bind DBHub instances to
127.0.0.1rather than0.0.0.0to restrict network accessibility. - Implement an explicit allowed-hosts and allowed-origins policy in local infrastructure proxies if DBHub must be exposed.
- Require a static authentication token for all
/mcprequests, independent of the HTTP transport's origin validation. - Restrict the
execute_sqltool permissions to read-only for production database connections where possible.
Immediate actions
Audit environments for DBHub instances running with --transport http
Mitigations
Bind DBHub HTTP transport to loopback interface (127.0.0.1) or disable if not required
DNS rebinding via local network access