What Happened When I Reported a Facebook Notification Vulnerability to Meta

In August 2026, I submitted a report to Meta's Bug Bounty program describing a chain of issues in Facebook's "Invite to Manage Your Stream" feature — the Community Manager Invite tool. Over the following six weeks, the report went through two rounds of rejection, a resubmission with a proof-of-concept video, and a final closure. This is a record of that exchange, in order, with my own notes on each stage.

The Finding

The Community Manager Invite feature lets a Page admin send an invite to any user — including someone who isn't their friend — asking them to help manage a live stream. The invite generates a notification directly in the recipient's main Notifications panel. That matters because Facebook already treats messages from non-friends differently: on Messenger, an unsolicited message from a stranger goes into "Message Requests," a separate folder built specifically to reduce unwanted contact. The Community Manager Invite notification doesn't go through anything like that. It lands in the same place as notifications from people you actually know.

On top of that, I found the Page's display name gets inserted directly into the notification text. Since a Page name can be set to almost any string, that field can function as a free-text message to a stranger — for example, naming a Page "Custom Message instead of Page Name Here" and having that exact string appear in someone's notifications.

Three more behaviors compounded the issue:

• If the admin deletes the invite or the Page after sending it, the notification stays visible to the recipient anyway. Clicking it leads nowhere, which confirms the underlying invite record is gone server-side — but the notification itself was never invalidated.
• If the recipient explicitly declines the invite, the admin can send another one immediately. There's no cooldown tied to the decline. I did find a broad rate limit that blocks the admin after roughly 20 requests, but it isn't connected to the specific recipient or to their decision to decline — it's a generic send cap, not a per-victim protection.
• The GraphQL mutation behind the invite (CometGamingVideoMutationsCommunityManagerBulkInviteMutation) returned a CRITICAL field_exception server error on multiple occasions, with the mutation result reported as null — yet the invite and notification were delivered regardless. The client sees a failure; the recipient gets the notification anyway.

I documented each of these with reproduction steps, the raw request and response from the network tab, and trace IDs for Meta's internal log correlation.

Timeline

August 17, 2026 — Report Submitted

I submitted the report, titled "Community Manager Invite: Notification Persists After Deletion, Bypasses Non-Friend Message Filtering, and Non-Atomic GraphQL Mutation Delivers Invite Despite Reported Server Error (PoC included)." Meta's automated acknowledgment assigned report number 1815397989614160 and asked me to hold off on public disclosure while they reviewed it.

August 19, 2026, 3:05 PM — First Rejection

Two days later, Meta replied with what reads as a template response:

"After reviewing your submission, we've determined that the reported issue does not qualify as a valid vulnerability under the scope of our bug bounty program. This may be because the behavior described is working as intended, falls outside our program scope or does not demonstrate a clear security or privacy impact. Due to the volume of reports we currently receive, we are unable to provide detailed information as to how we reached this decision."

No specific reasoning was given — just a list of possible categories the rejection might fall under, without saying which one applied.

August 19, 2026, 3:16 PM — My Reply

I responded the same day, narrowing the argument to what I saw as the core issue: this isn't just an unwanted invite, it's a way to route arbitrary text past a protection Facebook already built for non-friend contact. I laid out the persistence-after-deletion behavior and the lack of a decline-linked cooldown as supporting evidence, and offered to provide a video or repeat the test on Meta's own test accounts.

September 25, 2026, 4:04 PM — Second Rejection

Over a month later, Meta responded again, this time with more structure but the same outcome:

"We checked the behavior you described against the intended behavior of the product, and against the scope of our program. We could not find a way for someone to use this behavior to affect the security/privacy of Meta users data. We also could not find a way for them to take an action they are not already allowed to take. Your latest message did not add technical details that change this conclusion."

They asked for four specific things if I wanted to appeal further: step-by-step instructions reproducible from a new account, the exact request/endpoint and response, the maximum achievable impact against a victim, and a video or screenshots.

September 26, 2026, 2:22 PM — PoC Video Submitted

I replied with a timestamped walkthrough covering all six points of the chain — Page setup, invite sent, Page deleted, notification still visible with a dead link, decline followed by an immediate resend, and the DevTools network tab showing the CRITICAL error alongside successful delivery — along with a link to an unlisted YouTube video.

September 29, 2026, 12:36 PM — Final Closure

Three days later, the case was closed:

"We have investigated your report and concluded that while the behavior you reported might be unexpected, it does not have a security/privacy impact. Since what you describe doesn't appear to be a security vulnerability, we encourage you to report a general software bug."

This reply, signed by someone named "Sparrow" on the Meta Security team, is shorter than the previous two and doesn't reference the video, the network trace, or any of the specific points raised in my last message. It's the first reply in the thread that concedes the behavior is "unexpected" while still closing it as non-security.

The Open Question

After the final rejection, I checked the YouTube Studio analytics for the unlisted PoC video I'd linked in my September 26 reply. It shows zero views — not low engagement, zero, across the entire period since upload, and zero in the realtime panel as well.

I can't confirm that this means the video was never watched. Unlisted video view counts can fail to register for reasons that have nothing to do with whether a human opened the link — corporate link scanners and sandboxed preview tools sometimes load a page without executing the script that counts a view, and ad blockers or privacy extensions can have the same effect. So zero views is not proof of zero viewing. What it is, though, is the absence of any evidence that the video was watched, sitting next to a rejection that didn't engage with anything specific to the video's content. I think that combination is worth naming, even without being able to draw a firm conclusion from it.

Where This Leaves Things

I'm not asserting that Meta's triage team ignored the report. It's possible the video was reviewed through a method that doesn't register a view, the reasoning was sound, and the behavior genuinely falls outside what they consider a security issue. I can't rule that out, and I think it's important to say so plainly rather than overstate the case.

What I can say is that the process gives no way to tell the difference between a careful review that disagrees with my assessment and a fast triage pass that didn't engage with the specific evidence submitted. Both produce the same kind of reply. For a researcher deciding whether continuing to document, test, and resubmit a finding is worth the time, that distinction is the one that actually matters — and it's the one the current process doesn't surface.