Today, I'm sharing a vulnerability I discovered in Meta's bug bounty program. This vulnerability allows an attacker to disclose the author of anonymous posts or comments in Facebook Groups.

📝 Description of Vulnerability

• The Feature Promise: In Facebook groups, you can write an anonymous post or comment, and therefore no one should know your identity except the group admins.
• The Logic Flaw: If you make an anonymous post or comment, and then someone blocks you and writes a comment on your post or comment, and you reply to them anonymously, their mention in your reply will appear as plain text instead of the normal blue clickable link.

🎯 Exploitation Scenario

1. The victim publishes an anonymous post or comment inside a Facebook group.
2. The attacker suspects that a specific group member is the owner of this anonymous post or comment.
3. The attacker blocks the suspected member and then writes a comment on the post/comment asking them something so they will reply.
4. If the attacker's mention in the victim’s reply appears as a normal blue clickable link, then the suspected member is not the owner of the anonymous post/comment.
5. If the attacker's mention in the victim’s reply appears as plain text (not a clickable link), then the suspected member is the owner of the anonymous post/comment.

💥 Impact of the Vulnerability

This vulnerability completely breaks the purpose of the Anonymous Post/Comment feature in Facebook groups. By exploiting the difference in how mentions are rendered (blue clickable link vs. plain text), an attacker can reliably deanonymize the author of any anonymous post or comment.

This leads to a serious privacy violation because:

• The feature explicitly promises that only group admins should be able to know the identity of anonymous authors.
• Attackers can expose the identities of users posting in sensitive groups (e.g., political, mental health, or support groups).
• It can put victims at risk of targeted harassment, doxxing, or real-world harm in cases where anonymity is crucial for safety.

Therefore, the vulnerability undermines user trust in Facebook’s privacy guarantees and poses a significant security and privacy risk.

🛠️ Steps to Reproduce

From Victim's Side:

• Go to a Facebook group and post an anonymous post.

From Attacker’s Side:

1. I suspect that the owner of this post is a specific member of the group.
2. Block the suspected member.
3. Write a comment on the post asking them something so they will reply to you.

From Victim's Side:

• Reply to the attacker’s comment.

From Attacker’s Side:

1. If my mention in the victim’s reply appears as a normal blue clickable link, then the suspected member is not the owner of the post.
2. If my mention in the victim’s reply appears as plain text (not a clickable link), then the suspected member is the owner of the anonymous post.

📝 Observation: As shown, my mention in the victim’s reply appears as plain text (not a clickable link), which means that the suspected member is the author of the anonymous post.

🎥 Proof of Concept Video

🎥 Proof of Concept Video

For a detailed, step-by-step demonstration of the full exploit chain, watch the Official POC Video on Google Drive 🚀.

📅 Bug Bounty Timeline

• September 14, 2025: Reported
• September 16, 2025: Triaged
• October 17, 2025: Fixed
• October 29, 2025: Bounty Rewarded 🎉

👤 Follow Me

• Facebook
• LinkedIn

Today, I'm sharing a unique logical vulnerability I discovered in Meta's bug bounty program. This flaw allows an attacker to completely manipulate Facebook's privacy logic and permanently prevent any user from blocking them.

📝 Description of Vulnerability

• Recurring Events: On Facebook Events, a user can navigate to https://www.facebook.com/events/create/ and create a recurring event—which is simply a single event that repeats at different time intervals.
• The Logic Flaw: If you create a recurring event and then immediately delete it, the account enters a glitched state. Any Facebook user who tries to block you after this will encounter a system error that prevents the block from finalizing.

🎯 Exploitation Scenario

1. The Intent: The attacker wants to permanently prevent any Facebook user from blocking them.
2. The Setup: The attacker goes to the events creation page, clicks “Repeat event”, sets it to repeat twice, and clicks “Create event”.
3. The Trigger: The attacker deletes this recurring event to trigger the account glitch.
4. The Abuse: The attacker posts abusive comments on a victim’s posts or interacts with them inappropriately.
5. The Failure: The victims try to block the attacker but fail completely, encountering the error message: "Error performing query."

