Security advisory: Mattermost Mobile for iOS v1.31.0 Authentication Token Leakage and Account Takeover

security research, advisory, vulnerability, mattermost
Advisory information

Title: Mattermost Mobile for iOS Authentication Token Leakage and Account Takeover
Advisory reference: BLAZE-05-2020
Product: Mattermost Mobile Client for iOS v1.31.0 (Build 293)
CVE reference: CVE-2020-13891
Vendor reference: MMSA-2020-0022
Disclosure mode: Coordinated disclosure

Product description

Mattermost is a flexible, open source messaging platform that enables secure team collaboration. The product is used in several enterprises as a self-hosted, on-premise alternative to Slack and other messaging workspace.

According to Mattermost, it is "so secure that influential countries use it as a safeguard to national security".

Organizations that use Mattermost include Daimler, Intel, Uber, CERN, Bosch, NASA's JPL, Samsung, Valve, etc. (for more customers see

Vulnerability details

In order to make formatting of chat messages more convenient, Mattermost provides Markdown as part of its core functionality. Operating with Markdown syntax opens the door to a wide collection of possibilities such as text styling, insertion of code blocks, tables, item lists and more [1].

Additionally, the Mattermost client is also capable of rendering images by making use of the usual and well known Markdown syntax '![{alt text}]({URL of image} “{Hover text}”)' [2]. The images are loaded on public/private channels or direct messages where the Markdown image declaration is posted. This triggers the Mattermost client application to perform a GET request to the specified URL in order to fetch media content, which request is sent directly to the hosting server if no image proxy is enabled.

By manipulating the image source URL and analyzing the behavior, Blaze Information Security team found an unknown security breach exploitable on the iOS mobile application - the HTTP Authorization header, which contains the Bearer authentication token, is sent along with the GET request to arbitrary 3rd party hosts upon image load via a Markdown payload.

With this knowledge, the Markdown image feature can be abused by the media hosting servers themselves or rogue users (even guests [3]) without any interaction of the victims and provide a badly intentioned agent means to materialize a range of different attack scenarios, for example:

Sensitive Information Exposure

Steps to reproduce:

  1. Setup a simple socket listener with ncat/netcat as follows:
ncat -lkvvp 1337 2>&1 | tee --append received_connections.txt

Or just simply:

ncat -lp 1337
  1. Post the following payload in whatever chat conversation where the victims are present and fill in the placeholders (marked with '<>'s):
  1. Wait for the victims to open the chat where the payload was posted

  2. Check the listener inbound connections and look for 'Authorization: BEARER' just like in the example bellow (sensitive information was censored with 'x's due to privacy concerns):

Ncat: Connection from
Ncat: Connection from

GET /pwnd HTTP/1.1
Accept-Encoding: gzip, deflate
Connection: keep-alive
Accept: image/*,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_4_1 like Mac OS X) AppleWebKit/x.x.x (KHTML, like Gecko) Mobile/xxxxxx
Authorization: BEARER xxxxxxxxxxxxxxxxxxxxxxxxxx
X-Requested-With: XMLHttpRequest

For the sake of this simple example, with the shown ncat setup, no response will be sent to the client, but it is possible to do so in order not to bring any suspicions so the attack can be conducted covertly.

The video below exposes the first phase of exploitation by triggering the vulnerability that leads to the leakage of the authentication token through the Markdown payload.

In this case the victim is Gordon, the CEO of the company who happens to be the System Admin in Mattermost.

In order to perform the attack covertly, an image is served back to the Mattermost client application on the private channel "Security Posture Review" (e.g. using a PHP simple server) so it renders nicely in the interface, not lifting any suspicions of an attack. TShark is, in this case, the responsible for sniffing the HTTP network traffic on the chosen port. Finally, the token is retrieved from the GET request performed by Gordon's iOS application and stored in a variable to be used in the second phase.

Account Takeover / Impersonation

By collecting the Bearer token using the above explained it's now possible to perform authenticated requests to the Mattermost API on the victim's behalf. With this in mind an attacker gains almost full control over the victim's account and it's limited only by the requests where extra unknown authentication information is required (e.g. current password).

Denial of Service

By exploiting the last two scenarios the attacker also has the possibility to disable other user's accounts given that the compromised token is from a privileged user [4]. With this the attacker can deny access to every user.

The next video covers the second phase of the exploitation where the account takeover actuary takes place by using the authentication token, collected previously, to make authenticated calls to the Mattermost API.
To prove the impact of this vulnerability, after collecting all the information required (Users, Team and Channel IDs), Gordon's private chat with Kelly is read and Kelly's account is disabled in the end making it impossible for her to log back in.

Fix and recommendations

Upgrade Mattermost iOS application to the latest available version.


This vulnerability was discovered and researched by Jorge Ferreira from Blaze Information Security (, with help from Julio Fort and Wilberto Filho.

Disclosure timeline

22/05/2020: Issue discovered, reproduced and exploited by Blaze Information Security
23/05/2020: Mattermost informed about the vulnerability
24/05/2020: Mattermost responds saying they were not able to reproduce the vulnerability
24/05/2020: Blaze describes the exact steps and versions tested as well as those found to be affected
25/05/2020: The product security team of Mattermost confirms the vulnerability
16/06/2020: Security advisory MMSA-2020-0022 disclosed
20/07/2020: Blaze publishes the advisory