Open House: How an Unauthenticated MCP Server Exposed India’s Largest Real Estate Platform

0
48
Open House: How an Unauthenticated MCP Server Exposed India's Largest Real Estate Platform
Open House: How an Unauthenticated MCP Server Exposed India's Largest Real Estate Platform

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.

Background: DBHub and the Model Context Protocol

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.

Detection

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.

Partial listing of tables returned from DBHub interface
Partial listing of tables returned from DBHub interface

Impact and analysis

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.

Lead contact information 

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.

Table Rows Exposed Fields
contacts 15,630,608 First name, last name, email and/or phone number
lead20211101 5,537,150 Name, email and/or phone number

 

Unique national identifiers used for KYC

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.

Table Rows Exposed Fields
channelpartner 438,138 Name, phone, email, PAN number
brokerfeedback 433,987 Name, phone, PAN number
CIBILRequest 114,132 Name, phone, email, DOB, CIBIL credit score
serviceAgreementOwners 16,734 Owner PAN, owner Aadhar number
applicationform 5,953 PAN number, passport number
panaadharlink 31,422 PAN-Aadhar linkage status

 

Employee data

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.

Table Rows Exposed Fields
employee 125,135 Full name, personal email, official email, DOB, gender, Aadhar number (plaintext), name as on PAN, name as on Aadhar, passport number
candidate_joining_information 125,200 Aadhar number, PAN number, name as on PAN, name as on Aadhar, passport number, passport expiry, bank name, bank account number, father’s name, spouse name, emergency contact name, relationship to emergency contact
candidateprofile 185,768 Name, email address, phone, salary expectation, Aadhar number, date of birth
employeedependantinfo 21,572 Aadhar numbers of employee dependants
users 124,659 Name, API token, hashed password

 

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.

Table Rows Exposed Fields
Payout_request 584,362 PAN number, bank account number, bank name, IFSC code, payout amount
Leaderfeedback 176 Qualitative notes on leader performance

 

Risks from exposed data

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.

Recommendations

Securing MCP Server Deployments

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.

Attack Surface Visibility

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.

Conclusion

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.

– Greg Pollock from UpGuard

Also read: Viksit Workforce for a Viksit Bharat

Do Follow: The Mainstream LinkedIn | The Mainstream Facebook | The Mainstream Youtube | The Mainstream Twitter

About us:

The Mainstream is a premier platform delivering the latest updates and informed perspectives across the technology business and cyber landscape. Built on research-driven, thought leadership and original intellectual property, The Mainstream also curates summits & conferences that convene decision makers to explore how technology reshapes industries and leadership. With a growing presence in India and globally across the Middle East, Africa, ASEAN, the USA, the UK and Australia, The Mainstream carries a vision to bring the latest happenings and insights to 8.2 billion people and to place technology at the centre of conversation for leaders navigating the future.