CVE-2026-61742: DNS Rebinding to Unauthenticated SQL Execution in DBHub

DBHub operates as a Model Context Protocol (MCP) server designed to interface artificial intelligence models and external clients with relational databases including PostgreSQL, MySQL, SQL Server, Oracle, MariaDB, and SQLite. When initialized in the documented HTTP transport mode, DBHub exposes an unauthenticated HTTP service listening on a configured port (such as 8080). This architecture opens up a critical attack surface, as any local or network client can dispatch commands to the /mcp endpoint without verifying credentials.\n\nTo defend against malicious cross-origin interactions in web browsers, the developers implemented a security middleware intended to enforce Same-Origin policies. This middleware verifies whether the HTTP request's Origin header matches the Host header. The core design assumption was that mismatched headers would block unauthorized cross-origin requests originating from external malicious websites.\n\nHowever, this defense mechanism relies on relative comparisons of client-controlled headers rather than absolute host validation. Because the browser sets the Host and Origin headers based on the current domain it believes it is interacting with, a DNS rebinding attack can completely circumvent this verification step. The vulnerability, tracked as CVE-2026-61742, allows unauthenticated remote attackers to execute arbitrary SQL commands against databases connected to the DBHub server.

The root cause of CVE-2026-61742 resides in the origin-to-host relative validation logic within src/server.ts. When a standard browser makes a cross-origin request to a different domain, the browser enforces the Same-Origin Policy (SOP). If a script on http://malicious.com attempts to query http://localhost:8080, the browser automatically sets the Host header to localhost:8080 and the Origin header to http://malicious.com. The server's relative validation detects the mismatch and correctly issues an HTTP 403 Forbidden response.\n\nIn a DNS rebinding scenario, the attacker circumvents this browser mechanism by controlling both the DNS resolution of a domain and the serving infrastructure. The attacker registers a domain, such as rebind.attacker.com, with a low Time-To-Live (TTL) value. When the victim visits the attacker's site, the domain initially resolves to the attacker's malicious web server, which loads a script into the victim's browser context.\n\nOnce the script is running, the attacker's DNS server changes the A record for rebind.attacker.com to point to the loopback address 127.0.0.1. The script then initiates an HTTP POST request to http://rebind.attacker.com:8080/mcp. Because the browser associates the request with the origin http://rebind.attacker.com:8080, it sets both the Host header to rebind.attacker.com:8080 and the Origin header to http://rebind.attacker.com. When the request arrives at the local DBHub server, the middleware checks if rebind.attacker.com matches rebind.attacker.com. Because they are identical, the validation passes, allowing access to the MCP endpoint.\n\nmermaid\ngraph LR\n A["Attacker Site"] -->|"1. Load malicious JS"| B["Victim Browser"]\n A -.->|"2. Rebind DNS to 127.0.0.1"| C["DNS Server"]\n B -->|"3. POST /mcp (Host/Origin: rebind.com)"| D["Local DBHub (127.0.0.1)"]\n D -->|"4. Execute arbitrary SQL"| E["Target Database"]\n

An investigation of the vulnerable codebase in DBHub version 0.21.2 reveals how the validation check was structured in src/server.ts. The implementation extracted the Origin and Host headers and compared them directly after dropping port information. If they matched, the server dynamically reflected the untrusted origin back into the response's Access-Control-Allow-Origin and enabled Access-Control-Allow-Credentials. This dynamic reflection allowed the attacker's client-side script to read the response payload, facilitating data exfiltration.\n\ntypescript\n// Vulnerable logic in src/server.ts (v0.21.2)\nconst origin = req.headers.origin;\nif (origin) {\n const host = (req.headers.host ?? '').split(':')[0].toLowerCase();\n try {\n const originHost = new URL(origin).hostname.toLowerCase();\n if (originHost !== host) {\n return res.status(403).json({\n error: 'Forbidden',\n message: 'Origin does not match Host header (DNS rebinding protection)',\n });\n }\n } catch {\n return res.status(400).json({ error: 'Bad Request', message: 'Malformed Origin header' });\n }\n}\n\nres.header('Access-Control-Allow-Origin', origin || 'http://localhost');\nres.header('Access-Control-Allow-Credentials', 'true');\n\n\nThe patch implemented in version 0.22.5 (commit 5bf5c3242a22e94871dfdf53913c84a5025b7381) completely restructures this validation. Instead of comparing two client-supplied strings for relative equality, the updated code maintains a strict allowlist of authorized hostnames. The server now validates both the Host header and the Origin header against an absolute set of allowed hosts (allowedHosts), which defaults to loopback addresses like localhost and 127.0.0.1 unless explicitly overridden using --allowed-hosts. This ensures that an arbitrary external domain name, even if consistent across both headers, will be rejected immediately.\n\nThis patch is complete as it eliminates the reliance on relative comparisons and moves to an explicit allowlist design. Even if an attacker successfully rebinds a domain name to 127.0.0.1, the server will reject the incoming request because the Host header will contain the rebound domain name, which is not present in the default loopback allowlist.

