Meta Fixed Critical Support Flaw That Could Expose Emails, Chats, and Files

Meta has fixed a critical authorization vulnerability that could have allowed attackers to access customer support emails, chat conversations, case records, and uploaded files belonging to other users and organizations.

Independent security researcher Rony K Roy discovered the weakness while testing Meta Horizon Managed Solutions. His investigation later connected the issue to shared support infrastructure that served several Meta services, according to his technical disclosure.

Roy reported the flaw to Meta in January 2026. Meta initially treated the report as a lower-impact issue, but expanded testing revealed a much wider authorization problem. The company completed its fixes in April, and Roy said Meta found no evidence of malicious exploitation. SecurityWeek reported that Meta awarded the researcher $78,000.

Authorization Flaw Reached Multiple Meta Support Systems

The investigation started with Meta Horizon managed services, an enterprise platform that lets organizations manage Meta Quest devices, applications, and managed accounts. Roy found that some support-related GraphQL operations returned information even when the requesting account lacked the required permissions.

Further testing showed that the affected operations connected to shared backend services. As a result, the problem reached beyond one Horizon support feature and potentially affected Meta.com email support, customer support chats, case-management tools, and related workflows.

The issue involved several closely related authorization weaknesses. These included broken access control, missing authorization checks, and insecure direct object references, commonly known as IDOR vulnerabilities.

What Information Could Attackers Access?

Support tickets often contain more sensitive information than ordinary account pages. Users may share names, phone numbers, email addresses, screenshots, identity documents, diagnostic files, business information, or account details while trying to resolve a problem.

Roy found that the vulnerable operations could return support records associated with other users. Sequential case identifiers also made it possible to test nearby case numbers and potentially enumerate large collections of support records.

The researcher’s findings described exposure across email conversations, chat transcripts, case summaries, escalation details, attachments, and contact information submitted during support interactions.

Potentially accessible data	Security impact
Emails exchanged with Meta Support	Could expose private account, business, or recovery information
Support chat transcripts	Could reveal conversations with support agents and troubleshooting details
Uploaded files and attachments	Could expose screenshots, documents, logs, or identity information
Case summaries and metadata	Could reveal case status, ownership, history, and internal identifiers
Internal notes and escalation details	Could provide information about Meta’s support decisions and procedures
Names and contact information	Could support phishing, impersonation, or social engineering attacks

Attackers Could Also Manipulate Support Cases

The vulnerability did more than expose stored information. Roy found operations that could let an unauthorized user create support requests on behalf of another organization, change a case’s status, or alter parts of the support workflow.

An attacker could also add an external account as a subscriber to an existing support case. That action could provide continued visibility into messages and updates without requiring the attacker to repeatedly exploit the original data-access operation.

According to the independent report on the disclosure, the combined weaknesses could let an attacker enumerate case numbers, retrieve support requests, change workflow states, and add unauthorized subscribers.

• Create support requests for another Horizon organization
• Read email and chat exchanges linked to support cases
• Download files submitted through affected support channels
• Change case statuses or other workflow details
• Add unauthorized users as support-case subscribers
• Collect contact information for phishing or impersonation attempts

Salesforce Did Not Cause the Vulnerability

Parts of Meta’s support infrastructure reportedly used Salesforce-backed workflows and data structures. However, the researcher did not identify a vulnerability in Salesforce itself.

The weakness came from Meta’s implementation and integration of authorization controls across its support services. Backend operations did not consistently confirm whether the requesting account had permission to view or modify the requested support case.

This distinction matters because replacing the underlying customer relationship management platform would not correct an authorization failure in Meta’s own application logic. Developers must enforce access rules whenever an application retrieves or changes an object, regardless of which platform stores the data.

Why Sequential Case IDs Increased the Risk

An IDOR vulnerability becomes more dangerous when an application uses predictable object identifiers. If support cases receive sequential numbers, an attacker can alter one known identifier to test adjacent records.

Strong server-side authorization should block those requests even when an attacker knows a valid case number. In this incident, the affected GraphQL operations reportedly returned data without consistently validating the requester’s relationship to the case.

Combining predictable identifiers with missing authorization checks could have supported large-scale enumeration. An attacker would still need access to the relevant service and operations, but the predictable numbering could simplify the search for valid records.

Meta Paid the Researcher a $78,000 Bug Bounty

Roy submitted his initial report in January 2026. Meta increased the report’s severity after the investigation showed that shared infrastructure expanded the potential impact across multiple support services.

Meta finished deploying its fixes in April 2026. Roy later disclosed the issue publicly and said the company awarded him $78,000 through its bug bounty program. Meta’s 2026 bug bounty leaderboard lists Roy among its leading security researchers.

SecurityWeek contacted Meta about the findings but did not receive a response before publication. Therefore, the public timeline, bounty amount, remediation status, and statement about exploitation primarily come from Roy’s disclosure and his communication with the publication.

Event	Timeline
Researcher discovered the authorization weakness	January 2026
Roy reported the vulnerability to Meta	January 2026
Meta expanded the investigation and raised the severity	Early 2026
Meta completed remediation	April 2026
Researcher published the technical disclosure	July 2026
Reported bounty	$78,000

No Evidence of Malicious Exploitation

Roy said Meta found no evidence that attackers abused the vulnerability before the company fixed it. The available disclosure does not identify affected customers, a confirmed data breach, or a known criminal campaign connected to the flaw.

That finding means the vulnerability created a serious exposure risk, but it does not prove that criminals accessed customer support records. Users should distinguish between data that a flaw made accessible and data that an attacker demonstrably stole.

Meta has not assigned a public CVE identifier to the issue. The disclosure instead classifies the underlying problems through common weakness categories covering broken access control, authorization bypass through user-controlled keys, and missing authorization.

What Meta Customers Should Do

Meta has already corrected the vulnerable support workflows, so users do not need to install a software update. Organizations that used Horizon support services during the affected period can still take several precautionary steps.

• Review support cases for unfamiliar subscribers, comments, or status changes.
• Check whether support tickets contained passwords, recovery codes, identity documents, or other secrets.
• Rotate any credentials or access tokens previously shared through support.
• Warn staff about phishing messages that reference genuine support cases.
• Review Meta administrator accounts and remove access that users no longer need.
• Report unexplained support activity directly through Meta’s official channels.

Organizations should treat uploaded support files as sensitive records and limit the information they include. Redacting unnecessary personal details and using temporary credentials can reduce the impact of future support-system vulnerabilities.

Meta continues to operate its bug bounty program to encourage responsible vulnerability reporting. The size of this award reflects the risk created when one authorization weakness reaches several services through shared backend infrastructure.

The incident also shows why support platforms need the same access-control testing as payment, identity, and account-management systems. Meta describes Horizon managed services as a central platform for organizational device and account management, making strict separation between customer organizations essential.

FAQ