Mattermost Privilege Escalation — A Business Acceptable Risk?

Mattermost Privilege Escalation — A Business Acceptable Risk?

I recently discovered a Broken Access Control vulnerability (most critical issue within the OWASP Top 10 list) in Mattermost, that allows for privilege escalation. A user with the System Manager role, or one user with a manually granted sysconsole_write_user_management_permissions permission, can abuse this finding to elevate their privileges and access functionalities meant only for System Administrator users.

In self-hosted Mattermost instances where plugin uploads are enabled, this could lead to remote command execution. The issue was promptly reported through a bug bounty platform to the vendor (Mattermost), which ultimately classified this issue as a “Business Acceptable Risk”.

This post aims to inform customers and users of this platform about this issue, its actual risk and impact, as neither the application documentation nor the API docs mentions about this being an accepted risk or “hidden” functionality. In fact, the API documentation states that the affected endpoint is indeed only accessible to users with manage_system permissions — which I will demonstrate is actually not necessary.

Technical Details:

Mattermost allows granular permission settings for different roles. I discovered that if a user has the sysconsole_write_user_management_permissions permission, they can elevate their own privileges to access functionalities that would normally be restricted. For example, the System Manager role includes this permission, but by default, it cannot access certain functionalities like Reporting, Authentication, Integrations, Plugins, and Compliance. The following images demonstrate that the System Manager role has the Permissions setting enabled for editing, while the previously mentioned functionalities remain disabled by default.

System Manager user permissions.
System Manager user permissions.
System Manager user allowed functionalities.

While logged into the UI as a user with the System Manager role, I observed that the functionality only allows editing permissions related to channels, teams, and channel settings. These do not grant access to other functionalities.

Permissions UI functionality.

For example, with a user logged in as System Manager, the signup functionality is greyed out, and editing is not allowed.

While analysing the application, I found that a user with the sysconsole_write_user_management_permissions permission, granted by default to the System Manager role, can modify roles like system_user to add permissions and gain access to additional functionalities.

This is done through the /api/v4/roles/{role_id}/patch endpoint. However, the Mattermost API documentation states that this endpoint requires the manage_system permission, as shown in the following image.

Mattermost API documentation.

As shown in the following HTTP request/response pair, it can be seen that the manage_system permission is not assigned to the system_manager role:

If a user with the sysconsole_write_user_management_permissions permission tries to modify the system_managersystem_user_manager, or system_read_only_admin roles, an error occurs stating that the account lacks the appropriate permissions.

Permission error when trying to modify specific roles

However, a user with the sysconsole_write_user_management_permissions permission or the System Manager role can edit the system_user role, effectively escalating privileges for all registered users.

I created a Python script to test which permissions can be assigned or not, and I identified the following permissions that cannot be set:

The permissions that can be set using this vulnerability are:

To exploit this vulnerability as a System Manager user, we first retrieve the ID of the system_user role.

As shown in the response, the ID is wnbbfpf6etfgunkbk76mk19wfy. However, this ID varies with each installation.

As shown in the response, the ID is wnbbfpf6etfgunkbk76mk19wfy. However, this ID varies with each installation.

Then send a request to the endpoint /api/v4/roles/{RoleID}/patch, replacing {RoleID} with the role ID from the previous request.

In the following request/response pair, I added all the allowed permissions to the system_user role.

The following image shows that a user with the System Manager role cannot access certain functionalities, including user administration, as these permissions are not granted by default.

After modifying the permissions, users with the System Manager role (and all users) can access almost all functionalities, including user management, as shown in the following images.

Business Impact:

The Permissions privilege in the UI may seem harmless, as it is meant for managing team, group, and channel permissions — not server configurations. A Mattermost system administrator might grant this privilege thinking it’s safe, but as shown in the PoC, it can be exploited for privilege escalation.

While I couldn’t assign the system_admin role to my user, the escalation allows performing nearly all system admin actions, except changing system admin roles, resetting their passwords, or deleting them. However, it does allow:

  • Deleting all other users
  • Accessing compliance data
  • Disable MFA for all users
  • Achieving remote command execution if plugin uploads are enabled in the config file.
  • Etc…

Below is the response from the Bugcrowd team stating that the Mattermost team marked this issue as a Business Acceptable Risk.

However, the documentation does not mention this risk anywhere:


In fact, the API documentation lists several endpoints as requiring the manage_system permission, but this is incorrect – take for instance, the upload plugin endpoint:

Bonus, Remote Command Execution:

I often joke around that if a vulnerability doesn’t allow for Remote Command Execution (RCE), then it’s not worth it – No RCE, No Glory! = P

However, jokes aside, this vulnerability can certainly lead to command execution if the Mattermost instance is self-hosted and plugin uploads are enabled in the configuration file.

As a Proof-of-Concept, I modified the demo plugin provided by Mattermost. Here’s the process:

  1. Decompress the plugin.
  2. Replace the init binary with one that executes whoami, uname -a, and ls -lah commands, sending the output to a netcat listener.
  3. Recompress the plugin, upload it, and enable it.

Once the plugin is uploaded, the Enable Plugin button doesn’t appear in the UI because the user doesn’t have the manage_system permission.

Remember, this is a business accepted risk, and the user I used to exploit the privilege escalation can always just use the API to enable the plugin — because who needs UI buttons when you have direct access, right?

And just like that, Boom! The results are now received in my netcat listener:

Conclusions:

From a threat model perspective, I don’t think it makes sense to classify this finding as an “accepted business risk” given such an impact when abused. This post is to inform Mattermost users and customers about this vulnerability, so they can take necessary precautions and stay informed about how Permissions work in Mattermost — cannot always rely on the documentation…