Exploitation of CVE-2026-61742 requires three core prerequisites: the DBHub instance must be running in HTTP transport mode, the attacker must have a vector to execute JavaScript in the victim's browser (such as a malicious webpage or compromised ad), and the victim's browser must be able to reach the DBHub service on the local network or loopback interface. No prior authentication, API keys, or active sessions are needed to interact with the target /mcp endpoint.\n\nWhen the victim visits the malicious site, the script executes a classic DNS rebinding sequence, waiting for the DNS cache of the browser or OS to expire so that the domain points to 127.0.0.1. Once the rebinding is successful, the script sends an HTTP POST request containing a standard JSON-RPC payload to /mcp. This request requests DBHub to list its connected databases or run arbitrary SQL commands.\n\nBecause DBHub's vulnerable middleware validates the match and returns the Access-Control-Allow-Origin header matching the rebound domain, the browser permits the script to read the database response. This allows the attacker to systematically exfiltrate database schemas, execute read queries to extract data, or run write queries to manipulate the database. The entire process occurs silently in the background without any visible indications to the user.

The security impact of CVE-2026-61742 is exceptionally high, as reflected by its CVSS v4.0 score of 9.3. An attacker who successfully exploits this vulnerability gains full, unauthenticated control over any database connected to the compromised DBHub server. This includes the ability to execute arbitrary SQL statements under the privileges of the configured database user, allowing for read, write, and administrative actions.\n\nIn development environments, DBHub is frequently configured with elevated database privileges to allow developers to run migrations and view system schemas. Exploitation under these circumstances can lead to the deletion of tables, modification of critical application records, or the exfiltration of sensitive production data mirrors. Additionally, if the database engine supports functions that interact with the host system (such as PostgreSQL's PROGRAM COPY command or SQLite's loadable extensions), this vulnerability could be chained to achieve arbitrary remote code execution (RCE) on the developer's workstation.\n\nFurthermore, because DBHub acts as an MCP server, compromise of this service breaks the integrity of AI-assisted development systems. Malicious actors could inject manipulated database schemas or poisoned data into the context window of local LLMs, potentially leading to the generation of insecure code or backdoored database migrations.

Remediating CVE-2026-61742 requires upgrading the @bytebase/dbhub dependency to version 0.22.5 or later. The update implements robust host-header validation that enforces a default allowlist of loopback addresses, preventing rebinding attacks. If immediate upgrading is not feasible, operators must implement strict mitigation strategies to secure the endpoint.\n\nOne effective workaround is to restrict the DBHub service binding. Instead of binding to all interfaces (0.0.0.0), ensure the server binds strictly to the loopback interface (127.0.0.1). While this does not prevent local DNS rebinding from a browser on the same host, it reduces the network-level attack surface. Additionally, developers can configure local firewall rules to block unauthorized cross-origin requests or run DBHub inside a containerized environment with isolated network namespaces.\n\nFor enterprise deployments where DBHub must be accessed over a network, it should never be exposed directly to the internet in HTTP mode. Administrators should deploy a reverse proxy, such as Nginx or Caddy, to handle SSL termination and enforce strong access controls, including Basic Authentication, IP white-listing, or Client Certificate authentication (mTLS). The proxy should also explicitly validate the incoming Host header and discard any requests bearing unexpected hostnames.