Meta Support Flaw Turned Private Cases Into a Cross-Account Risk

Customer support systems are usually built to be quiet back rooms: ticket histories, private emails, chat threads, and workflow actions that only the right person should ever touch. When the authorization layer slips, that back room can become a cross-account viewing window. That is the risk raised by a critical broken access control flaw tied to Meta’s support infrastructure.

Fast Facts

• The issue was described as a critical broken access control, or IDOR, flaw.
• It was linked to Meta’s customer support infrastructure.
• Reported impact included access to private support emails, chats, and case data.
• The flaw could also let someone manipulate support workflows on behalf of another user.
• Independent researcher Rony K Roy was credited, and Meta later patched the issue and awarded a $78,000 bounty.

Why this kind of bug matters

OWASP describes IDOR as a failure to verify that a requester is authorized to access a referenced object. In practical terms, that means an application may accept an object identifier and return data or trigger an action without proving the account is allowed to touch it. In support systems, those objects are often tickets, case notes, messages, attachments, or status changes.

That makes the weakness more than a simple read leak. If a user can open another person’s case, the private contents may be exposed. If the same object can also be updated, reassigned, approved, or closed, the flaw can become an integrity problem as well. The available facts fit that pattern: access to other users’ support data, plus the possibility of workflow manipulation.

From a defensive perspective, the lesson is straightforward but easy to miss under deadline pressure. Hiding an identifier or making it harder to guess is not enough. The server has to verify ownership or privilege on every read and every state change. That is especially important in internal tools, where teams may assume that a logged-in user is automatically trusted once they reach the interface.

At the time of writing, public information does not fully establish whether the flaw was used in the wild, the exact endpoint involved, or the full scope of affected records. The available information supports a risk analysis, not a definitive claim about broader compromise.

Conclusion

This case is a reminder that support platforms are high-value systems, not administrative afterthoughts. A single object-level authorization mistake can cut across privacy, process integrity, and customer trust at the same time. The broader lesson for security teams is to test internal workflows with the same suspicion they reserve for public APIs, because attackers do not need a flashy exploit when a missing check will do.

WIKICROOK

• IDOR: Insecure Direct Object Reference, a flaw where changing an object reference can expose another user’s data if authorization checks are missing.
• Broken Access Control: A class of weaknesses where applications fail to enforce who is allowed to view or modify a resource.
• Object-Level Authorization: Server-side checks that confirm a user may access a specific record, ticket, or file.
• Bug Bounty: A program that rewards security researchers for responsibly reporting valid vulnerabilities.
• Authorization Regression Testing: Repeated testing to make sure access-control fixes stay intact after code changes and feature updates.