What is the CVSS score of CVE-2026-6689?

CVE-2026-6689 has a CVSS 3.1 base score of 4.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N. EPSS exploitation probability: 0.0%.

Mattermost CVE-2026-6689

EUVD-2026-36501 MEDIUM

Missing Authorization (CWE-862)

2026-06-12 Mattermost

GHSA-c28q-m4gf-vg4q

Authentication Bypass Mattermost

4.3

CVSS 3.1 · Vendor: Mattermost

Severity by source

Vendor (Mattermost) PRIMARY

4.3 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

vuln.today AI

4.3 MEDIUM

Network-accessible API requiring low-privilege authentication (PR:L); integrity-only impact as only invite configuration is affected, with no data exposure or service disruption.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (Mattermost).

CVSS VectorVendor: Mattermost

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 12, 2026 - 17:35 vuln.today

DescriptionCVE.org

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

AnalysisAI

Mattermost's team creation API endpoint (POST /api/v4/teams) fails to enforce the PermissionInviteUser authorization check, allowing authenticated users holding only PermissionCreateTeam to configure invite-controlled team settings - including making a team publicly joinable via open invite and restricting membership by allowed domains - that they are explicitly prohibited from setting on existing teams. Affected versions span the 10.11.x, 11.5.x, and 11.6.x release trains up to their respective latest builds. No public exploit identified at time of analysis, and the flaw has not been listed in CISA KEV.

Technical ContextAI

Mattermost is a self-hosted and cloud-deployed team collaboration platform with a granular, role-based permission system. The REST API exposes team management via POST /api/v4/teams (creation) and PATCH/PUT endpoints (update). The platform distinguishes PermissionCreateTeam, which governs the ability to instantiate a new team, from PermissionInviteUser, which governs the ability to configure how users may be invited or admitted to a team. The fields AllowOpenInvite (makes a team publicly discoverable and joinable without an explicit invitation) and AllowedDomains (restricts membership to specified email domains) are invite-related settings that should require PermissionInviteUser. The root cause is CWE-862 (Missing Authorization): the PermissionInviteUser check was implemented on the update/patch code path but was entirely omitted from the creation code path. This is a classic authorization inconsistency across alternate execution paths - the same business logic constraint was not uniformly enforced across all API surfaces that mutate the same data. CPE: cpe:2.3:a:mattermost:mattermost:*:*:*:*:*:*:*:*.

RemediationAI

Upgrade Mattermost to a version beyond the affected ranges (past 11.6.1, 11.5.4, or 10.11.16 as applicable to the installed release train) per Mattermost advisory MMSA-2026-00655 at https://mattermost.com/security-updates. Exact patched release version numbers are not specified in the available advisory data and should be confirmed directly from the vendor before deployment. As a compensating control pending upgrade, administrators should audit and restrict the PermissionCreateTeam grant to only highly trusted users or dedicated service accounts - this shrinks the population of principals who could exploit the bypass, though it may constrain legitimate team creation workflows. Additionally, administrators should audit all teams created on affected versions to verify that AllowOpenInvite and AllowedDomains settings reflect intended organizational policy, as any team created during the vulnerable window by a user without PermissionInviteUser may have unauthorized invite settings.