Finding an Apartment in NYC Is Hard; Finding Your SSN Digits on a Blackstone Site Was Easier

Finding a rental in New York City is a nightmare of paperwork, background checks, and exorbitant fees. But as one cybersecurity-conscious applicant discovered, the process of securing a lease on a Beam Living property—a portfolio company owned by private equity giant Blackstone—was far less secure than the housing market is competitive. In a startling disclosure, a tenant applicant revealed that the company’s leasing portal was leaking the last four digits of Social Security numbers, dates of birth, home addresses, and phone numbers of thousands of applicants via a simple GraphQL query, accessible to anyone who knew the victim’s email address.

This glaring security vulnerability highlights the fragility of modern real estate cybersecurity. While the researcher noted that the exploit has since been silently patched, the company’s handling of the disclosure—ranging from dismissive responses to an opaque remediation process—raises serious questions about how corporate giants manage and protect sensitive customer data. This incident is a stark reminder that in the world of property management, the real keys to the kingdom are often data access points, not just door locks.

Network Tabs and the Humble GraphQL Query

During the application process for a lease at Beam Living, the security-conscious user (who was quite literally writing their social security number into a form) kept a watchful eye on the network traffic in their browser’s developer tools. They were checking the structure of the application, looking for how the frontend communicated with the backend—a standard practice for researchers looking for backend logic bugs. The initial reviews seemed benign, until the user navigated to their main profile and spotted a call to pd-dlcore.beamliving.com/graphql.

The request was not inherently malicious, but the choice of input parameters was enough to raise a red flag. Instead of relying on the session cookie to derive the authenticated user’s identity, the system was supplying a user’s email address directly into the GraphQL query. In web application security, passing a user-controlled identifier like an email through a query as a parameter—rather than trusting the session—is a classic sign of potential "Insecure Direct Object References" (IDOR). This is a vulnerability that permits a user to access data belonging to other users or systems.

To test the hypothesis, the researcher did what any penetration tester worth their salt would do: they used a friend’s email address (with the friend's knowledge, presumably) as the input. The result was a massive data breach. The query returned the last four digits of their friend’s Social Security number, date of birth, home address, IP address, and phone number. The response was not sanitized, and there was no authorization check in place to ensure the requesting user was the owner of the email address.

The impact was staggering. Beam Living used this single leasing portal across all its communities in New York City and beyond. This means that any individual who had applied for a lease through this shared portal—and whose record remained in the system—had their sensitive application data exposed to any other user who simply knew their email address. This isn't just about a single lease application; it’s a systemic vulnerability affecting the entire tenant ecosystem of the property giant.

The Arsenal of Cybersecurity Vulnerabilities

Let's break down the specific technical vulnerabilities at play here. The core flaw was a failure in authorization and access control. In a secure system, the backend should use the session cookie to identify the logged-in user and fetch their data from the database. In this case, the system was querying the database with an arbitrary identifier (the email) without verifying that the requester had the rights to that data. This is the classic IDOR vulnerability pattern that has plagued websites since the dawn of web apps.

The data returned also included sensitive information components that are a treasure trove for identity theft and fraud. The last four digits of a Social Security number are often used as a verification vector for security questions, banking, and financial institutions. Combined with a date of birth and a home address, this data creates a high-value composite that can be used for fraud or identity theft. The exposure of IP addresses is also a privacy breach and can be used for targeted attacks or geolocation tracking.

In the hands of malicious hackers, this specific malware and phishing kits could turn these credentials into a serious data breach. A platform that relies on knowledge-based authentication (KBA) using this data (asking "what is the last 4 of your SSN?" or "what is your address?") would be compromised instantly. The attacker could potentially use the data to apply for loans, purchase high-ticket items, or even take over other accounts that share the same verification methods.

This is not a simple cyberattack or brute-force; it’s a logical access flaw. A script could be written to scrape the entire database with a list of emails, harvesting data on a massive scale without breaking any network perimeter defenses. The attack vector is as simple as a web request, making it an easy target for script kiddies and advanced threat actors alike. This kind of issue in modern technology security is often more dangerous than a sophisticated zero-day because it doesn't require complex hacking tools—just knowledge of the URL structure and a target's email address.

The Saga of the Disclosure Process

Following the discovery, the researcher immediately stopped testing and responsibly disclosed the findings to Beam Living. However, the corporate response was anything but reassuring. The initial disclosure process required multiple emails to be sent to get a response. When the researcher finally got on a phone call with a member of the Beam Living team, the company representative claimed they had checked the issue and found "no issue at all."

This is a classic and frustrating pattern in cybersecurity incident response. The company's initial denial created a tense standoff. The researcher, a tenant, was aware of the consequence of the backlash. Yet, they were persistent. When they went back to the system to demonstrate the issue again, they found it had been silently patched. The vulnerability had been fixed without formal acknowledgment of the security flaw, let alone the data breach itself.

Silently patching a vulnerability is a common double-edged sword in the cybersecurity community. On one hand, it stops the bleeding. On the other, it fails to inform the affected users of a data breach, a violation of transparency and ethical security practices. The company's failure to identify the issue initially, and then silently fixing it without explaining what was found, suggests a lack of a mature security culture.

The researcher noted, "I alerted them that I was going to post this blog, and I hope I don’t get my lease canceled." This statement underscores the precarious position of security researchers who find themselves in a conflict with the very entities they are trying to protect. It also highlights a critical lesson for companies, particularly those as large as Blackstone: a lack of clear communication in the vulnerability disclosure process can turn a resolved tech problem into a PR nightmare. A clear, transparent disclosure process is just as important as the security patch itself. The cover-up and dismissiveness often outweigh the actual coding flaw in the eyes of the public.

The Bigger Picture for Cybersecurity

The incident isn't just about a data leak; it’s a template of how security is often treated as an afterthought in the "PropTech" (Property Technology) sector. As the real estate industry embraces digital platforms, it is sifting through huge amounts of sensitive personal data—from income taxes to SSNs—often with less security rigor than a typical banking infrastructure. This is a stark reminder that data security goes beyond the banking sector and affects every piece of information we submit for daily life.

For security researchers, this story serves as a tutorial on simple GraphQL/API testing. For cybersecurity professionals, it’s a case study in how access control authorization isn't a technical feature but a critical security layer. The assumption that your data is safe because you are applying for a lease from a reputable company is a risky one. The exposure of SSN digits can have long lasting and financial implications for the victims, and they might never even know their data was exposed if the data wasn't acknowledged.

The process of reporting these issues is also moving to an under-resourced area. The standard is to have a clear, documented security policy and a dedicated channel for security researchers to report flaws without the fear of legal retaliation or lease termination. Had Beam Living had a "bug bounty" program or a clear vulnerability disclosure policy (VDP), the researcher could have reported it faster without needing to chase via multiple emails.

Conclusion

The GraphQL vulnerability at Beam Living is a classic case of technical simplicity paired with a structural failure. The fact that a user could obtain the last four digits of a stranger's Social Security number with just an email is a stark reminder that "hacking" doesn't always require sophisticated malware or zero-day exploits—it can be as simple as a well-crafted query against a broken API. While the patch was deployed, the company's poor handling of the disclosure proves that a complete cybersecurity strategy includes not just patching the code, but respecting the trust of the user and the ethical researchers who help them improve.