$5,000 Bounty From Microsoft Teams Community Invitation Bypass (CVE-2025-49731)

KacaTeknologi.com/en – I discovered a privilege escalation vulnerability in Microsoft Teams Community that allowed a regular community member to bypass the owner’s invitation restrictions and invite unauthorized users to join the community.

The vulnerability was reported to Microsoft and was assessed as an Important security issue under the Permissions, Privileges and Access Controls category. Microsoft awarded a $5,000 bounty for the finding, which was later assigned CVE-2025-49731.

In this write-up, I will explain how I discovered the issue, how the Microsoft Teams Community invitation mechanism could be bypassed, and why the vulnerability represented a broken access control issue.

Microsoft Teams Community allows users to create communities and control how other users can join them.

For this research, I used a community with the following configuration:

• Require approval to join: Disabled
• Allow members to share a link to this community: Disabled

The second setting is particularly important.

When Allow members to share a link to this community is disabled, regular members should not have access to the community’s invitation link. The community owner remains responsible for controlling who can invite new users.

Therefore, I created the following attack scenario:

• Victim: Community owner
• Attacker 1: Regular community member
• Attacker 2: User who is not a member of the community

The objective was to determine whether Attacker 1 could somehow invite Attacker 2 despite not having access to the official invitation link.

As usual, testing the relevant endpoints to determine whether they were vulnerable to privilege escalation was the first thing I did. However, I expected Microsoft’s developers to have already implemented proper server-side authorization for these endpoints, so I didn’t expect to find anything interesting.

I tested several endpoints, including:

• POST /api/mt/beta/join/{communityId} HTTP/2
• PATCH /api/groups/v1/threads/{communityId}/properties HTTP/2 with the request body {"shareJoinLink":true}
• POST /api/groups/v1/threads/{communityId}/joinInvitations HTTP/2 with the request body {"userMris":["8:live:.cid.userId"]}

And yes, all of these endpoints were properly protected and returned a 403 Forbidden response.

The next approach was to understand how the invitation link flow worked. Perhaps I could discover something interesting here.

Normally, a community owner can generate a unique invitation link from the Community Settings, or it will be automatically generated via an email invitation.

When you click the button, you will receive a legitimate invitation link that may look like this:

https://teams.live.com/l/community/FEARNwVT7pgEPFKsQE

This link contains a unique value that acts as the invitation link for the community.

Since all endpoints are well-protected, I therefore started looking for alternative ways to reach the invitation functionality.

During this testing, I discovered that the Microsoft Teams Community invitation flow consists of two steps, based on the request flow:

1. The system generates a unique link https://teams.live.com/l/community/FEARNwVT7pgEPFKsQE. This link is unpredictable, completely unique, and cannot be obtained elsewhere.
2. When the link is opened, it first redirects the user to https://teams.live.com/l/community/invite/<CommunityID> before redirecting them to a launcher.

In other words, the app accepts the link below as an invitation link:

https://teams.live.com/l/community/invite/<CommunityID>

For example:

https://teams.live.com/l/community/invite/19:T_Kng9Z7M0_BgAGFkSPK1hme5f...@thread.v2

This was the interesting part.

The invitation endpoint did not require the unique invitation token generated by the community owner. Instead, the Community ID could be used to construct a valid invitation URL.

As Attacker 1, I intercept the requests generated by Microsoft Teams using Burp Suite. Basically, I just need to interact with the community/group, and the Community ID will appear in the HTTP history.

I locate the request containing the Community ID:

GET /api/chatsvc/consumer/v1/threads/19%3A7qdSepDlm8PFn9tqi-oStAVjcxxxMiiEGMfpmwKVzXZA1%40thread.v2?view=msnp24Equivalent

The Community ID can then be decoded into its readable form. So, it looks like this:

GET /api/chatsvc/consumer/v1/threads/19:7qdSepDlm8PFn9tqi-oStAVjcxxxqMiiEGMfpmwKVzXZA1@thread.v2?view=msnp24Equivalent

Then, I construct the community ID to the following URL:

https://teams.live.com/l/community/invite/19:7qdSepDlm8PFn9tqi-oStAVjcxxxqMiiEGMfpmwKVzXZA1@thread.v2

The important observation is that I did not need to obtain the owner’s unique invitation link.

The next steps:

• I sent the constructed invitation link to Attacker 2, who is not a member of the community.
• Attacker 2 opens the link and accepts the invitation.
• The user is successfully added to the Microsoft Teams Community as a regular member.

This happened even though the community owner had explicitly disabled the ability for regular members to share the community invitation link.

The core problem was not simply that the Community ID was exposed.

The issue was that the same Community ID could be used to construct an alternative invitation URL that bypassed the intended access control mechanism.

The community owner had explicitly disabled:

Allow members to share a link to this community

Therefore, a regular member should not have been able to obtain an alternative mechanism for inviting other users.

The intended flow relied on a unique invitation link generated by the owner. However, the vulnerable endpoint allowed the following predictable relationship:

Community ID -> /community/invite/<CommunityID> -> Valid invitation -> Unauthorized user joins

In other words, the unique invitation link became unnecessary.

An attacker did not need to know the legitimate invitation token. Knowing the Community ID was sufficient to construct another valid invitation URL.

What’s The Impact?

The vulnerability allowed a regular community member to bypass the owner’s invitation restrictions.

An attacker could:

• Invite unauthorized users into a Microsoft Teams Community.
• Bypass the intended invitation-link restriction.
• Allow users who were not authorized by the community owner to gain community membership.
• Gain access to community discussions, meetings, and content available to members.

Not only that, an attacker can rejoin the community at any time as long as they have the Community ID.

The impact could be particularly relevant for communities containing sensitive discussions or information where membership is intended to be controlled by the owner.

Microsoft Response and $5,000 Bounty

I reported the vulnerability to Microsoft through the Microsoft Security Response Center (MSRC).

Microsoft assessed the report as eligible for a $5,000 bounty under the M365 Bounty Program.

The case was classified as:

• Severity: Important
• Vulnerability Type: Permissions, Privileges and Access Controls :: Other Permission, Privilege or Access Control
• Data Classification: 1 — Confidential
• Bounty: $5,000

The vulnerability was subsequently assigned CVE-2025-49731.

Microsoft later confirmed that the fix had been released and that the case was resolved.

Timeline

Also read: $3,133.70 Bounty for Privilege Escalation Vulnerability in Google Search Console (GSC) via DOM Manipulation

This Microsoft Teams community invitation vulnerability was an interesting example of how a seemingly simple identifier can become security-sensitive when it is accepted by an alternative functionality.

When testing a web application, I always try to identify alternative paths to the same functionality. An endpoint that looks unrelated to the normal workflow can sometimes expose a completely different way to bypass an authorization boundary.

Thanks for reading!