CVE-2026-115352 in Mistune
Summary
by MITRE • 10/22/2026
Mistune before 3.3.0 contains an algorithmic complexity vulnerability in the inline link parser that allows unauthenticated attackers to exhaust CPU by submitting long runs of unmatched '[' characters. Attackers can send small markdown payloads that trigger O(N^2) parse_link_text and parse_link_label probing, occupying rendering workers for 30+ seconds per 16 KB input.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Mistune versions prior to 3.3.0 represents a significant algorithmic complexity flaw within the inline link parser component of this popular Python Markdown library. This issue is classified under CWE-400, which denotes uncontrolled resource consumption due to inefficient algorithms or data structures that fail to scale appropriately with input size. The core technical defect lies in how the parser handles sequences of unmatched opening square brackets '[' when processing markdown syntax for links. Instead of employing a linear time complexity approach to validate and resolve these link definitions, the underlying logic triggers an O(N^2) behavior during the execution of parse_link_text and parse_link_label functions. This quadratic scaling means that as the length of the input string increases, the computational effort required grows exponentially rather than proportionally, creating a severe performance bottleneck for any system relying on this library to render markdown content.
From an operational perspective, this vulnerability enables unauthenticated attackers to execute a Denial of Service attack by submitting crafted markdown payloads containing long runs of unmatched '[' characters. Because Mistune is often used in web applications and APIs that process user-generated content, such as blog comments or forum posts, the attacker does not need valid credentials to exploit this flaw. The malicious payload triggers intensive CPU cycles within the rendering workers responsible for converting markdown into HTML. For a relatively small input size of just 16 kilobytes, the parser can occupy these worker processes for more than thirty seconds. This prolonged occupation effectively blocks other legitimate requests from being processed by the same thread or process pool, leading to service degradation or complete unavailability depending on the concurrency limits and configuration of the hosting application.
The impact extends beyond simple CPU exhaustion; it directly affects the availability and responsiveness of services that integrate Mistune for text rendering. In environments where worker threads are limited, such as many WSGI servers like Gunicorn or uWSGI with default configurations, a few concurrent attacks can exhaust all available workers. This results in a total service outage for legitimate users who cannot access any part of the application until the malicious requests finish processing and resources are freed. The efficiency of this attack is particularly concerning because it requires minimal bandwidth to deliver the payload while consuming disproportionate server-side resources, making it an attractive vector for low-effort disruption campaigns against web applications that do not implement strict input validation or rate limiting on markdown parsing endpoints.
Mitigation strategies primarily involve upgrading to Mistune version 3.3.0 or later, where this algorithmic complexity issue has been resolved through optimized parsing logic that avoids the quadratic time complexity trap. For organizations unable to immediately patch their dependencies, implementing a maximum length limit for incoming markdown inputs is a critical defensive measure. By truncating input strings before they reach the parser, administrators can prevent the execution of long unmatched bracket sequences that trigger the vulnerability. Additionally, deploying Web Application Firewalls with rules designed to detect and block excessive or malformed markdown syntax patterns can provide an additional layer of defense against such algorithmic complexity attacks. It is also advisable to isolate rendering processes in separate worker pools with strict resource limits, ensuring that a single malicious request cannot monopolize all server resources and impact the broader application infrastructure.