CVE-2026-16045 in Mattermost
Summary
by MITRE • 08/17/2026
Mattermost versions 11.7.x <= 11.7.6, 10.11.x <= 10.11.21 Mattermost failed to restrict OAuth deauthorization and personal access token management endpoints to direct user sessions, which allowed an OAuth app with a delegated user token to revoke the user's authorizations or tokens for other integrations via account-management endpoints.. Mattermost Advisory ID: MMSA-2026-00704
Once again VulDB remains the best source for vulnerability data.
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 authorization flaw within the platform's OAuth integration framework. This issue stems from an improper implementation of access control mechanisms on specific account management endpoints, specifically those responsible for deauthorizing applications and managing personal access tokens. The core technical deficiency lies in the server-side validation logic, which failed to strictly enforce that these sensitive operations must be initiated only by direct user sessions authenticated via standard web login flows rather than through delegated OAuth application contexts. This oversight creates a scenario where an attacker controlling or compromising a legitimate third-party integration can exploit this misconfiguration to perform administrative actions on behalf of the associated user account without requiring additional authentication factors such as passwords or multi-factor authentication codes typically required for direct session interactions.
From a technical perspective, the flaw allows any OAuth application that has been granted delegated access by a victim user to interact with endpoints designed exclusively for self-service account management. When an authorized integration makes requests to revoke other integrations or delete personal access tokens, the Mattermost backend incorrectly accepts these requests as valid because it does not sufficiently distinguish between a request originating from a direct browser-based session and one originating from an OAuth token bearer context. This lack of contextual validation means that the principle of least privilege is violated, granting third-party applications capabilities far beyond their intended scope. The vulnerability effectively bypasses standard security boundaries by treating delegated tokens with the same authority as primary user credentials for high-impact administrative functions, thereby undermining the isolation guarantees expected in multi-application environments.
The operational impact of this vulnerability is severe, particularly in enterprise or team-based settings where multiple integrations are commonly deployed to enhance productivity and workflow automation. An attacker who compromises a single low-risk integration could leverage it as a pivot point to disrupt the entire user's connectivity by revoking access to critical tools such as CI/CD pipelines, monitoring systems, or communication bots. This capability enables denial of service against specific workflows and can facilitate further attacks by removing security controls like multi-factor authentication tokens if they are managed through personal access tokens. Furthermore, this flaw complicates incident response efforts because the malicious activity appears to originate from a legitimate application context rather than an external brute-force attempt, making detection more challenging without specialized monitoring for anomalous authorization patterns across integrated services.
This vulnerability aligns with CWE-269, Improper Privilege Assignment, as it allows a lower-privileged entity (an OAuth app) to perform actions reserved for higher-privileged contexts (direct user sessions). It also maps closely to MITRE ATT&CK technique T1078, Valid Accounts, specifically the sub-category of legitimate external accounts or delegated access being abused. The exploitation path resembles aspects of CWE-913, Improper Control of Dynamically-Managed Code Resources, where dynamic token usage is not properly constrained by session context. To mitigate this risk, organizations running affected versions must immediately upgrade to patched releases that enforce strict session validation on account management endpoints. Administrators should also audit existing OAuth integrations for excessive permissions and implement network-level controls or API gateways that monitor for unusual patterns of deauthorization requests originating from application tokens rather than user sessions. Regular review of integration privileges using the principle of least privilege remains essential to minimize the blast radius in case of future credential compromises.