CVE-2026-6689: Mattermost Permission Bypass in Team Creation
Mattermost has a permissions bypass vulnerability affecting multiple versions where authenticated users with team-creation rights can inappropriately configure invitation settings during team setup. Specifically, users lacking the PermissionInviteUser permission can set AllowOpenInvite (making a team publicly joinable) and AllowedDomains (restricting team membership to specific domains) during POST-based team creation—settings they would normally be blocked from configuring on existing teams. The vulnerability requires an authenticated account and results in unauthorized configuration of team access controls, not data disclosure or system failure.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 4.3 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
- Weaknesses (CWE)
- CWE-862
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-12 / 2026-06-18
NVD description (verbatim)
Mattermost versions 11.6.x <= 11.6.1, 11.5.x <= 11.5.4, 10.11.x <= 10.11.15, 10.11.x <= 10.11.16 Fail to enforce PermissionInviteUser when setting AllowOpenInvite or AllowedDomains during team creation (the check was only applied on update/patch), which allows an authenticated user holding PermissionCreateTeam but not PermissionInviteUser on the resulting team to configure invite-controlled team settings (make the team publicly joinable via open invite and/or constrain membership via allowed domains) that they are not permitted to set on an existing team via POST /api/v4/teams with allow_open_invite: true and/or a non-empty allowed_domains in the request body.. Mattermost Advisory ID: MMSA-2026-00655
1 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-6689 exploits a logic flaw in Mattermost's permission enforcement layer. The PermissionInviteUser check is applied only during team updates (PATCH operations) but not during initial team creation (POST operations). An attacker holding PermissionCreateTeam can pass allow_open_invite: true or a non-empty allowed_domains array in the POST /api/v4/teams request body to bypass the permission gate. The vulnerability spans versions 11.6.x (≤11.6.1), 11.5.x (≤11.5.4), and 10.11.x (≤10.11.16), indicating a regression or incomplete security control implementation across a wide release window. The underlying root cause is asymmetric permission validation between create and update code paths.
Business impact
This vulnerability allows privilege escalation within a Mattermost deployment. A user with team-creation permissions but without invitation-management permissions can unilaterally control team joinability and domain membership policies. In organizations that rely on Mattermost for internal communication, this enables unauthorized changes to team access controls, potentially exposing sensitive channels to unintended members or locking out legitimate ones. The impact is heightened in multi-tenant or federated deployments where teams represent distinct organizational units. However, the risk is contained to the authenticated user's team configuration authority—there is no data exfiltration or system-wide compromise.
Affected systems
Mattermost Server is affected across multiple recent versions: 11.6.x up to and including 11.6.1, 11.5.x up to and including 11.5.4, and 10.11.x up to and including 10.11.16. Organizations running any of these versions in production are potentially vulnerable if they grant team-creation permissions to users who should not have invitation-control authority. Verify your deployed version via the System Console (Administration → About) and cross-reference against these affected ranges. Notably, the vulnerability spans both recent (11.x) and earlier long-term support (10.11.x) release lines.
Exploitability
Exploitation requires valid Mattermost credentials and at least PermissionCreateTeam on a workspace. No network-level authentication bypass is needed. The attack is straightforward: submit a POST request to /api/v4/teams with allow_open_invite or allowed_domains set, and the permission check will not trigger. The vulnerability is not listed on CISA's KEV catalog, suggesting no evidence of active weaponization in the wild as of the advisory date. However, the ease of exploitation (single API call with no special conditions) means that any insider threat with team-creation privileges poses an immediate risk. The CVSS 3.1 score of 4.3 (MEDIUM) reflects the requirement for authentication and the limited scope (integrity impact only, no confidentiality or availability impact).
Remediation
Upgrade to patched versions immediately. Consult the Mattermost security advisory (MMSA-2026-00655) for specific fixed versions. In the interim, restrict PermissionCreateTeam to users and roles that also hold PermissionInviteUser, or implement organizational policy ensuring that team creators do not modify team access settings post-creation. Monitor team creation and configuration logs for suspicious activity. Organizations unable to patch quickly should review role-based access control (RBAC) assignments to minimize the number of users holding the CreateTeam permission without corresponding invitation privileges.
Patch guidance
Visit the Mattermost security advisories page and reference MMSA-2026-00655 to identify the fixed version for your release line (11.6.x, 11.5.x, or 10.11.x). Mattermost typically provides patches on a regular cadence; upgrade as soon as the patched version is available for your support lifecycle. Test the upgrade in a staging environment first to validate compatibility with custom integrations or plugins. The advisory publication date is 2026-06-12, so fixed builds should be available shortly thereafter. Check your Mattermost subscription portal for automated update notifications.
Detection guidance
Audit team creation API calls (POST /api/v4/teams) in your Mattermost logs and look for requests that include allow_open_invite: true or non-empty allowed_domains values, especially when originating from users without PermissionInviteUser. Configure webhooks or SIEM integrations to alert on team configuration changes that conflict with expected policy. Review team settings in the System Console → Teams section for unexpectedly permissive joinability settings on teams created during the vulnerability window. Correlate recent team creator accounts with their assigned permissions to identify potential exposure.
Why prioritize this
Although assigned a MEDIUM CVSS score, this vulnerability should be treated as a near-term patch candidate because it enables unauthorized delegation of access-control authority to team members. In environments where team structure maps to business function or data classification, misconfiguration of invitation settings can have outsized organizational impact. The wide range of affected versions (10.11.x through 11.6.x) suggests a systemic permission-check oversight rather than an edge case, increasing the likelihood that multiple teams have been affected if the vulnerability has been exploited. The fact that no KEV listing exists does not lower urgency; CISA KEV status reflects active exploitation in the wild, not vulnerability severity.
Risk score, explained
The CVSS 3.1 score of 4.3 reflects: (1) low attack complexity—a simple API call with no race conditions or special preconditions; (2) requirement for authentication (PR:L); (3) no confidentiality or availability impact; (4) low integrity impact limited to team-level settings. The score appropriately penalizes the attack for requiring valid credentials, but does not fully capture the organizational risk of permissive team access in communication-critical infrastructure. Risk context should account for your deployment's role-based access control maturity and the sensitivity of teams in scope.
Frequently asked questions
Do I need to revoke all team-creation permissions immediately?
Not necessarily, but you should audit which users or roles hold PermissionCreateTeam without PermissionInviteUser, and prioritize patching before reassigning team creation rights. If your access control model already pairs these permissions, your exposure is limited to the already-created teams. However, any new team creation during the vulnerable window by a user lacking PermissionInviteUser should be reviewed.
Can this vulnerability be exploited by an unauthenticated attacker?
No. The vulnerability requires a valid Mattermost user account with at least PermissionCreateTeam. Unauthenticated attackers cannot exploit it. However, any legitimate team-creator account that lacks PermissionInviteUser becomes a potential vector if compromised or if the user has malicious intent.
Does this affect Mattermost Cloud deployments?
Mattermost Cloud customers should check their current server version and consult Mattermost's cloud upgrade schedule. Cloud deployments typically receive patches on a faster cadence than self-hosted instances. Contact Mattermost support if your cloud workspace is running an affected version.
What should I do if I discover a team with unexpectedly permissive settings created during the vulnerable window?
Review the team creator's account and permissions. If the creator should not have had invitation-control authority, treat it as a potential unauthorized configuration and re-restrict the team's joinability settings. Update your team access control policy to enforce alignment between team creation and invitation permissions going forward.
This analysis is based on publicly available information from the Mattermost security advisory (MMSA-2026-00655) and the CVE record as of the advisory publication date (2026-06-12). Patch availability, version numbers, and specific remediation steps should be verified directly against the official Mattermost security advisory and your vendor communications. SEC.co does not provide legal, compliance, or operational technology advice; organizations should validate applicability and impact within their own environments before implementing changes. This vulnerability requires valid Mattermost credentials and does not represent a zero-day or uncontrolled exploit risk as of publication. Source: NVD (public-domain), retrieved 2026-07-20. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2022-42479MEDIUMMissing Authorization in TemplateHouse Soledad – MEDIUM Severity Access Control Bypass
- CVE-2022-45813MEDIUMBeRocket Advanced AJAX Product Filters Missing Authorization Flaw
- CVE-2023-25969MEDIUMMissing Authorization in ThemeHunk Contact Form Plugin
- CVE-2023-32959MEDIUMMetroStore Missing Authorization Vulnerability – Patch Guide
- CVE-2025-12714MEDIUMRank Math SEO Plugin Unauthenticated Metadata Injection Vulnerability
- CVE-2025-52766MEDIUMMissing Authorization in Printeers Print & Ship – CVSS 6.5
- CVE-2025-53302MEDIUMMissing Authorization in Anton Shevchuk Constructor Framework
- CVE-2025-53346MEDIUMMissing Authorization in ThimPress Thim Core 2.3.3