CVE-2026-97701 in Zulip
Summary
by MITRE • 11/04/2026
Zulip is an open-source team collaboration tool. In Zulip Server versions through 12.1, the authenticated POST /messages/render endpoint renders the content parameter without enforcing the normal message length limit used by message send and edit operations. An authenticated user can submit Markdown up to the server body-size limit, causing disproportionate backend CPU consumption, and repeated or concurrent requests can degrade Markdown rendering performance or backend availability for other users. This issue is fixed in version 12.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in Zulip Server versions through 12.1 represents a significant flaw in the input validation logic governing message content processing, specifically within the authenticated POST /messages/render endpoint. As an open-source team collaboration tool, Zulip relies heavily on real-time Markdown rendering to display user-generated content accurately and efficiently. The core technical deficiency lies in the disparity between how standard message creation or editing operations handle payload size constraints versus how the render API processes incoming data. While typical send and edit functions enforce strict limits on message length to prevent abuse and manage resource allocation, the /messages/render endpoint bypasses these normal restrictions. Instead of adhering to the expected character count thresholds, this endpoint accepts Markdown content up to the server's broader body-size limit, which is typically configured for much larger payloads such as file uploads or bulk data transfers. This architectural inconsistency creates a direct pathway for resource exhaustion attacks by authenticated users who can exploit the lack of specific length enforcement on rendering operations.
From an operational perspective, this flaw leads to disproportionate backend CPU consumption because Markdown parsing and HTML generation are computationally intensive processes that scale non-linearly with input size. When an attacker submits excessively large or complex Markdown structures through the vulnerable endpoint, the server must allocate significant processing power to parse nested elements, resolve references, and generate corresponding DOM trees. This excessive resource utilization can quickly degrade system performance for legitimate users sharing similar resources on the same backend infrastructure. In scenarios involving repeated submissions from a single account or concurrent requests from multiple authenticated accounts, the cumulative effect is severe degradation of Markdown rendering performance across the platform. The impact extends beyond simple latency; it poses a tangible risk to service availability by potentially causing denial-of-service conditions where legitimate users experience timeouts, failed message loads, or complete unresponsiveness due to backend overload.
This vulnerability aligns with CWE-787: Out-of-bounds Write in terms of resource consumption patterns and is more accurately categorized under CWE-400: Uncontrolled Resource Consumption, as the primary impact stems from excessive allocation of computational resources rather than memory corruption or buffer overflow. In the context of the MITRE ATT&CK framework, this behavior facilitates an Impact tactic specifically related to Denial of Service via resource exhaustion (T1499). The attack vector requires authentication, which classifies it as a lower-severity initial access requirement but does not diminish its potential for disruptive impact within trusted environments. Attackers with valid credentials can leverage this flaw to disrupt team communications without needing external network access or privilege escalation beyond their existing account permissions.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary resolution, as implemented in Zulip Server version 12.2, involves enforcing consistent length limits on the /messages/render endpoint that mirror those applied to standard message send and edit operations. This ensures uniform resource management across all user-facing input points. Administrators running affected versions should upgrade immediately to patch this discrepancy. Furthermore, organizations should implement rate limiting specifically for rendering endpoints to mitigate the impact of concurrent abuse attempts even after patches are applied. Input validation logic must be audited regularly to ensure that API endpoints do not inherit overly permissive defaults from general server configurations, and monitoring tools should be configured to alert on unusual spikes in CPU usage correlated with Markdown processing activities.