# Critical Meta IDOR Flaw in Support Case Infrastructure Exposed Customer Emails, Transcripts, and Internal Notes (Meta Horizon Managed Solutions / Meta.com Support)

> A chained Insecure Direct Object Reference (CWE-639), Broken Access Control (CWE-284), and Missing Authorization (CWE-862) flaw in Meta's customer support case infrastructure — spanning Meta.com support workflows, Meta Horizon Managed Solutions, and a Meta-integrated Salesforce Service Cloud backend — allowed unauthorized enumeration and retrieval of support emails, case records, live chat transcripts, and internal support notes belonging to other organizations, as well as unauthorized creation of tickets, modification of case status, and addition of subscribers to cases. Independent researcher Rony K Roy (aka WhiteAuth) reported the issue to Meta in January 2026; Meta remediated it in April 2026, paid a $78,000 bug bounty, and found no evidence of in-the-wild exploitation. Roy publicly disclosed the findings on 2026-07-17.

- **Published:** 2026-07-22T00:00:00Z
- **Last reviewed:** 2026-07-22T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1620
- **Card image:** https://intel.threadlinqs.com/og/threat/threat-intel-meta-horizon-support-idor-tl-2026-1620.webp?v=f2df962e (Threadlinqs threat intel: Meta Support Case IDOR Exposes Chats: Analysis & Hunting (TL-2026-1620) — Critical severity, 15 IOCs, 9 detection rules.)
- **ID:** TL-2026-1620
- **Severity:** CRITICAL
- **Category:** VULNERABILITY
- **Status:** PATCHED
- **Detections:** 9 (1 shown free below) · **IOCs:** 15

## Description

In January 2026, independent security researcher Rony K Roy (publishing under the handle WhiteAuth) was evaluating Meta Horizon Managed Solutions — Meta's enterprise platform for administering Meta Quest devices and managed-user fleets — when he identified what initially appeared to be an isolated authorization weakness in its support-case workflow. Deeper analysis revealed that the weakness was not isolated to Horizon: it stemmed from a shared backend used across multiple Meta support channels, including the consumer-facing Meta.com support portal, and a Meta-integrated instance of Salesforce Service Cloud used as the underlying case-management system.

The root cause was a combination of three chained weaknesses: (1) support case records were assigned sequential, predictable identifiers (CWE-639, Insecure Direct Object Reference); (2) the support API/application layer did not consistently verify that the requesting principal owned or was authorized to view/modify a given case (CWE-284, Broken Access Control); and (3) certain case-management endpoints omitted authorization checks entirely (CWE-862, Missing Authorization). Because the underlying Salesforce platform itself enforced its own access controls correctly, the flaw was specific to how Meta's application layer queried and exposed Salesforce-backed case objects — Salesforce was not itself vulnerable.

Chaining sequential-ID enumeration with the missing/broken authorization checks meant that any authenticated (in some paths, potentially any) party could iterate through support case identifiers and pull back another organization's case emails, live chat transcripts, internal support-agent notes, escalation details, case summaries, and file attachments — data that frequently contained customer PII (names, email addresses, phone numbers) embedded in confidential operational communications. Beyond read access, the same lack of ownership verification let an attacker create new support tickets impersonating another organization, change the status of an existing case (e.g., closing or reopening cases that were not theirs), and add unauthorized subscribers/watchers to a case thread — extending unauthorized visibility into ongoing support conversations after the fact.

Roy reported the finding to Meta through the Meta Bug Bounty program in January 2026. Meta investigated, developed a fix that added proper per-case authorization/ownership checks across the affected surfaces, and rolled it out in April 2026. Meta stated it found no evidence that the flaw had been exploited by malicious actors prior to remediation. Meta subsequently paid Roy a $78,000 bounty, and he is listed among the top researchers on Meta's 2026 bug bounty leaderboard. Roy publicly disclosed technical details of the finding on 2026-07-17; the disclosure was covered by SecurityWeek on 2026-07-21 and by GBHackers on 2026-07-22. No CVE has been assigned, as this is a first-party SaaS/vendor-operated infrastructure flaw rather than a distributable software vulnerability.

## MITRE ATT&CK

- T1594 Search Victim-Owned Websites
- T1592 Gather Victim Host Information
- T1595 Active Scanning
- T1190 Exploit Public-Facing Application
- T1078 Valid Accounts
- T1526 Cloud Service Discovery
- T1213 Data from Information Repositories
- T1530 Data from Cloud Storage
- T1567 Exfiltration Over Web Service
- T1565 Data Manipulation
- T1087 Account Discovery
- T1069 Permission Groups Discovery
- T1098 Account Manipulation
- T1114 Email Collection
- T1119 Automated Collection

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**Sequential Support-Case-ID Enumeration (BOLA/IDOR) — SPL** (`TL-2026-1620-SPL-001`)

