CVE-2026-61742: 
JavaScript 취약성 분석 및 완화

CVE-2026-61742 is a DNS rebinding vulnerability in DBHub, a database MCP (Model Context Protocol) server supporting Postgres, MySQL, SQL Server, Oracle, MariaDB, and SQLite. When DBHub is started in HTTP transport mode (--transport http), its origin validation logic checks only that the Origin hostname equals the Host hostname — a check that is trivially bypassed via DNS rebinding — allowing unauthenticated browser-origin SQL execution against the connected database. All versions of @bytebase/dbhub up to and including 0.22.4 are affected; version 0.22.5 contains the fix. The vulnerability carries a CVSS v4.0 base score of 9.3 (Critical) (GitHub Advisory). It was originally published on June 24, 2026, and added to the GitHub Advisory Database on September 24, 2026 (GitHub Advisory).

The root cause is a flawed CORS/origin validation implementation in src/server.ts (CWE-346: Origin Validation Error) combined with a complete absence of authentication on the /mcp JSON-RPC endpoint (CWE-306: Missing Authentication for Critical Function). The middleware extracts the hostname from both the Host and Origin request headers and rejects requests only when they differ — it does not validate against an explicit allowlist of trusted hosts or origins. In a DNS rebinding attack, the attacker controls a hostname (e.g., dbhub-rebind.example) that initially resolves to the attacker's server; after serving malicious JavaScript to the victim's browser, the attacker rebinds the DNS record to the victim-accessible DBHub IP. Subsequent browser requests carry both Host: dbhub-rebind.example:<port> and Origin: http://dbhub-rebind.example, which pass the equality check, causing DBHub to reflect the attacker-controlled origin into Access-Control-Allow-Origin and dispatch MCP tool calls without any authentication token or CSRF protection (GitHub Advisory, Security Advisory).

Successful exploitation allows an attacker to invoke any DBHub MCP tool — including execute_sql — from the victim's browser without authentication, enabling full read and write access to the connected database. An attacker can enumerate database schemas and tables, extract sensitive data, and execute write queries (when execute_sql is not configured as read-only), with results readable by the attacker's JavaScript via the reflected CORS header. The severity is rated High for developer workstations and internal deployments, and can escalate to Critical when DBHub is connected to production databases with broad credentials; the attack requires no prompt injection, no compromised AI client, and no prior internal network access — only that the victim visits a malicious web page while DBHub HTTP transport is running (GitHub Advisory).

A complete, runnable Node.js proof-of-concept (dbhub-dns-rebinding-poc.mjs) is publicly available in the GitHub security advisory; it spawns DBHub in demo HTTP mode, sends crafted requests with attacker-controlled Host and Origin headers, and demonstrates successful SQL read and write operations (Security Advisory). The NVD SSVC assessment classifies exploitation as "poc" with "automatable: yes" and "technicalImpact: total." The EPSS score is approximately 0.20%, and there is no evidence of in-the-wild exploitation or CISA KEV catalog inclusion at this time (GitHub Advisory). No threat actor attribution has been reported.

1. Setup attacker infrastructure: Register an attacker-controlled domain (e.g., dbhub-rebind.example) and configure a DNS server with a very short TTL (e.g., 1 second) that initially resolves to the attacker's web server IP.
2. Serve malicious JavaScript: Host a web page at http://dbhub-rebind.example:<port> that loads in the victim's browser. The page includes JavaScript that will later send requests to DBHub.
3. Initiate DNS rebinding: After the victim's browser loads the page and caches the initial DNS resolution, the attacker changes the DNS record to resolve dbhub-rebind.example to the victim-accessible DBHub server IP (e.g., 127.0.0.1 for localhost, or an internal network IP).
4. Wait for DNS TTL expiry: The attacker waits for the browser's DNS cache to expire (aided by the short TTL), after which subsequent requests to dbhub-rebind.example resolve to the DBHub server.
5. Send crafted MCP request: The attacker's JavaScript sends an HTTP POST to /mcp with headers Host: dbhub-rebind.example:<port> and Origin: http://dbhub-rebind.example. Because both hostnames match, DBHub's middleware accepts the request and reflects the origin into Access-Control-Allow-Origin.
6. Invoke tools/list: Send a JSON-RPC request {"jsonrpc":"2.0","id":"list","method":"tools/list","params":{}} to enumerate available MCP tools.
7. Execute SQL read: Send a tools/call request with {"name":"execute_sql","arguments":{"sql":"SELECT * FROM sensitive_table"}} to read database contents.
8. Execute SQL write (if permitted): Send a tools/call request with a write SQL payload (e.g., INSERT, UPDATE, DROP) to modify database records.
9. Exfiltrate results: The browser JavaScript reads the JSON-RPC HTTP 200 response (permitted by the reflected CORS header) and sends the extracted data to the attacker's server via fetch() or XMLHttpRequest (Security Advisory).

• Network: Unexpected HTTP POST requests to /mcp on the DBHub port originating from browser user agents; requests where the Host header contains an external or unfamiliar hostname (not localhost or the configured deployment hostname) while the server is bound to a local/internal address; outbound HTTP requests from the victim's browser to an external domain immediately after DBHub responses (data exfiltration).
• Logs: DBHub HTTP access logs showing POST requests to /mcp with Host and Origin headers containing attacker-controlled hostnames; Access-Control-Allow-Origin response headers reflecting non-localhost origins in server logs; repeated tools/call invocations with execute_sql and unusual or enumeration-style SQL queries.
• Database: Unexpected table creation (e.g., tables named dns_rebind_probe or similar canary names from PoC); unusual SELECT, INSERT, or schema enumeration queries in database audit logs not attributable to legitimate application activity; new records inserted by the DBHub service account outside of normal application workflows (Security Advisory).

Upgrade @bytebase/dbhub to version 0.22.5 or later, which fixes the DNS rebinding vulnerability (GitHub Advisory). If an immediate upgrade is not possible, apply the following workarounds in order of priority:

• Restrict network binding: Ensure DBHub HTTP transport binds only to 127.0.0.1 (loopback) rather than 0.0.0.0, limiting exposure to the local machine.
• Firewall rules: Block external access to the DBHub HTTP port using host-based or network firewall rules so only trusted clients can reach the endpoint.
• Disable HTTP transport: Switch to the default stdio transport mode, which is not affected by this browser-origin attack vector.
• Limit database permissions: Configure DBHub with least-privilege database credentials and set execute_sql to read-only mode where write access is not required (Security Advisory).

The advisory was published by tianzhou (a Bytebase maintainer) on June 24, 2026, and credited researchers junbyjun1238 and avishaigonen-pluto as finders (Security Advisory). The vulnerability received coverage from automated threat intelligence aggregators including VulDB, CVEFeed, and Offseq Radar shortly after NVD publication. A Mastodon post from @stemshop noted the advisory. No significant vendor statements beyond the official advisory or notable independent researcher commentary have been identified at this time.