CVE-2026-93846 in Mattermost
Summary
by MITRE • 10/26/2026
Mattermost versions 11.7.x <= 11.7.10 fail to restrict which built-in roles can be assigned to a team member via the API, which allows a team admin to grant a team member permissions beyond those permitted by the configured permission scheme via the {{update-team-member-roles}} REST API.. Mattermost Advisory ID: MMSA-2026-00734
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in Mattermost versions 11.7.x through 11.7.10 represents a critical authorization flaw within the platform's role management subsystem, specifically affecting the API endpoint responsible for updating team member roles. This issue stems from an improper restriction of built-in roles that can be assigned to users via programmatic interfaces. In a properly secured environment, the assignment of administrative or elevated privileges should be strictly governed by predefined permission schemes and access control policies designed to enforce the principle of least privilege. However, in these affected versions, the {{update-team-member-roles}} REST API endpoint fails to validate whether the requested role assignment aligns with the permissions currently permitted for that specific team member under the organization's configured security policy. This oversight allows a user possessing the Team Admin role to bypass intended access controls and grant other users elevated privileges that they should not possess, effectively circumventing the administrative boundaries set by system administrators or compliance frameworks.
From a technical perspective, this flaw constitutes an Insecure Direct Object Reference combined with Broken Access Control vulnerabilities as defined in industry standards such as CWE-284: Improper Access Control and CWE-639: Authorization Bypass Through User-Controlled Key. The root cause lies in the backend logic of the API handler which accepts role identifiers from client requests without sufficiently cross-referencing them against the user's existing permission scope or the team's configured policy constraints. By allowing a Team Admin to assign roles beyond their authorized delegation limits, the system fails to enforce hierarchical trust boundaries. This is particularly dangerous because it enables privilege escalation within the team structure, where an actor with moderate privileges can elevate another account to have administrative capabilities without requiring higher-level approval or audit trails that would typically accompany such significant permission changes.
The operational impact of this vulnerability is severe, as it directly compromises the integrity of access control mechanisms and data confidentiality within Mattermost deployments. An attacker who has compromised a Team Admin account or possesses valid credentials for such an account can exploit this flaw to grant themselves or other malicious actors elevated permissions, including full administrative rights over team channels, files, and user management features. This leads to unauthorized access to sensitive communications, potential data exfiltration, and the ability to manipulate system configurations in ways that could disrupt service availability or expose private information. Furthermore, because these actions are performed via API calls, they may leave fewer visible traces than manual UI interactions, complicating forensic analysis and incident response efforts for security teams relying on standard monitoring tools.
To mitigate this risk, organizations running Mattermost versions 11.7.x through 11.7.10 must immediately upgrade to a patched version where the {{update-team-member-roles}} endpoint has been hardened to enforce strict validation against configured permission schemes. Until an upgrade is feasible, administrators should consider restricting API access for team-level roles or implementing network-level controls such as Web Application Firewalls that monitor and limit role assignment requests based on expected patterns of behavior. Additionally, enabling comprehensive audit logging for all role modification events can help detect unauthorized privilege escalation attempts in real time. Security teams should also review existing user permissions to ensure no accounts have been improperly elevated due to exploitation of this flaw prior to patching. This incident underscores the importance of rigorous input validation and authorization checks on all administrative API endpoints, aligning with ATT&CK technique T1078: Valid Accounts for lateral movement and privilege escalation within enterprise environments.