Detects a single authenticated principal or source IP issuing a high-rate burst of GET requests against sequential numeric /cases/{id} identifiers within a short window — the case-ID scraping pattern used to exploit the Meta support-case IDOR chain (CWE-639 sequential IDs) to enumerate other organizations' cases.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1595.002, T1190, T1213
- **Data sources:** api_gateway_access_logs, web_application_firewall_logs, app_service_http_logs
- **Severity:** critical
- **Confidence:** high

### Splunk SPL

```spl
index=web sourcetype="api:gateway" uri_path="/cases/*" http_method=GET
| rex field=uri_path "/cases/(?<case_id>\d+)"
| where isnotnull(case_id)
| bin _time span=1m
| stats dc(case_id) as distinct_case_ids, values(case_id) as case_ids, count as request_count by src_ip, user, _time
| where distinct_case_ids > 20
| sort -distinct_case_ids
```

### Microsoft KQL

```kql
AppServiceHTTPLogs
| where TimeGenerated > ago(24h)
| where CsUriStem has "/cases/" and CsMethod == "GET"
| extend CaseId = extract(@"/cases/(\d+)", 1, CsUriStem)
| where isnotempty(CaseId)
| summarize DistinctCaseIds = dcount(CaseId), RequestCount = count() by CIp, bin(TimeGenerated, 1m)
| where DistinctCaseIds > 20
| project TimeGenerated, CIp, DistinctCaseIds, RequestCount
```

### Sigma

```yaml
title: Sequential Support-Case-ID Enumeration (BOLA/IDOR)
id: 8f3c2a1e-1620-4c1a-9e01-tl20261620a1
status: experimental
description: Detects rapid sequential numeric object-ID access patterns against a support/case-management API endpoint, consistent with BOLA/IDOR enumeration (OWASP API1:2023) as seen in the Meta support-case IDOR chain.
references:
    - https://gbhackers.com/critical-meta-idor-flaw/
    - https://www.securityweek.com/meta-pays-78000-bounty-for-vulnerability-exposing-customer-support-data/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-07-22
tags:
    - attack.reconnaissance
    - attack.t1595.002
    - attack.initial-access
    - attack.t1190
    - attack.collection
    - attack.t1213
logsource:
    category: webserver
    product: generic
detection:
    selection:
        cs-uri-stem|contains: '/cases/'
        cs-method: 'GET'
    timeframe: 1m
    condition: selection | count(cs-uri-stem) by c-ip > 20
falsepositives:
    - Legitimate support-agent bulk-review tooling or QA scripts polling many cases
    - Sanctioned data-migration or backfill jobs iterating case IDs sequentially
level: high
```

**Known false positives:**

- Legitimate support-agent bulk-review tooling or QA/synthetic-monitoring scripts polling many cases in sequence
- Authorized data-migration or reporting jobs iterating case IDs

**Tuning notes:** Tune the distinct-case-id threshold (20/min) to the org's typical support-agent request volume; exclude known service-account/API-key identities used for legitimate bulk reporting; correlate case_id ranges against the requesting principal's own tenant to reduce false positives before alerting.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- Sequential Support-Case-ID Enumeration (BOLA/IDOR) — KQL (locked: unlock with TL Creds)
- Unauthorized Cross-Tenant Case Read via Broken Object-Level Authorization — KQL (locked: unlock with TL Creds)
- Bulk Automated Cross-Org Case-Data Collection & Exfiltration — KQL (locked: unlock with TL Creds)
- Sequential Support-Case-ID Enumeration (BOLA/IDOR) (locked: unlock with TL Creds)
- Unauthorized Case Status/Subscriber Mutation Following Enumeration (locked: unlock with TL Creds)
- Bulk Automated Cross-Organization Support-Case Data Collection (locked: unlock with TL Creds)
- Unauthorized Cross-Tenant Case Read — Missing Object-Level Authorization (locked: unlock with TL Creds)
- Unauthorized Case Status Change or Subscriber Addition Without Prior Ownership (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sources

- [Critical Meta IDOR Flaw Let Attackers Access Customer Support Cases](https://gbhackers.com/critical-meta-idor-flaw/)
- [Meta Paid $78,000 Bounty for Vulnerability Exposing Customer Support Data](https://www.securityweek.com/meta-pays-78000-bounty-for-vulnerability-exposing-customer-support-data/)
- [Meta Pays $78,000 Bounty for Customer Support Data Vulnerability](https://www.news4hackers.com/meta-pays-78000-bounty-for-customer-support-data-vulnerability/)
- [Meta Bug Bounty — Program Scope](https://bugbounty.meta.com/scope/)
- [Insecure Direct Object Reference Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1620