💥 Impact of the Vulnerability

• Total Block Failure: The victim is completely unable to block or restrict the attacker’s Facebook account.
• Continuous Harassment: Offensive comments remain visible to the victim and to all other users, enabling unrestricted cyberbullying.
• Infinite Loop: The victim is forced to manually delete offensive comments, but the attacker can immediately post new ones without limitation.
• User Confusion: The victim has no clear indication or explanation as to why blocking is failing, leaving them feeling exposed and unsafe.
• Safety Undermined: This vulnerability enables attackers to bypass Facebook’s fundamental safety control (blocking), directly undermining user protection.

🛠️ Steps to Reproduce

From Attacker’s Side:

1. Targets a victim and decides to permanently disable their ability to block the attacker on Facebook and Messenger.
2. Navigates to https://www.facebook.com/events/create/.
3. Clicks “Repeat event”, sets it to repeat twice, and clicks “Create event”.
4. Deletes the newly created recurring event.
5. Goes to the victim's profile and posts offensive comments.

From Victim’s Side:

1. Opens the post, notices the abuse, and attempts to block the attacker’s account.
2. Result: The blocking action fails, and the system displays the error: "Error performing query."

🎥 Proof of Concept Video

🎥 Proof of Concept Video

For a detailed, step-by-step demonstration of the full exploit chain, watch the Official POC Video on Google Drive 🚀.

📅 Bug Bounty Timeline

• October 6, 2025: Reported to Meta Bug Bounty.
• October 7, 2025: Triaged by the security team.
• October 8, 2025: Fix deployed to production.
• November 3, 2025: Bounty awarded by Meta! 🎉

👤 Follow Me:

• Facebook
• LinkedIn

Today, I'm sharing a critical vulnerability I discovered in Teleport's bug bounty program. This privilege escalation flaw allows an Access List Owner to bypass access control policies and systematically elevate their account's role to Admin, gaining full control over the organization.

📝 Summary

Go to [your-domain.teleport.sh/web/accesslists]. Create a new access list and add a role to "Roles Granted," e.g., "reviewer" role. Add a user as the Access List Owner. The user, as the Access List Owner, can escalate the role of the list to higher roles, thereby escalating their own account's role. This is a prohibited procedure, as stated in the official documentation, that Owners are not able to control what roles and traits are granted by the Access List.

🛠️ Steps To Reproduce

1️⃣ From Organization Owner Account:

1. Go to [your-domain.teleport.sh/web/accesslists].
2. Create a new access list.
3. Add a user as List Owner.
4. Add a role to "Roles Granted," e.g., "reviewer" role.

2️⃣ From Access List Owner Account:

1. Add a new member to the access list and intercept the request.
2. Add "editor" role on "grants roles".
3. The "editor" role will be added to "Permissions Granted".
4. Logout and re-login to the account.
5. Result: Now, the user has the "editor" role and can perform any action on the entire organization.

🎥 Proof of Concept Video

🎥 Proof of Concept Video

For a detailed, step-by-step demonstration of the full exploit chain, watch the Official POC Video on Google Drive 🚀.

💥 Impact

• Privilege Escalation: Direct violation of the principle of least privilege.
• Unauthorized Access: High potential for unauthorized access to highly sensitive information.
• Security Breach: Risk of totally compromising the overall security of the system.
• Violation of Access Control Policies: Complete contradiction with Teleport's official documentation and security policies.
• Risk of Insider Threats: Potential exploitation by malicious insiders with limited access.

📅 Bug Bounty Timeline & Updates

💬 Team Correspondence & Comments:

🎯 jent-teleport (Dec 11, 11:59pm): "Thank you for the report @moaz219. I was able to reproduce this and agree with you that is a concerning privilege escalation in our new Access List functionality. I will let you know as soon as I have an update on this fix."

