Bytebase - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/vendors/bytebase/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 24 Sep 2026 20:03:55 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgDNS Rebinding Vulnerability in DBHub HTTP Transporthttps://feed.craftedsignal.io/briefs/2026-09-dbhub-dns-rebind/Thu, 24 Sep 2026 20:03:55 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-dbhub-dns-rebind/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.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

  1. Attacker registers a domain (e.g., dbhub-rebind.example) and configures an authoritative DNS server to provide a short Time-To-Live (TTL).
  2. Victim is lured to an attacker-controlled website hosted at the attacker's domain, which resolves initially to an attacker-controlled web server.
  3. Attacker's web server delivers malicious JavaScript to the victim's browser.
  4. Attacker updates the DNS record for their domain to point to the victim's internal loopback or local network IP where DBHub is running.
  5. The malicious JavaScript triggers a cross-origin HTTP request to the DBHub server at the attacker's domain (e.g., dbhub-rebind.example:8080).
  6. DBHub's middleware extracts the Host and Origin headers, finds they match the attacker's domain, and validates the request as authorized.
  7. DBHub dispatches the JSON-RPC command, executing arbitrary SQL queries on the connected database.
  8. 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 http configuration.
  • Bind DBHub instances to 127.0.0.1 rather than 0.0.0.0 to 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 /mcp requests, independent of the HTTP transport's origin validation.
  • Restrict the execute_sql tool permissions to read-only for production database connections where possible.
]]>highthreatweb-vulnerabilitydns-rebindingdatabase-securityvulnerabilityrce