.jpeg){kind=small}
Organizations keep their databases behind firewalls for a reason: the data inside is the data they can least afford to lose. A new class of AI middleware–Model Context Protocol (MCP) servers–exists specifically to reach into those protected systems on an AI model's behalf. One of them, DBHub, connects directly to SQL databases. DBHub thus enables a user to ask AI a question and have it execute an appropriately formed SQL query to get the answer–a natural language interface for company databases that can be very helpful until that interface is exposed to the public.
DBHub’s intrinsic connection to databases makes their exposure a useful bellwether for MCP exposures becoming meaningful in severity and scale. Most internet-accessible MCP servers wrap public APIs, providing a better interface for AI agents but the same risk profile. DBHub, on the other hand, connects to the one place organizations work hardest to keep private. As noted in a Github issue a year ago, the HTTP interface lacks authentication, making an accessible DBHub instance an accessible database.
UpGuard scanned the public internet for DBHub and found 31 instances already exposed, most of them able to run live SQL against real production data, several holding PII and medical records. The individual misconfigurations are familiar. What's new is the surface: MCP is being adopted quickly, it points at high-value data by design, and the early evidence suggests that MCP specifically designed for use cases like database querying will become a real vector for data exposure.
What DBHub is, and how it exposes data
The MCP project describes the protocol as "a USB-C port for AI applications" — a single standardized way to connect AI tools to external systems, replacing the bespoke, fragile, one-off integrations that each new data source used to require. One protocol, many connections.
Previously, every time an AI model had to connect to a new tool or data source, custom integration code was required: one integration for GitHub, another for Slack, and yet another for local databases. Each one is bespoke, fragile, and requires ongoing maintenance. MCP addresses this with a single standardized connection layer for AI agents and external tools: one protocol with infinite connections.
Essentially, these MCP servers act as wrappers for APIs that are already public. While they do have their own issues, including a sophisticated attack using MCP servers as an entrypoint, they are not prone to expose data in the same way as DBHub.
DBHub
DBHub acts as a specific kind of MCP server that provides AI with access to databases to simplify user queries. Rather than giving every user the connection string to a database (or databases), DBHub acts a hub where users send questions and it returns answers. DBHub supports MySQL, Microsoft’s SQL Server, PostgreSQL, SQLite and MariaDB. DBHub allows AI agents or platforms to run SQL commands against connected databases.
To its credit, DBHub ships with guardrails — read-only mode, row limiting, query timeouts — and supports SSH tunneling with SSL/TLS encryption. None of that helps when the server itself is placed on the public internet. The databases and the AI can stay private; if the DBHub instance in the middle has a public IP and an open MCP port — whether deliberately exposed through the firewall or simply never put behind one — the data is reachable.
When the DBHub server is misconfigured and faces the public internet, the data in the database becomes at risk, even if both the database server and the AI are private. This configuration, core to how MCP servers in general operate, is how the DBHub servers discovered by UpGuard researchers came to expose their data. They were given a public IP address and the MCP port in use was opened through the firewall (or it simply wasn’t behind one to begin with.)
The execute_sql tool is a plain text box and a Run button.
From here, accessing the table structure and exfiltrating the data is just a matter of simple queries. Perhaps operators are not wholly aware that in addition to providing access to AI tools, DBHub has a web-interface for human interaction. Putting the DBHub server on the internet exposes it.
The web interface provides one other feature when browsing to it, a log of recent requests, showing (by default) the previous 100 queries run against the DBHub system. This provides further intelligence and context for how the operator uses the database and what valuable data might be present.
What’s already exposed
Of the 31 discovered servers, 25 (81%) were verified to have execute_sql permissions active, meaning SQL queries and commands could be given to the database via the exposed DBHub instance. Of these 25, UpGuard researchers were able to sample data on 22 systems, revealing a wide range of industries and uses for the DBHub servers. Also widely varied were the DBHub versions of the discovered systems, which ranged from 0.15.0 to 0.21.2. Older versions of DBHub have known security issues and provide opportunity for even further compromise. UpGuard notified organizations with personally identifiable information present.
In addition to sensitive data being discovered, plain text API credentials were also present on two systems, the misuse of which could allow threat actors to modify or compromise further systems and data.
The takeaway
DBHub is the clearest early example of where MCP exposure leads: an AI-enabling layer that connects, by design, to the data organizations most want to protect, already sitting open on the public internet in real deployments. The number of MCP servers in use will rise sharply as these tools are adopted, and each new one is a potential door to meaningful data.
New functionality has always come with new gaps. Whether a gap stays a misconfiguration or becomes an incident depends on how quickly it's detected and closed — and how well security practice adapts to the new vector. Rushing into AI integration without planning for that will only get more dangerous as the technology becomes more common and more powerful.
