CVE-2026-95666 in Mattermost
Summary
by MITRE • 09/22/2026
Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 fail to limit the length of the post ID array accepted by the bulk reactions endpoint which allows an authenticated user to cause excessive database load via a crafted request to {{POST /api/v4/posts/ids/reactions}}.. Mattermost Advisory ID: MMSA-2026-00771
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in Mattermost versions 11.9.x through 11.10.1, specifically affecting releases up to 11.9.1, 11.8.5, and 11.7.10, represents a significant resource exhaustion flaw within the application's bulk reactions endpoint. This issue stems from an insufficient input validation mechanism that fails to enforce strict length constraints on the post ID array submitted via the POST /api/v4/posts/ids/reactions API route. As detailed in Mattermost Advisory MMSA-2026-00771, this architectural oversight allows authenticated users to submit requests containing excessively large arrays of post identifiers without triggering any server-side limits or rejection protocols. The absence of these safeguards means the application processes every identifier provided in the payload, leading directly to disproportionate database operations and resource consumption relative to the size of the input array.
From a technical perspective, this flaw is classified under CWE-787: Out-of-bounds Write if it leads to memory corruption, but more accurately aligns with CWE-400: Uncontrolled Resource Consumption when considering its primary impact on system stability and availability. The vulnerability exploits the application's logic for handling bulk operations, where each post ID in the array typically triggers a database query or transaction to update reaction counts or metadata associated with that specific post. When an attacker crafts a request containing thousands or millions of IDs, the backend must iterate through this list, executing individual database calls for each entry. This linear scaling of resource usage against unbounded input size creates a classic Denial of Service scenario, where the server's CPU and I/O resources are saturated by legitimate-looking but maliciously oversized requests.
The operational impact of this vulnerability is severe for any Mattermost deployment relying on standard hardware configurations or shared database instances. An authenticated attacker can leverage this flaw to cause excessive database load, potentially leading to service degradation for all users connected to the instance. In high-traffic environments, such a request could exhaust available database connections, causing timeouts and failures for other critical application functions beyond just the reactions feature. This effectively results in a Denial of Service condition, disrupting communication workflows and undermining the reliability of the collaboration platform. The requirement for authentication means that while external unauthenticated attackers cannot exploit this directly, any compromised user account or insider threat can trigger significant operational disruption without needing elevated privileges.
In terms of attack classification, this vulnerability maps to MITRE ATT&CK technique T1496: Resource Hijacking, specifically under the sub-technique for Denial of Service via resource exhaustion. The attacker utilizes legitimate application functionality in an unintended manner to consume system resources, thereby impairing service availability. This behavior is consistent with patterns observed in other enterprise communication platforms where bulk processing endpoints lack robust rate limiting or payload size restrictions. The vulnerability highlights a common oversight in API design where the assumption that authenticated users will act reasonably leads to insufficient defensive coding practices regarding input validation and resource management limits.
Mitigation strategies must focus on immediate patching as well as architectural hardening of the affected endpoint. Organizations running vulnerable versions should upgrade immediately to patched releases that address MMSA-2026-00771, ensuring that the post ID array length is strictly validated against a defined maximum threshold before processing begins. In addition to upgrading, administrators can implement network-level controls such as Web Application Firewalls (WAF) rules to inspect and block requests with unusually large JSON payloads targeting this specific API endpoint. Rate limiting should also be applied at the application or infrastructure level to restrict the frequency of bulk reaction updates per user session, adding a layer of defense against automated abuse attempts. Continuous monitoring for spikes in database query volume associated with the reactions endpoint can aid in early detection and response to potential exploitation activities.