Meta has addressed a critical vulnerability involving broken access control that exposed sensitive customer support data across multiple services. This issue highlighted systemic weaknesses in authorization within their shared backend infrastructure.
The flaw, categorized as an Insecure Direct Object Reference (CWE-639) combined with Broken Access Control (CWE-284) and Missing Authorization (CWE-862), allowed unauthorized users to access and manipulate support-related data on Meta.com and its associated platforms.
The risk was significant due to its cross-functional impact and the potential exposure of personally identifiable information (PII) contained within support interactions.
Critical Meta IDOR Flaw
The vulnerability permitted attackers to retrieve customer support emails, case records, live chat transcripts, and internal support notes without proper authorization.
Additionally, sensitive metadata such as escalation details, case summaries, and attachments were also accessible. Beyond passive data exposure, the flaw enabled active abuse scenarios, allowing unauthorized users to create support tickets on behalf of other organizations, modify case statuses, and add unauthorized subscribers to support threads.
Such actions could facilitate social engineering, data harvesting, or operational disruptions within enterprises utilizing Meta services.
The issue was first identified during security testing of Meta Horizon Managed Solutions, an enterprise platform designed to manage Meta Quest devices and users.
Researchers found that certain GraphQL queries returned support-related data even when the requesting user did not have appropriate permissions, indicating inconsistent enforcement of authorization controls across backend services.
Further investigation revealed by WhiteAuth that multiple support channels, including Meta.com support workflows and chat systems, relied on shared infrastructure with flawed trust assumptions.
A significant contributing factor was the use of sequential identifiers for support cases. When coupled with missing authorization checks, this allowed attackers to enumerate case IDs and systematically access large volumes of sensitive support data.
The vulnerability was further compounded by the integration of Salesforce-backed components within Meta’s support ecosystem. Although Salesforce itself was not vulnerable, Meta’s implementation failed to enforce access controls properly across integrated systems, creating a broad attack surface.
What began as a narrowly scoped issue evolved into a cross-vertical exposure affecting multiple independent support channels. This underscores the risks associated with shared microservices architectures, where inconsistent authorization logic can propagate across systems.
The flaw effectively dismantled isolation boundaries between users and organizations, exposing communications that often contained confidential operational details and user-submitted information such as names, email addresses, and phone numbers.
The issue was reported to Meta in January 2026, with its severity increasing as additional impacted services were identified. Meta completed remediation in April 2026 and confirmed that there was no evidence of exploitation in the wild.
The company implemented fixes to ensure consistent authorization enforcement across all affected support workflows and backend services.
This case illustrates a recurring security challenge in modern cloud and API-driven architectures: ensuring uniform access control across interconnected systems.
Even minor inconsistencies in authorization logic can lead to significant exposure when combined with predictable identifiers and shared infrastructure. For organizations, this incident reinforces the importance of centralized authorization validation, thorough API security testing, and continuous monitoring of cross-service trust boundaries.
ALERT: 20+ government sites delivered malware to businesses and citizens. See full attack research to check your own exposure.
