Mattermost CVE-2026-16046

Exploitation requires three specific conditions: (1) the attacker must hold a valid Mattermost user account with at least low-privilege access (PR:L per CVSS); (2) the attacker must be listed as a participant in the specific playbook run being targeted - arbitrary runs belonging to other teams cannot be targeted without participant membership; and (3) the targeted playbook run must be in a finished/completed state. The Playbooks feature must be in active use on the instance. Limiting factors include: the vulnerability has no confidentiality or availability impact; it cannot be exploited unauthenticated; external attackers who are not run participants are blocked by the participant-membership check that does work correctly; and impact is confined to data integrity of historical run records rather than live operational data or credentials.

The CVSS 3.1 base score of 4.3 with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N accurately characterizes this as a medium-severity, low-complexity, authenticated network vulnerability. Real-world risk is moderate but context-dependent: the integrity impact targets historical incident records rather than live operations, making this most damaging in regulated environments where playbook retrospectives serve as compliance evidence or legal records. EPSS data was not provided in the available intelligence, so exploitation probability cannot be quantified. The vulnerability is not in the CISA KEV catalog and no POC has been identified, which together suggest no observed active exploitation. The attack complexity is genuinely low once the preconditions are met, but the requirement to be an authenticated run participant meaningfully limits the attacker pool to insiders or compromised accounts. The scope-unchanged rating confirms blast radius is contained to the affected Mattermost instance's data layer.

An authenticated Mattermost user who is a participant in a completed incident playbook run crafts a REST or GraphQL API mutation request targeting that run's write endpoint. Because the server validates participant membership but not run state, the request succeeds and the attacker can rewrite the retrospective, reassign run ownership to another user, or alter checklist completion records - effectively laundering the post-incident history without triggering an access-denied error.