💰 Teleport Team (Dec 12, 9:33pm): "Thank you again for this and your other recent reports @moaz219!"

🎁 Teleport Team (Dec 20, 7:10pm): "Yes, I can confirm this report is eligible for the privilege escalation bonus. Thank you for asking!"

👤 Follow Me:

• Facebook
• LinkedIn

Today, I'm sharing a vulnerability I discovered in Meta's bug bounty program. This vulnerability allows attackers to disable SMS-based Two-Factor Authentication for the victim's Facebook account.

Prerequisites for Understanding the Vulnerability

To understand this vulnerability, it's necessary to understand a few key concepts first.

1. Account Center:

The Account Center, provided by Meta, offers users a unified interface to manage and integrate their experiences across Facebook, Instagram, and other Meta services. It centralizes settings, permissions, and account data management, streamlining the handling of multiple linked accounts under the Meta umbrella. For more information about the Account Center, you can visit this page.

2. Facebook SMS-based Two-Factor Authentication:

On Facebook, if you have a phone number linked to your account and have SMS-based Two-Factor Authentication (2FA) enabled using this phone number, and this number becomes linked to another Facebook account, it will automatically be removed from your account, disabling the SMS-based 2FA.

Exploiting the Vulnerability

While testing the Account Center, I discovered that if you have two connected accounts in the Account Center and one of them has a phone number linked to it, you can transfer this number to another account. For example, if you have connected Facebook and Instagram accounts, and your Facebook account has a phone number linked to it, you can open the Account Center from Instagram and add this number from your Facebook account to your Instagram account, and vice versa.

