# Your Next Door Neighbor Could Be a Data Breach: How a Blackstone Real Estate Portal Leaked SSNs
In the high-stakes world of New York City real estate, finding an apartment is famously cutthroat—but discovering that your landlord’s portal is leaking your most sensitive personal data shouldn't be part of the lease agreement. A recent security audit by a savvy researcher revealed a critical vulnerability in the leasing platform used by Beam Living, a Blackstone portfolio company. The flaw allowed any authenticated user to access the last four digits of Social Security numbers, dates of birth, addresses, and phone numbers of thousands of other applicants, simply by knowing their email address.
## The Hunt for an Apartment and a Vulnerability
Applying for a rental in NYC is a brutal process. The competition is fierce, the paperwork is intense, and the amount of personal information demanded is staggering. As one security-conscious applicant recently recounted, they were in the middle of the leasing process for a Beam Living property when they decided to do a little bit of security due diligence. While submitting sensitive details like their Social Security number for a background check, they kept their browser’s network tab open—a practice every savvy tech enthusiast knows is the first line of defense against phishing and sloppy code.
The user was specifically looking to see where their data was going. In an era of escalating cyber threats, ensuring your PII isn't being sent to a server vulnerable to any script kiddie is vital. Initially, nothing seemed out of the ordinary. The application portal seemed to be functioning with the expected GraphQL queries. However, a red flag was raised. The developer noticed that when viewing their own profile, the site made a call to `pd-dlcore.beamliving.com/graphql`. The specific GraphQL query was using the user’s email address as a parameter to fetch profile data, rather than simply deriving the user’s identity from a secure session cookie.
This is a classic vulnerability sign. A system that trusts a user to supply their own username or email to fetch data is often bypassing the authentication layer. While it’s not necessarily a vulnerability, it is a massive "code smell" that suggests the application might be trusting client-side input.
## The Initial Exploration: From Zero to Game Over
Curiosity and, let’s be honest, the instinct of a security researcher, kicked in. They decided to test the boundaries. The obvious next step was to see if they could query data for another user. Using a friend’s email address who had also applied for a lease through the portal, they plugged the email into the vulnerable parameter. The result? It was immediate and devastating.
The query returned a treasure trove of private data for the friend. This wasn't just the first name and email. The response included the last four digits of their Social Security number, full date of birth, home address, IP address, phone number, and other fields from the application. The system was not just pulling the session user’s data; it was offering a direct data retrieval service for any existing applicant record in the system.
## A Shared Portal Equals a Massive Breach
The impact of this went far beyond a single application. The flaw was found in a system used across all Beam Living communities. Anyone who had applied for a lease through that shared portal and whose record remained in the system was vulnerable.
This means if a threat actor knew the email address of a former or current applicant, they could submit a crafted API request and harvest the Social Security number details (last four) and DOBs of every resident. In the world of cybersecurity, this is a goldmine for identity theft and fraud. The attacker wouldn't even need to brute-force or cause a massive breach to exfiltrate all data; they just needed a list of emails.
## The Less-Than-Ideal Disclosure Process
Upon discovering the severe vulnerability, the researcher immediately halted their testing. This was a standard procedure for responsible disclosure. They immediately reached out to Beam Living to inform them of the issue. However, the "white hat" process became a test in itself.
The disclosure process was far from smooth. The researcher had to send multiple emails to different contacts before getting a phone call with a representative from Beam Living. During the call, the team expressed that they had checked the issue and found "no problem at all." The researcher, worried they might have jumped to conclusions, was advised to retest the vulnerability. Upon re-trying the exploit, the surprise was validated—it had been silently patched. The backend query was fixed, likely in response to the email or call, even if the front-line support team didn't know about it.
While the fix is a relief, the approach to handling the disclosure is a stark reminder of a common issue in enterprise cybersecurity. The reluctance to acknowledge a confirmed finding, the lack of a coordinated response, and the silence around the patch are all too common. In this case, the bug is fixed, but the system still demonstrated a lack of a proper incident response process.
## The Underlying Problem
There are several takeaways from this incident. First, the use of "last four digits" as a verification mechanism is an insecure concept. This leak proves that these digits are not as private as consumers assume. Coupled with a date of birth and an address, they can be used for identity fraud, credit card scams, or even two-factor authentication bypasses.
Second, the reliance on session cookies is critical. The fact that the API was designed to accept an email as a parameter rather than a session token reveals a weakness in the security architecture. Developers often do this to make the front-end coding easier, but the consequence is a lack of integrity in the server, potentially allowing access control failures.
Finally, this event highlights the broader need for security in the real estate industry. Large portfolio companies are massive targets because they handle huge amounts of sensitive data for applicants—many of whom are high-value targets in New York City. While Blackstone is a giant, their portfolio companies must maintain high-security standards.
## Lessons for the Hacker and the Pentester
For our audience of tech enthusiasts and security researchers, this is a classic case of "GraphQL introspection gone wrong." It’s a prime example of how web apps are still broken despite modern frameworks. The principle of **"Never Trust User Input"** is the lesson here. The server must validate the authenticated user against the requested object.
It also highlights the importance of **secure API design**—utilizing the session cookie and server-side variables rather than client-supplied data. If you are doing a red team assessment or a bug bounty, look for GraphQL endpoints where the fields might allow for verbose output that includes PII.
## Conclusion
The Beam Living, Blackstone exposure was a critical bug. It allowed complete viewing of sensitive PII just by knowing a target's email address. The fact that it took a plucky renter to find and report it shows how often these holes are missed. While the portal is now patched, the closure from the disclosure process remains an important lesson in the company's security culture. Hopefully, this situation will compel Blackstone and other property managers to audit their backends for identity and data exposure bugs before a malicious attacker gets the email and the exploit code. As we watch New York City’s housing market remain, one thing is clear: your lease shouldn't be the only thing getting signed—your consent to sloppy security should be off the table.