Mattermost CVE-2026-6689

Exploitation requires an authenticated Mattermost session with the PermissionCreateTeam permission explicitly granted to the user or role. The exploiting user must not hold PermissionInviteUser on the target team (a user who already holds both permissions is authorized to set these fields and is therefore not exploiting a flaw). The bypass is triggered exclusively through the team creation API endpoint POST /api/v4/teams by including allow_open_invite: true and/or a non-empty allowed_domains value in the request body. The PermissionInviteUser check IS correctly enforced on PATCH and PUT (update) paths for existing teams - the missing check is specific to the creation path only. Exploitation does not expose data, does not affect availability, and does not grant the attacker elevated read or administrative access; the sole impact is unauthorized configuration of team invite settings at creation time.

The CVSS 3.1 score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) accurately characterizes the risk: the vulnerability is network-accessible and low-complexity, but requires authenticated access with a specific permission (PR:L), and impacts only integrity at a low level. There is no confidentiality or availability impact. The CVSS correctly reflects a narrow, bounded privilege escalation within the authorization model rather than a broad compromise. No EPSS data was provided; however, the absence of KEV listing and the requirement for a specific authenticated permission set suggest opportunistic or targeted exploitation is unlikely compared to unauthenticated network vulnerabilities. The real-world risk is context-dependent: in organizations that rely on AllowedDomains or invite-only team controls as a security boundary (e.g., regulated industries, multi-tenant deployments, or environments where team visibility controls enforce data segregation), this flaw could undermine a meaningful access control. In loosely governed deployments where all authenticated users can create teams freely, the practical impact is minimal. No conflicting signals were identified between CVSS vector and description.

An authenticated Mattermost user who holds PermissionCreateTeam but not PermissionInviteUser crafts a POST request to /api/v4/teams with the body fields allow_open_invite set to true and allowed_domains set to a target domain. Because the server does not invoke the PermissionInviteUser check on the creation path, the API accepts the request and provisions a team with open-invite and domain-restriction settings the user is not authorized to configure. The resulting team is publicly joinable by anyone matching the specified domain, bypassing the organization's intended membership control policy without any server-side rejection.