CVE-2026-16046 in Mattermost
Summary
by MITRE • 08/17/2026
Mattermost versions 11.7.x <= 11.7.6, 10.11.x <= 10.11.21 fail to enforce run-state validation on write operations for finished playbook runs which allows a run participant to modify status, checklists, retrospective content, ownership, and participants on completed runs via REST and GraphQL API requests. Mattermost Advisory ID: MMSA-2026-00675
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in Mattermost versions 11.7.x through 11.7.6 and 10.11.x through 10.11.21 represents a critical failure in access control logic, specifically categorized under CWE-862 Missing Authorization. This flaw occurs within the backend handling of playbook run operations, where the application fails to verify whether a specific playrun has reached its final state before permitting write actions. In normal operational workflows, once a playbook is marked as finished or completed, it should transition into a read-only mode for participants who are not designated administrators or owners with explicit override permissions. However, due to this validation gap, the system continues to accept and process modification requests against these finalized records via both REST and GraphQL API endpoints.
The technical root cause lies in the absence of state-based permission checks during the execution of update operations. When a user submits an HTTP request to modify attributes such as status, checklist items, retrospective content, ownership assignments, or participant lists for a completed run, the server-side logic does not adequately cross-reference the current lifecycle stage of that playrun against the permissions associated with the requesting actor. This allows any authenticated participant who has access to view the finished playbook to alter its metadata and contents. The exploitation vector is straightforward, requiring only standard API calls which are easily automated or scripted by an attacker possessing valid credentials for a lower-privilege role within the workspace.
The operational impact of this vulnerability is significant regarding data integrity and auditability. Playbooks in Mattermost serve as structured workflows for incident response, project management, and process execution, often containing sensitive information about organizational procedures, personnel assignments, and post-mortem analyses. By allowing unauthorized modifications to completed runs, an attacker can alter the historical record of events, potentially covering up mistakes or fabricating outcomes. This undermines the reliability of retrospective data used for continuous improvement and compliance reporting. Furthermore, changing ownership or participant lists on a finished run could disrupt accountability structures established during the active phase of the playbook, leading to confusion in future audits or legal reviews where accurate chain-of-custody for digital evidence is required.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK technique T1078 Valid Accounts, as it leverages legitimate user credentials to perform unauthorized actions, and potentially T1534 Internal Spearphishing if the modified data is used to deceive other stakeholders about the state of a resolved incident. The ability to modify retrospective content specifically poses risks related to information manipulation, which can affect decision-making processes based on flawed post-incident reviews.
To mitigate this risk, organizations running affected versions must immediately upgrade Mattermost to version 11.7.7 or later, where the run-state validation logic has been corrected to enforce strict read-only access for completed runs unless explicitly overridden by appropriate administrative privileges. Until an upgrade is feasible, administrators should consider restricting API access policies and monitoring logs for unusual patterns of write operations on closed playruns. Additionally, reviewing existing playbook configurations to ensure that sensitive retrospective data is not overly accessible can help limit the blast radius if exploitation occurs in unpatched environments. Regular security audits focusing on authorization checks across all state transitions are recommended to prevent similar logic flaws in other modules.