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

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

Mattermost CVE-2026-9571

EUVD-2026-43305 MEDIUM

Authentication Bypass by Primary Weakness (CWE-305)

2026-07-13 Mattermost

GHSA-4v7j-4mvr-5975

Information Disclosure Mattermost

6.5

CVSS 3.1 · NVD

Severity by source

Vendor (Mattermost) PRIMARY

MEDIUM

qualitative

NVD

6.5 MEDIUM

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

vuln.today AI

6.8 MEDIUM

AV:N for network-accessible OAuth endpoint; AC:H for token-retention precondition; PR:L because the attacker was a regular user, not an administrator.

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

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

Primary rating from Vendor (Mattermost).

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

CVSS changed

Jul 13, 2026 - 21:52 NVD

5.9 (MEDIUM) 6.5 (MEDIUM)

Analysis Generated

Jul 13, 2026 - 09:01 vuln.today

DescriptionNVD

Mattermost versions 11.7.x <= 11.7.2, 11.6.x <= 11.6.4, 10.11.x <= 10.11.19 fail to invalidate OAuth refresh tokens upon user account deactivation, which allows a deactivated user or an attacker in possession of a valid refresh token to obtain new functional access tokens via the OAuth refresh token grant endpoint.. Mattermost Advisory ID: MMSA-2026-00680

AnalysisAI

Mattermost fails to invalidate OAuth refresh tokens when a user account is deactivated, enabling former users - or any attacker who possesses a valid refresh token - to continue minting functional access tokens against the OAuth refresh token grant endpoint indefinitely after access revocation should have taken effect. All three actively maintained release branches are affected (10.11.x, 11.6.x, 11.7.x), making this a cross-branch session-persistence flaw with high confidentiality and integrity impact on any workspace relying on OAuth-integrated access control. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, though the attack path requires minimal skill for any party already holding a refresh token.

Technical ContextAI

Mattermost is an open-source team messaging and collaboration platform (CPE: cpe:2.3:a:mattermost:mattermost). Its OAuth 2.0 implementation issues refresh tokens - long-lived credentials designed to regenerate short-lived access tokens - to authenticated clients. CWE-305 (Authentication Bypass by Primary Weakness) describes the root cause: the primary authentication control (account deactivation) fails to cascade into revocation of derived credentials (refresh tokens). In a correct implementation, deactivating a user account should atomically invalidate all associated sessions, access tokens, and refresh tokens stored server-side. Mattermost instead leaves refresh tokens valid, meaning the OAuth /oauth/token endpoint with grant_type=refresh_token continues to issue new bearer tokens for deactivated accounts. This is a classic session-persistence flaw where token lifecycle management is decoupled from identity lifecycle management.

RemediationAI

Patch available per vendor advisory at https://mattermost.com/security-updates (MMSA-2026-00680). Administrators should upgrade beyond the affected version ceiling in their respective branch - 10.11.19, 11.6.4, or 11.7.2 - to a patched release as soon as available. Exact fix versions are not independently confirmed from the provided data; consult the Mattermost security updates page directly to identify the specific patched build for your branch. As an immediate compensating control, administrators can manually audit and revoke active OAuth application authorizations for deactivated users through the Mattermost System Console (System Console > Integrations > OAuth 2.0 Applications), or delete and recreate the affected user accounts (deletion, unlike deactivation, may purge token state - verify behavior in your version). Disabling OAuth 2.0 entirely for external integrations eliminates the attack surface but will break any OAuth-dependent integrations; evaluate this trade-off based on organizational OAuth usage before applying.