MCP servers represent an attack surface that is both new and very familiar. MCP servers exist because of the recent rise of AI, but they are ultimately just another service connected to a datastore on one end and the internet on the other. When configured without authentication, they expose whatever data they are connected to. In the case of DBHub, an MCP interface for interacting with database, that can include organizations' information on customers and employees.

One such case illustrates the potential impact of such exposures. Square Yards, “India’s largest real estate platform,” left an unauthenticated DBHub instance exposed to the internet, in turn providing access to a massive collection of database tables with millions of records of personal information for customers and employees.

This leak is not just consequential for the individuals affected; it is the largest exposure of sensitive personal data attributed to an unauthenticated MCP server to date, a landmark in the progression from theoretical to actual AI risks.

The Model Context Protocol (MCP) is an open standard that defines how AI assistants connect to external data sources and tools. The design goal is interoperability: rather than every AI vendor building proprietary integrations for databases, file systems, and APIs, MCP provides a common interface that any compliant AI client can use. DBHub is one such server that allows AI assistants to browse and query connected databases. When deployed safely, DBHub's MCP server is accessible only to authorized clients.

The security failure mode is straightforward: if the MCP server is deployed on a cloud VM and the port is reachable from the public internet without requiring authentication, anyone can issue queries against the underlying database. This is not a vulnerability in MCP or DBHub specifically; it is a configuration error, the same category of mistake that has exposed S3 buckets and Elasticsearch clusters before it.

UpGuard researchers identified a publicly accessible DBHub MCP server on May 28, 2026. After determining that data of some sensitive is was present, UpGuard notified Square Yards on May 29, 2026. The data was secured soon after. They never responded to UpGuard. 

The database returned schema and data for 2,178 tables totalling over 650 GB, covering the company's full operational scope: CRM and lead management, HR and payroll, property transaction processing, KYC document collection, broker and partner management, and financial payout processing. Data samples of the oldest and most recent records indicated it was being updated at the time of discovery and held data stretching back several years.

To determine what data was actually present, UpGuard sampled the oldest and newest records. For data points mentioned below, not all data points were present for all records, but at least some of the sampled records had valid values for each listed field.

The largest collections of records were leads with contact information: names associated with a phone number or email address to reach them. Across the various lead tables there were millions of identities.

Individuals who progressed further with their inquiry–either offering a property for rent or paying to rent a property–provided more personal information. In order to perform KYC and credit checks this data included unique identifiers like PAN, Aadhar, or passport numbers. Further personal information used to establish one’s creditworthiness present in some collections included the identities of marriage partners, employer, and income.

A table “users” included over 124k rows. In the data sample, entries all had the UserType set to Employee. These rows included the user’s name, device type, API access token, and hashed password.

The collection also included more personal data related to employees. The “employee” table had detailed records for 125k rows: name, email address, father’s name, current address, employee id, blood type, “access number,” and a “WhatsUp” number that is likely a phone number for the Indian country code +91. In this table the bank account and PAN numbers were hashed and thus not readable as plaintext. 

However, in the similarly-sized table “candidate_joining_information” many of the same data points were present, along with aadharCardNo, panCardNumber and bankAccountNumber in plaintext. In some but not all cases these entries also included UAN and passport numbers. 

Other tables included additional information for candidates prior to joining and family members of employees. These included name, date of birth, and Aadhar numbers in some but not all cases.

Other tables documented employee commission payouts and their feedback, both positive and negative, about managers at the company. The commission payout objects recorded the recipients’ name, bank account number PAN number, and the payout amount.

The combination of data categories exposed here creates layered risks that go beyond any single field.The presence of Aadhar number, passport number, PAN number, and/or bank account details provides the information needed for identify theft activities like opening financial accounts, applying for credit, or conducting unauthorized transactions. 

Records that combine a person's name, mobile number, email, employer, property purchase details, and financial situation create highly credible targeting material for fraud. Someone aware of a target's CIBIL score, declared salary, and the property they are in the process of buying is well-positioned to craft a convincing impersonation. 

The optimal solution is to secure MCP deployments with best practices for defense in depth. Treat MCP servers as internet-facing services even when deployed internally. Apply the same hardening standards you would to any API endpoint. 

Among those hardening standards is authentication. MCP supports bearer token authentication. No MCP server should be reachable without a valid credential, regardless of whether it is considered "internal." 

On top of that, apply network layer controls so that is it not internet-facing. If an MCP server only needs to be reachable by a specific application or service, enforce that at the network layer — do not rely solely on application authentication. By applying controls at multiple layers, MCP deployments can remain secure even if one lapses temporarily. 

Configuration errors do happen; this is why defense in depth is so important, as is having detective controls to know when an asset has slipped out of compliance with your security standards. The configuration error here — an MCP server deployed without authentication on a public IP — is detectable from outside the organisation before any data is exfiltrated, provided the organisation is monitoring its own external footprint. 

The Square Yards exposure is a reminder that new integration layers introduce new attack surfaces. MCP servers are genuinely useful — they are how AI assistants get access to the data that makes them helpful — but that utility comes with a responsibility to secure the access point as carefully as the underlying data store. The controls required are not novel: authentication, network segmentation, least privilege, logging. What is new is the need to apply them to a layer that many security teams have not yet added to their mental model of what needs protecting.