CVE-2026-8821 in Mattermost
Summary
by MITRE • 09/14/2026
Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.7, 10.11.x <= 10.11.22 fail to validate channel member-management permission during playbook run creation, allowing an authenticated channel member to add an arbitrary user to a restricted channel via the run owner field.. Mattermost Advisory ID: MMSA-2026-00677
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in Mattermost versions 11.9.x through 11.8.4, as well as earlier branches including 11.7.x up to 11.7.7 and 10.11.x up to 10.11.22, represents a critical authorization bypass within the platform's playbook execution framework. This flaw stems from an insufficient validation of channel member-management permissions when initiating a new playrun. In standard Mattermost operations, restricted channels enforce strict access controls that prevent users without specific administrative privileges from adding members or modifying membership lists. However, during the creation of a playrun, which is a structured workflow for managing incidents or projects within a channel, the application fails to verify whether the authenticated user possesses the requisite permissions to modify the member list before accepting input for the run owner field.
Technically, this defect allows an authenticated channel member who lacks explicit permission to manage members in a restricted channel to bypass these restrictions by specifying an arbitrary external or internal user as the playrun owner. The system accepts this designation without cross-referencing it against the channel's membership policy or the requesting user's privilege level. By setting another user as the run owner, the attacker effectively grants that target user access to the restricted channel context associated with the playbook execution. This mechanism circumvents the intended security boundary because the playrun creation process is treated as a distinct action from direct member management, yet it results in the same outcome of unauthorized membership expansion. The vulnerability exploits the logical separation between workflow initiation and permission enforcement, where the latter is not adequately applied to inputs that alter channel access dynamics.
The operational impact of this vulnerability is significant for organizations relying on Mattermost for secure collaboration within sensitive or private channels. An attacker with a basic authenticated account in a restricted channel can escalate their privileges indirectly by forcing the inclusion of another user who may have higher clearance levels, thereby potentially exposing confidential information to unauthorized parties. Alternatively, if the target user added has lower privileges, it could be used to create confusion or facilitate further social engineering attacks within the workspace. This behavior aligns with CWE-269, which describes Improper Privilege Assignment, as well as CWE-862, Missing Authorization Check, since the application fails to enforce access control on a critical action that modifies channel membership state. From an offensive security perspective, this technique is consistent with ATT&CK T1078, Valid Accounts, specifically in the context of using legitimate credentials to gain unauthorized access through logical flaws rather than credential theft or exploitation of software bugs in authentication mechanisms.
Mitigation for this issue requires immediate patching to the latest stable release of Mattermost that includes the fix referenced in Advisory MMSA-2026-00677. Administrators should verify their current version and upgrade promptly, as automated exploits may target known vulnerable instances once details are publicized. In environments where upgrading is not immediately feasible, temporary mitigations include restricting playbook creation permissions to only those users who already possess channel management privileges, thereby reducing the attack surface for this specific bypass. Additionally, implementing strict monitoring of playrun creation events in restricted channels can help detect anomalous activity indicative of exploitation attempts. Long-term architectural improvements should involve enforcing permission checks at a lower level within the API layer that handles all membership-related operations, ensuring that any action resulting in channel state changes undergoes uniform validation regardless of the entry point used by the client application.