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

Key facts for Meta Horizon support IDOR

Detection coverage for Meta Horizon support IDOR

As of 2026-07-22, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1620 across Splunk SPL, Microsoft KQL and Sigma, covering 15 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Sequential Support-Case-ID Enumeration (BOLA/IDOR) — SPL

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

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

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

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.

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

Indicators of compromise for Meta Horizon support IDOR

As of 2026-07-22, Threadlinqs Intelligence tracks 15 indicators of compromise for TL-2026-1620.

How Meta Horizon support IDOR works

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.

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 techniques by tactic:

Discovery

T1069 Permission Groups Discovery; T1087 Account Discovery; T1526 Cloud Service Discovery

Defense Evasion

T1078 Valid Accounts

Persistence

T1098 Account Manipulation

Collection

T1114 Email Collection; T1119 Automated Collection; T1213 Data from Information Repositories; T1530 Data from Cloud Storage

Initial Access

T1190 Exploit Public-Facing Application

Impact

T1565 Data Manipulation

Exfiltration

T1567 Exfiltration Over Web Service

Reconnaissance

T1592 Gather Victim Host Information; T1594 Search Victim-Owned Websites; T1595 Active Scanning

Remediation for Meta Horizon support IDOR

Patches

• Meta deployed a backend authorization fix in April 2026 adding per-case ownership verification across Meta.com support, Meta Horizon Managed Solutions, and the Salesforce-integrated case backend

Immediate actions

• Confirm the Meta-deployed April 2026 patch is applied across all affected surfaces (Meta.com support, Meta Horizon Managed Solutions, Salesforce-integrated backend)
• Audit support-case access logs for anomalous sequential case-ID access patterns predating the patch
• Review any organizational support cases for unauthorized status changes, added subscribers, or tickets created on the organization's behalf between case-system deployment and April 2026

Longer-term hardening

• Replace sequential/predictable object identifiers with non-guessable UUIDs for all customer-facing case/ticket records
• Enforce object-level authorization (ownership/ACL checks) at the API layer for every case read, write, status-change, and subscriber-management endpoint, independent of underlying platform (e.g., Salesforce) access controls
• Apply the OWASP IDOR Prevention guidance: centralize authorization checks, avoid exposing internal/sequential primary keys in client-facing APIs, and add automated IDOR regression tests to CI for support/case-management systems
• Extend bug bounty scope and internal red-team coverage to first-party SaaS-integrated backends (not just directly-owned codebases), given this flaw lived at the integration boundary rather than in Salesforce itself

Affected and fixed versions

• Meta Platforms, Inc. — Meta.com Customer Support Portal
  Vulnerable versions: production, pre-April 2026
  Fixed in: production, post-April 2026 patch
• Meta Platforms, Inc. — Meta Horizon Managed Solutions
  Vulnerable versions: production, pre-April 2026
  Fixed in: production, post-April 2026 patch
• Meta Platforms, Inc. (Salesforce-integrated backend) — Meta support case-management system built on Salesforce Service Cloud
  Vulnerable versions: production, pre-April 2026 (Meta application layer; underlying Salesforce platform was not vulnerable)
  Fixed in: production, post-April 2026 patch

Timeline of Meta Horizon support IDOR

• 2026-01-01 Independent researcher Rony K Roy (WhiteAuth) discovers the authorization weakness while testing locked-ioc-11 and reports it to Meta via the locked-ioc-13 (January 2026, exact day not disclosed).
• 2026-01-02 Further analysis by the researcher shows the flaw is not isolated to Horizon but affects a shared backend also used by Meta.com support workflows and a Salesforce Service Cloud-integrated case-management system.
• 2026-04-01 Meta deploys a backend patch adding per-case authorization/ownership verification across the affected support surfaces (April 2026, exact day not disclosed).
• 2026-04-02 Meta confirms it found no evidence of malicious exploitation of the flaw prior to remediation.
• 2026-04-03 Meta pays Rony K Roy a $78,000 bug bounty for the finding; Roy is subsequently listed among the top researchers on Meta's 2026 bug bounty leaderboard.
• 2026-07-17 Rony K Roy publicly discloses technical details of the IDOR/broken access control chain.
• 2026-07-21 SecurityWeek publishes coverage of the disclosure, confirming the $78,000 bounty and timeline details.
• 2026-07-22 GBHackers publishes a technical summary of the vulnerability chain and its impact.

Sources cited for Meta Horizon support IDOR

• Meta Bug Bounty — Program Scope bugbounty.meta.com · Vendor report · 2026-07-22
• Insecure Direct Object Reference Prevention Cheat Sheet cheatsheetseries.owasp.org · Research · 2026-07-22
• Critical Meta IDOR Flaw Let Attackers Access Customer Support Cases gbhackers.com · News · 2026-07-22
• Meta Paid $78,000 Bounty for Vulnerability Exposing Customer Support Data SecurityWeek · News · 2026-07-21
• Meta Pays $78,000 Bounty for Customer Support Data Vulnerability news4hackers.com · News · 2026-07-21

Threats related to Meta Horizon support IDOR

• CVE-2026-2031 "StubZero": Remote Code Execution in Google Cloud Application Integration via Exposed Proto Descriptors, GenericStubbyTypedTaskV2 and ACL Bypass
• Broken Object-Level Authorization (BOLA) in Airline GraphQL Booking API Exploited via Autonomous AI Red-Team Agent
• Claude-Powered AI Agent (OpenClaw) Autonomously Exploits Broken Access Control Flaw in Gym Booking API
• FIFA World Cup 2026 Broadcast API Broken Access Control (Missing Server-Side Authorization) Allowed Live TV Stream Takeover
• SolarWinds Serv-U 2026.3 Patches 16 Vulnerabilities (CVE-2026-28302 to CVE-2026-28321) Including Root RCE, IDOR-Chained Privilege Escalation, and Broken Access Control

Related coverage of this activity

• Snowflake GitHub Actions JIRA leak
• Elementor Pro upload RCE
• Buffa Rust protobuf DoS
• KindaRails2Shell Active Storage flaw
• JetBrains May-June 2026 patch cluster