Mattermost EUVD-2026-60192

Exploitation requires three specific preconditions to align: (1) the target Mattermost instance must be running one of the affected version ranges (11.7.0-11.7.6, 10.11.0-10.11.21, or 11.8.0-11.8.3); (2) the attacker must hold an authenticated Mattermost session - unauthenticated access is not sufficient; and (3) the attacker's account must have previously been assigned Board Admin status and subsequently demoted to the System Guest role without the SchemeAdmin flag being cleared. This is not a default-configuration risk for all users - it applies only to accounts that have undergone this specific demotion lifecycle. Limiting factors include the requirement for a valid authenticated session (PR:L), the necessity of prior Board Admin assignment, and the fact that impact is confined to Boards feature administration rather than system-wide privilege escalation.

The reported CVSS 3.1 score of 6.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) is consistent with the nature of this flaw. The low-privilege requirement (PR:L) correctly reflects that the attacker must hold a valid, authenticated Mattermost session; unauthenticated exploitation is not possible. The low complexity (AC:L) is also accurate - once a user is in the demoted-but-stale-flag state, exploitation requires no special tooling beyond issuing standard API calls. Impact is bounded at Low across all three pillars because Board Admin access is scoped to the Boards feature only, not the broader system. No EPSS score was provided in the intelligence set; however, the combination of authenticated-only access, a required pre-condition (prior Board Admin assignment followed by demotion), and no KEV or POC listing all point to low real-world exploitation pressure. This is a genuine authorization logic flaw that warrants patching, but its blast radius is constrained compared to unauthenticated remote code execution classes.

An attacker who was legitimately assigned Board Admin privileges in a Mattermost Boards workspace and subsequently demoted to System Guest retains the ability to call Board Admin REST API endpoints. Using their still-valid session token, they issue authenticated API requests - such as modifying board membership, changing permission settings, or accessing restricted board content - actions that should be blocked by their current System Guest role. No public proof-of-concept code has been identified, but exploitation requires nothing beyond standard HTTP tooling and knowledge of the Boards API.