Meta Paid $78,000 Bounty for Vulnerability Exposing Customer Support Data

**Meta** paid a **$78,000** bug bounty after a security researcher found a **broken access control** flaw in the company’s **support infrastructure**. The issue could expose **customer support data**. SecurityWeek reported the payout under the title Meta Paid $78,000 Bounty for Vulnerability Exposing Customer Support Data.

**Broken access control** means the system failed to enforce who could read or act on which support records. In support stacks that pattern often shows up as missing or weak checks on ticket IDs, session or role claims, agent tools, or internal APIs that sit behind the help portal. Here the failure sat in Meta’s **support infrastructure**, so the risk was not a public marketing page but the systems that hold case history, contact details, and related support context.

For engineers and builders, support planes are high-value because they aggregate identity, account state, and conversation history in one place. A control gap there can turn a normal agent or integration path into an unauthorized read of customer data without needing a full product compromise. Access checks must apply on every object and action, not only at login or UI layer.

In the market, large platforms run public bounty programs precisely because support and admin surfaces are hard to lock down at scale. A **$78,000** award signals Meta treated this class of finding as serious under its program rules, and it sits in the same competitive pressure all major consumer platforms face: keep help tooling usable for agents while preventing cross-user or cross-tenant data access.

Watch for how Meta and peers harden **object-level authorization** on support APIs, agent tools, and ticket lookups after findings like this. Practical takeaway for anyone shipping support or CRM-adjacent systems: treat ticket and case IDs as untrusted input, enforce authorization server-side per resource, and put support data under the same access-review bar as primary product PII.