An Interesting bug on a not-so-interesting Meta Platform — Messenger Kids

This is me, Samip Aryal from Nepal writing about one of my more unusual bug discoveries, this specifically found in BountyCon 2024 (the first report). It combines some interesting GraphQL mutations & business-logic flaws from a slightly forgotten Meta product — Messenger Kids.

Background

Messenger Kids accounts (“Neo accounts”) are meant for children under 13. Each kid_account can be managed by:

• one primary parent
• one additional parent

Parents are normal Facebook user accounts. Parental management is embedded directly inside the Facebook app through the Messenger Kids Dashboard or via https://www.facebook.com/messenger_kids (More about it here)

Since the start, some business logic behind this kid-parent relationship was very unusual to me:

1. Messenger Kids allows adding any friend as a secondary parent of a Neo account without their approval, and once added, the kid can directly chat with that user. And the parent can never block the Neo account.
2. There were these frequent prevailing low-hanging bugs around the Facebook and Facebook Lite applications, where users added as parents were unable to remove themselves or block communication due to errors or partial DOS states.

These aspects led me to be suspicious of this kid-parent relationship. I was curious if I could just add any random user (non-friend) as the parent of this kid's account. Will this allow me to directly talk to them via the Messenger Kids application? I tried manipulating the Graph API request

NeoApprovedUserUpdateManagingParentsMutation

Didn’t quite work as expected, but got some low-hanging fruits around it.

Fast forward to 2024 BountyCon, while I was dialing back in to test the Messenger kid parent dashboard interface in the FB app, I realized I had never fully evaluated this on the GraphQL endpoints themselves. Thus, I jumped to it.

THE Bug

As expected, when I made a POST request using this AJAX call, with managing_parent_id as any user’s userID, I was able to add that user to the parent of my Neo account.

MessengerKidsCometUpdateManagingParentsMutation:

new AsyncRequest('api/graphql/').setData({
  doc_id: 5247402565289912,
  variables: '{"input":{"managing_parent_id":"VICTIM_ID","mutation_action":"ADD_PARENT","neo_approved_user_id":"TEST_KID_ID","actor_id":null}}'
}).send()

Result:
Any Facebook user — even a non-friend — was added as a parent of the attacker-controlled kid account.

Because parents automatically appear in the child’s approved contacts, the attacker could then directly call or message the victim using the Messenger Kids application, fully bypassing the normal message-request flow.

// I reported this bug initially, and this report got fixed some days later with an unexpectedly good bounty.

— Unexpected because this bug had some obvious downsides, preventing it from scaling for maximum impact:

1. The added victim would get a notification once he is added as a parent, and he can just go to the Messenger kid Dashboard and remove himself as the parent of that kid. After this, he can simply block the Neo account and the message thread. (Although they could be added again with this)

2. But, the victim could also see which user added them, making it easy to block the attacker’s account and prevent him (kind of) from adding him to the parent role again.

FIX → Throws an error if the managing_parent_id (victim userID) ≠ friend with the actor (actor_id)

THE Bypass!

After the first fix, I revisited the same GraphQL mutation and focused on this particular parameter:

"mutation_action":"ADD_PARENT"

Also, to remove the added parent, a slight change to the same POST request. While testing the REMOVE_PARENTmutation, I noticed something odd:

Observation 1 — Removing non-existing parents (not added) still returned success

I could send:

"mutation_action": "REMOVE_PARENT"

…with any random managing_parent_id, even if the victim was not a parent at all.

This hinted that parent existence validation was missing.

I started fuzzing/exploring different mutation actions and found an interesting one:

"mutation_action":"REMOVE_PARENT_AND_KEEP_AS_CONTACT"

As expected, this too:

• did not require friendship (the previous fix didn’t apply)
• did not check if the victim was already a parent
• automatically converted them into a Messenger Kids contact

Bypass Payload

Hence, this was the modified AJAX call with the new mutation_action:

MessengerKidsCometUpdateManagingParentsMutation:

new AsyncRequest('api/graphql/').setData({
  doc_id: 5247402565289912,
  variables: '{"input":{"managing_parent_id":"VICTIM_ID","mutation_action":"REMOVE_PARENT_AND_KEEP_AS_CONTACT","neo_approved_user_id":"TEST_KID_ID","actor_id":null}}'
}).send()

This exploit again allowed the attacker to directly call or chat with anyone on Facebook, as previously.

ADDITIONALLY…

• With this bypass, the victim user won’t receive any sort of notifications, unlike previously (when they were added as a parent by X), almost completely hiding the identity. There’s nothing like removing oneself as a parent this time (because the victim isn’t added as a parent but as a CONTACT here)
• Also, while creating the Messenger Kids account, I identified no validation or sanitization in the name field., anything (< > “ ‘ / \ ( ) { } [ ] ; : = % & + — * ! ? $ @ # ^ |) can be supplied in its name.

• So this means, Paired with this bypass exploit, I could just message/call anyone impersonating as their friend, or anyone, and the victim would normally receive the message or call “from” the apparent profile (directly to their chat).
• The scary part is that the receiving person (victim) had no way to figure out the true identity of the person this time. There was no way to go to their profile or block their message. This kid's account was basically invincible — unblockable and untraceable.

Finally, combining all these scenarios, I elevated the impact and reported the bypass. I also received a good response from the Facebook Security Team ;)

This was triaged within a day, fixed, and totally unexpectedly rewarded double the first report. I never saw getting 2x the bounty for a bypass before this lol.

Final Fix

Meta deployed a global fix across both the GraphQL mutations and the Graph API endpoints involved in Messenger Kids parent management. Multiple doc_id variants and related API surfaces were updated to enforce both the friendship requirement and proper parent-existence validation before any parent-management action is allowed, closing the root cause across all endpoints.

The only unresolved area is the lack of name sanitization on Messenger Kids accounts — can be an interesting lead!

…

Thank you for reading this write-up, If you have any queries/suggestions, I’m available on Facebook/Instagram/Twitter (X). Also, you can contact me if you have an incomplete vector related to Messenger Kids — wanna collaborate or chain, or if you need an SSL bypass script for the Messenger Kids application.

…