Mattermost Server EUVD-2026-102744

Exploitation requires two concrete conditions to coexist: (1) the Mattermost server must be running at debug-level logging, which is not the default production setting, causing authentication tokens to be written unsanitized into log entries; and (2) the attacker must already have read access to those server logs (direct filesystem access, a centralized log/SIEM viewer role, or compromise of the logging pipeline). Limiting factors: the high privilege/access barrier to logs (PR:H), the non-default debug logging requirement, and that victim user interaction (an authenticated session being generated/logged, UI:R) is needed to populate a usable token. Impact is confined to confidentiality - stolen tokens enable user impersonation but the flaw itself grants no direct integrity or availability impact.

This is a low-to-moderate priority issue (vendor CVSS 4.5, MEDIUM) and the available signals are internally consistent in pointing to a limited, prerequisite-heavy threat rather than a mass-exploitation risk. The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N) encodes high required privileges (PR:H) and required user interaction (UI:R), with impact confined to confidentiality (C:H, I:N, A:N) - consistent with a CWE-532 log-exposure flaw where the payoff is stolen session/OAuth tokens, not direct code execution. There is no EPSS score, no CISA KEV listing, and no POC referenced in the input, so exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision data was provided. One notable tension: the vendor sets AV:N, yet the described precondition is 'access to server logs,' which in most deployments implies local, administrative, or log-aggregation access rather than purely network-reachable attack surface - this inflates the apparent remote exposure, and the real-world barrier is higher than AV:N alone suggests. Overall, the combination of PR:H, UI:R, and the dependency on debug-level logging being enabled makes this a defense-in-depth / credential-hygiene concern rather than a drop-everything emergency.

An attacker who already has read access to Mattermost server logs (e.g., a low-trust operator, a log-aggregation viewer, or someone who has pivoted to the logging pipeline) harvests session or OAuth access tokens that were written in plaintext to debug-level log entries. They then replay a stolen token against the Mattermost API to impersonate the corresponding authenticated user. No public exploit code is identified; exploitation is trivial once log access and debug logging coincide, as it requires only reading and replaying a token.