Taking Over Files in a chat —IDOR in Microsoft Teams

Out of curiosity, I started looking into the file uploading process in the browser version of Microsoft Teams. Found a couple of IDORs in a single endpoint and some leaks in another. Combining both, I found that it is possible for a user to delete what other users upload, give arbitrary ownership, and even change the content of any file being uploaded, ie. full takeover.

Let me walk you through the attack scenarios..


When you upload a file to a Microsoft Teams chat, a couple of requests will be issued. For our attack scenarios, we will be focusing on 2 main endpoints:

  1. Endpoint A, responsible for PUTing the data related to the uploaded file:

This endpoint request contains some interesting params such as:

2. Endpoint B, responsible for retriving info related to the available files in a chat:

This endpoint response contains some interesting params such as:

Attack Narrative:

  1. Targeting “imidisplayname” — Change file ownership (self):

Status: Unpatched — this still works as of the day of this writing.

From Endpoint A, lets focus on “imidisplayname” param:

This value is being reflected in the files details in the chat:

Changing this value to anything will be successful:

To confirm that the value is also changed for the referenced object, if we check Endpoint B we can see that it has been changed successfully:

2. Targeting “imidisplayname” — Change file ownership (others’ files):

Status: patched.

Checking other uses’ uploaded files for a different chat in the web application, we can see only 1 file uploaded by user “Greg xxx”:

Via Endpoint B, we can retrieve the “itemid” for this file:

From Endpoint A, we craft a similar request but with the grabbed values for “id” and “itemid”. Those two params are the ones responsible for referencing the uploaded file as mentioned earlier.

We can confirm that the change took place, moreover, the file itself has been overridden— no other files appear on the list except our file:

3. Targeting “itemid” and “fileUrl”— Takeover files (same chat):

Status: patched.

As shown in the previous scenario, we already caused this accidently when attempting to change the file owner (diplay name).

To clarify more, notice the “fileurl” variable which basically fetches the file content whenever the image is being loaded:

Submitting the PUT request of Endpoint A with a new “fileUrl” value and the “itemid” of the other users’s uploaded file will make the application override this file with the new data. At this point file deletion, as well as changing file content is possible:

4. Targeting “itemid”, “fileUrl”, “ThreadId” — Takeover files (different chat):

Status: patched.

From Endpoint B, we can see that among the details of the uploaded file we have a “ThreadID” value:

Via Endpoint A, if we change the “<thread_id>” to this value, we can do all the previously mentioned scenarios for other chats as well.


A user can delete what other users upload, give arbitrary ownership, and even change the content of any file being uploaded, ie. full takeover.

Reporting Timeline:

28 April 2020 — Reported

29 April 2020 — Rejected because its considered a “social engineering” or “man in the middle” attack:

29 April 2020 — Re-reported with tackling the mentioned points:

One month later I didn’t receive anything, so I asked for an update.

20 May 2020 — Update:

2 June 2020 — Rejected because “it does not meet the bar for servicing”,
worth noting that I had 0 views on my 2 PoC videos after being asked to re-upload them.

16 June 2020 — Clarification for the rejection of the report:

TL;DR Altering the value of “message.properties.file” property for another user is not considered a security risk.

29 June 2020 — Public disclosure permission granted.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store