Mattermost EUVD-2026-102747

Exploitation requires the attacker to already hold a valid OAuth bearer token for the specific target user AND the target account must be SSO/identity-provider-backed, since the attack abuses the account-type switch endpoint (POST /api/v4/users/login/switch) to convert SSO to password auth. The flaw is that OAuth application sessions are not rejected by this endpoint. Limiting factors: this is not reachable by a fully unauthenticated attacker (PR:H - a victim-scoped OAuth token is mandatory), attack complexity is high (AC:H), and only Mattermost versions in the listed vulnerable ranges with OAuth/SSO integration enabled are affected; deployments not using SSO-backed accounts or OAuth applications are not exposed.

This is a moderate-severity authorization flaw (CVSS 4.4, CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N; CWE-863 Incorrect Authorization) that reads as a genuine account-takeover primitive but with meaningful exploitation barriers. The network attack vector (AV:N) is offset by high attack complexity (AC:H) and high privilege requirement (PR:H): the attacker must already possess a valid OAuth bearer token scoped to the specific target user. The impact profile is integrity-only (I:H, C:N, A:N), which correctly reflects that the bug permits permanent takeover of the victim's SSO-backed account rather than data disclosure or disruption. No EPSS score, no SSVC decision, and no KEV listing were provided in the input, and no public exploit is identified, so there is no signal of active or widespread exploitation - this is a vendor-reported (Mattermost) issue, not one with demonstrated in-the-wild activity. The signals are internally consistent rather than conflicting: a network-exploitable but token-gated, high-complexity integrity bug. Verdict: this is a credible fix-on-schedule authorization defect, not an emergency; the realistic priority depends entirely on whether an attacker can plausibly obtain a victim's OAuth bearer token (e.g., via a compromised or malicious OAuth app), which the PR:H rating assumes. Treat it as an elevated-priority patch for SSO/OAuth-integrated Mattermost deployments, but it is not a mass-exploitation, high-real-risk scenario on current evidence.

An attacker who has obtained a valid OAuth bearer token for a target user (for example through a compromised or malicious OAuth application granted access to that account) sends a crafted request to POST /api/v4/users/login/switch to change the account from SSO to email/password authentication. Because the endpoint fails to reject OAuth application sessions, the attacker sets an attacker-controlled password and detaches the account from its identity provider, achieving permanent takeover even after the original token is revoked. No public exploit code is identified at time of analysis.