CVE-2026-19867 in Mattermost
Summary
by MITRE • 10/16/2026
Mattermost versions 11.10.x <= 11.10.0, 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10 fail to cap the number and size of mention keys stored in a user's notification properties, and to bound the quadratic multibyte-keyword matching performed for each post, which allows an authenticated user to degrade post-processing latency and consume excessive CPU on behalf of other members of any channel they share via storing an oversized notify_props.mention_keys list on their own profile.. Mattermost Advisory ID: MMSA-2026-00773
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Mattermost versions 11.10.x through 11.8.x, specifically affecting releases up to 11.10.0, 11.9.1, and 11.8.5, represents a significant resource exhaustion flaw rooted in the application's notification processing logic. This issue stems from an absence of input validation regarding the size and quantity of mention keys stored within a user's notification properties object. When users configure their profiles to receive notifications for specific keywords or mentions, the system stores these identifiers in a list known as notify_props.mention_keys. The software fails to enforce any upper limits on either the number of entries in this list or the character length of individual keys. This lack of boundary checking allows an authenticated user to populate their profile with an arbitrarily large set of mention keywords, effectively bypassing standard input constraints that are typically present in secure application design practices.
The operational impact of this flaw is realized during post-processing operations within shared channels. When a message is posted by any member of a channel, the Mattermost server must evaluate whether the content triggers notifications for all users subscribed to those mentions. The underlying algorithm performs quadratic multibyte-keyword matching against each stored mention key for every incoming post. Because there is no cap on the number or size of these keys, an attacker can construct a profile with thousands of long keyword strings. Consequently, when other users in the same channel send messages, the server must execute this computationally expensive pattern-matching process against the inflated dataset. This results in severe degradation of post-processing latency and causes excessive CPU consumption on behalf of all channel members who are not necessarily targeted by the malicious keywords but whose notification systems are forced to perform unnecessary work due to the attacker's configuration.
From a security architecture perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write if interpreted as memory corruption in lower-level implementations, or more accurately CWE-400: Uncontrolled Resource Consumption when viewed through the lens of application-layer resource management. The quadratic complexity of the keyword matching algorithm exacerbates the impact, transforming a linear scaling issue into an exponential one relative to the number of posts and mention keys. In terms of adversary behavior, this aligns with MITRE ATT&CK technique T1496: Resource Hijacking, where resources are consumed for malicious purposes such as denial-of-service or performance degradation without necessarily gaining unauthorized access to data. The attacker leverages valid authentication credentials to abuse system functionality rather than exploiting a code execution flaw, making it an insider threat vector that can also be executed by compromised accounts.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Users operating affected versions should upgrade immediately to the patched release where these bounds are enforced. For administrators unable to patch instantly, implementing reverse proxy rules or application-level firewalls to limit the size of POST requests containing user profile updates can provide a temporary buffer against exploitation. Furthermore, developers must implement strict input validation that caps both the array length and string lengths within the notify_props structure. The quadratic matching algorithm should also be optimized using more efficient data structures such as trie trees or inverted indexes to reduce computational complexity from O(n*m) to near-linear time relative to post content size, ensuring that even if large inputs are attempted, they do not result in disproportionate CPU usage across the channel ecosystem.