CVE-2026-105829 in CommonMark
Summary
by MITRE • 10/08/2026
League CommonMark from 1.3.0 before 2.10.2 contains a cross-site scripting vulnerability that allows users posting Markdown to bypass the DisallowedRawHtml extension by ending raw HTML with a bare disallowed tag name. Attackers can place a lone <script or <iframe line followed by a block supplying attributes like src or onload, executing stored scripts in viewers' browsers under default GFM settings.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in League CommonMark versions prior to 2.10.2 represents a significant security flaw within the Markdown parsing engine used extensively across various web applications and content management systems. This specific issue is classified as an improper neutralization of input during web page generation, commonly referred to as Cross-Site Scripting or XSS. The core technical failure lies in how the parser handles raw HTML blocks when interacting with security extensions designed to restrict such content. Specifically, the DisallowedRawHtml extension is intended to strip out untrusted HTML tags that are not on an allowlist, thereby preventing attackers from injecting malicious scripts into rendered pages. However, a logic error allows this protection mechanism to be bypassed through a specific formatting trick involving bare tag names followed by attribute-containing blocks.
The technical flaw manifests when a user posts Markdown content that includes raw HTML structured in a particular way. An attacker can construct a payload consisting of a lone opening tag such as <script or <iframe on one line, immediately followed by another block containing attributes like src or onload. The parser incorrectly interprets this sequence, failing to recognize the initial bare tag as part of the disallowed content that should be stripped. Instead, it processes the subsequent block with its dangerous attributes as valid HTML within the context of the first tag. This results in the browser interpreting the combined structure as a functional script or iframe element rather than stripping both components out entirely. Under default GitHub Flavored Markdown settings, which often permit certain levels of raw HTML for formatting purposes, this bypass is particularly effective because it exploits the parser's assumption that isolated tags without attributes are harmless while missing their connection to subsequent attribute-bearing blocks.
The operational impact of this vulnerability is severe due to its potential for stored Cross-Site Scripting attacks. Since CommonMark is frequently used in platforms where users can submit content that persists, such as forums, wikis, or blog comment sections, an attacker who successfully exploits this flaw can embed malicious JavaScript code into the page source. When other users view the compromised page, their browsers will execute the injected script in the context of the vulnerable website's domain. This allows attackers to steal session cookies, hijack user accounts, perform actions on behalf of victims, or redirect users to phishing sites. The persistence of this data means that every subsequent visitor to the affected content is exposed to the attack vector without needing any further interaction from the attacker after the initial injection.
From a classification perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation and falls under MITRE ATT&CK technique T1059 Command and Scripting Interpreter via browser-based execution. The failure to properly sanitize input before rendering it in an HTML context is the root cause, highlighting a gap in the validation logic for raw HTML blocks within the Markdown parser's extension system. To mitigate this risk, organizations relying on League CommonMark must upgrade immediately to version 2.10.2 or later where the parsing logic has been corrected to properly handle these edge cases and enforce stricter neutralization of disallowed tags regardless of how they are formatted in the source markdown. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts can be loaded, thereby limiting the impact even if a bypass occurs.