This led me to consider a scenario: Suppose the victim has two connected Instagram and Facebook accounts, with a phone number linked to their Facebook account. If the victim has 2FA enabled on their Facebook account using this phone number, and the attacker gains access to the victim's Instagram account, the attacker could transfer the phone number from the victim's Facebook account (which they don't have access to) to the Instagram account (which they do have access to). Then, by linking the victim's Instagram account to a Facebook account they control, the attacker could remove the phone number from the victim's Facebook account, effectively disabling the 2FA.

I attempted this by accessing the victim's Instagram account and trying to transfer the victim's phone number from their Facebook account to the Instagram account. Unfortunately, this attempt failed because I was prompted to re-verify the phone number, so I couldn't complete the transfer.

After further consideration, I came up with a different idea: What if I added my Meta account to the victim's Account Center and then tried to transfer the victim's phone number to the Instagram account from the Meta account center? Here's what I did:

I added my Meta account to the victim's Account Center. Then, from the Meta account center, I successfully transferred the victim's phone number to the Instagram account. I quickly connected the Instagram account to a Facebook account that I own and transferred the phone number from the Instagram account to my Facebook account. This action removed the phone number from the victim's Facebook account, disabling their 2FA.

Steps to Reproduce

From Victim's Side:

1. The victim has two connected Instagram and Facebook accounts.

2. The victim has a phone number linked to their Facebook account.

3. The victim has 2FA text message enabled on their Facebook account using this phone number.

From Attacker's Side:

1. The attacker gains access to the credentials of the victim's Facebook and Instagram accounts.

2. The attacker's target is to bypass Facebook 2FA and gain access to the victim's Facebook account.

3. The attacker logs into the victim's Instagram account.

4. The attacker navigates to https://accountscenter.meta.com/accounts and adds the victim's Instagram account to their Meta account.

5. The attacker navigates to https://accountscenter.meta.com/personal_info/contact_points and adds the victim's phone number from the victim's Facebook account to the victim's Instagram account.

6. The attacker navigates to https://accountscenter.instagram.com/accounts/ and removes the victim's Facebook account, and adds an account they own.

7. The attacker navigates to https://accountscenter.instagram.com/personal_info/contact_points/ and adds the phone number to the newly added Facebook account.

From Victim's Side:

1. The victim navigates to https://accountscenter.facebook.com/password_and_security/two_factor and finds that their Facebook 2FA has been disabled.

🎥 Proof of Concept Video

For a detailed, step-by-step demonstration of the full exploit chain, watch the Official POC Video on Google Drive 🚀.

Impact

This bug allows an attacker to bypass the 2FA of a victim's Facebook account, potentially leading to unauthorized access and control over the victim's Facebook account.

Timeline

• May 20, 2024: Reported

• May 28, 2024: Triaged

• May 29, 2024: Bounty Rewarded ($2500)

• August 3, 2024: Fixed

Follow Me:

• Facebook

• LinkedIn

Today, I'm sharing a vulnerability I discovered in Meta's bug bounty program. This vulnerability allows attackers to gain unauthorized access to victims' account data, affecting Meta's primary technologies (Facebook, Instagram, and Meta accounts).

To understand this bug, it's essential to grasp what is the Account Center.

The Account Center, provided by Meta, offers users a unified interface to manage and integrate their experiences across Facebook, Instagram, and other Meta services. It centralizes settings, permissions, and account data management, streamlining the handling of multiple linked accounts under the Meta umbrella. For more information about the Account Center, you can visit here.

Sensitive Data Transfer Feature

One of the features of Account Center is the ability to download or transfer the data of your accounts, including those of other linked accounts. This data is extremely sensitive and can include:

• Personal messages

• Photos and videos

• Friends and followers lists

• Login and session data

• Payment information

Given the sensitivity of this data, robust security measures are expected to be in place to protect it from unauthorized access.

Exploiting the Vulnerability: Unauthorized Data Transfer

I assumed the scenario of gaining access to a victim's Facebook account, which is linked with Instagram and Meta accounts. I then attempted to access the data of these other linked accounts.

1. I navigated to the Account Center data download page.

2. Attempting to download the data of the linked Instagram and Meta accounts, I was prompted for the passwords of these accounts.

3. Initially, I entered the correct password and captured the successful response.

4. Subsequently, I tried again, entering incorrect passwords and manipulating the response with the previously captured successful response. This method did not work for direct downloads.

However, there was an option to transfer the data to cloud services like Google Drive or Dropbox. I exploited this feature:

1. I initiated the data transfer and was prompted for the passwords of the linked Instagram and Meta accounts.

2. I entered incorrect passwords, intercepted the request, and manipulated the response with the previously captured successful response.

And just like that, the transfer started, and I received all the victim's Instagram and Meta account data in my drive without knowing the passwords for those accounts.

This bug also works across other platforms. For instance, if an attacker gains access to a victim's Instagram account, they can transfer the data of linked Facebook and Meta accounts. Similarly, if an attacker gains access to a victim's Meta account, they can transfer the data of linked Facebook and Instagram accounts.

Steps to Reproduce

Victim's Side:

1. The victim has connected Instagram, Facebook, and Meta accounts.

Attacker's Side:

1. The attacker gains access to the victim's Facebook account.

2. The attacker navigates to Account Center data download page.

3. The attacker initiates a transfer of all the victim's account information to their Google Drive.

4. The system prompts for the Instagram and Meta passwords.

5. The attacker enters any random password and intercepts the request.

6. The attacker replaces the response body with:

   {"data":{"fxcal_reauth_v2":{"success":true,"error_data":null,"error_state":null}},"extensions":{"is_final":true}}
   

7. The transfer starts, and the attacker waits for it to finish.

8. The attacker opens their drive and finds they have received all the victim's account data.

🎥 Proof of Concept Video

For a detailed, step-by-step demonstration of the full exploit chain, watch the Official POC Video on Google Drive 🚀.

Impact

This vulnerability allows an attacker to gain unauthorized access to sensitive user data from linked Facebook, Instagram, and Meta accounts. By exploiting this flaw, an attacker can bypass the security mechanisms meant to protect this data, leading to potential privacy breaches and misuse of personal information.

Timeline:

• May 6, 2024: Reported

• May 22, 2024: Triaged

• May 29, 2024: Bounty Rewarded ($5000)

Follow me:

• Facebook

• LinkedIn