CVE-2026-118694 in python-markdown2
Summary
by MITRE • 10/28/2026
python-markdown2 through 2.5.5 contains a denial of service vulnerability that allows remote users to exhaust CPU by submitting Markdown with unclosed inline link destinations. Attackers can submit repeated '[a](' or '![a](' sequences, causing _find_balanced to rescan the remaining document for each link and consume quadratic CPU time.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in python-markdown2 versions through 2.5.5 represents a significant denial of service risk stemming from inefficient algorithmic complexity within the library's parsing logic. Specifically, the flaw resides in how the parser handles unclosed inline link destinations, which triggers an exponential or quadratic increase in processing time relative to the input size. This issue is not merely a matter of resource consumption but reflects a fundamental design oversight in the regular expression matching and state management routines used by the markdown processor when encountering malformed hyperlink syntax.
At the technical level, the vulnerability exploits the behavior of the _find_balanced function within the python-markdown2 codebase. When an attacker submits Markdown content containing sequences such as [a] or ![a], which represent incomplete inline links with unclosed parentheses, the parser attempts to locate the closing delimiter by scanning forward through the document. Because the closing parenthesis is missing, this scan continues until it reaches the end of the input string without finding a match. Crucially, for each subsequent malformed link sequence encountered in the text, the parser does not utilize an optimized search strategy or maintain state that would allow it to skip ahead efficiently. Instead, it restarts the scanning process from the beginning of the remaining document segment. This results in quadratic CPU time complexity, meaning that as the length of the malicious input increases, the processing time grows exponentially rather than linearly.
The operational impact of this vulnerability is severe for any application or service that processes user-supplied Markdown content without strict sanitization limits. An attacker can craft a relatively small but carefully structured payload consisting of repeated unclosed link patterns to trigger this quadratic behavior. When such a request reaches the server, it causes the CPU usage to spike dramatically as the parser becomes trapped in an inefficient loop-like scanning process. This effectively denies service to legitimate users by consuming all available processing resources on the affected system. In cloud or containerized environments, this could lead to automatic scaling events due to high resource utilization or cause the application instance to crash if it exceeds memory or timeout limits imposed by upstream infrastructure components like load balancers or reverse proxies.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption leading to a denial of service condition. Furthermore, from an offensive security perspective, this technique is consistent with ATT&CK tactic T1496, Resource Hijacking, specifically the subtechnique related to CPU exhaustion via inefficient algorithms or loops. The attack vector relies on remote interaction through standard HTTP requests that deliver Markdown-formatted data, making it applicable in web applications, forums, documentation sites, and any API endpoint that accepts markdown input for rendering purposes.
Mitigation strategies should focus on both immediate patching and architectural defenses. The primary remediation is to upgrade python-markdown2 to a version later than 2.5.5 where the parsing logic has been optimized or patched to handle unclosed delimiters more efficiently, likely by implementing bounds checking or limiting the depth of recursive scans. For systems that cannot be immediately updated, input validation should be implemented at the application layer to reject Markdown strings containing unbalanced parentheses in link syntax before they reach the parser. Additionally, deploying rate-limiting mechanisms and setting strict timeouts for markdown processing tasks can help mitigate the impact by preventing any single request from monopolizing server resources indefinitely. Monitoring CPU usage patterns associated with markdown rendering endpoints may also aid in early detection of such abuse attempts.