league/commonmark (thephpleague/commonmark) versions >= 2.7.0 and < 2.9.1 contain a cross-site scripting vulnerability in the AttributesExtension. Prefixing an attribute name with a single U+000C form feed byte (e.g. {\x0Conclick="alert(1)"}) bypasses the AttributesHelper::filterAttributes() 'on' event-handler filter because PHP's trim() does not strip U+000C, causing the attribute to be written verbatim into the output where browsers parse it as a genuine event handler. The same prefix also defeats the allowunsafelinks check, allowing javascript: URIs through href/src attributes even when allowunsafelinks is false. Exploitation requires processing untrusted Markdown with the AttributesExtension enabled; the injected script executes when the rendered HTML is viewed. Fixed in 2.9.1.

league/commonmark versions before 2.9.1 contain multiple denial of service vulnerabilities in fenced code block detection, reference link label lookup, and emphasis delimiter processing that perform super-linear work on crafted input. Attackers can submit specially crafted Markdown with long backtick runs, nested brackets, or delimiter sequences to consume disproportionate CPU time and prevent legitimate requests from completing.

The league/commonmark (thephpleague/commonmark) library in versions >= 1.5.0 and < 2.9.1 contains quadratic parsing complexity in its SmartPunctExtension and AttributesExtension. When either extension is explicitly registered on the Environment (they are not enabled by default and are excluded from the standard CommonMark and GitHub-Flavored Markdown converters), an unauthenticated attacker can submit small, specially crafted Markdown documents — such as text alternating with unpaired quotes, contiguous runs of block-level attribute blocks, or repeated class attributes — to trigger disproportionate CPU consumption and cause a denial of service. Fixed in 2.9.1.

commonmark versions from 1.5.0 before 2.10.0 contain a denial of service vulnerability in the AttributesExtension when processing distinctly-named attributes. Attackers can submit Markdown with numerous distinct attribute names to cause quadratic-time attribute merging and filtering, consuming disproportionate CPU resources and preventing legitimate requests from completing.

Impact

The DomainFilteringAdapter in the Embed extension is vulnerable to an allowlist bypass due to a missing hostname boundary assertion in the domain-matching regex. An attacker-controlled domain like youtube.com.evil passes the allowlist check when youtube.com is an allowed domain.

This enables two attack vectors:

- SSRF: The OscaroteroEmbedAdapter makes server-side HTTP requests to the embed URL via the embed/embed library. A bypassed domain filter causes the server to make outbound requests to an attacker-controlled host, potentially probing internal services or exfiltrating request metadata. - XSS: EmbedRenderer outputs the oEmbed response HTML directly into the page with no sanitization. An attacker controlling the bypassed domain can return arbitrary HTML/JavaScript in their oEmbed response, which is rendered verbatim.

Any application using the Embed extension and relying on alloweddomains to restrict domains when processing untrusted Markdown input is affected.

Patches

This has been patched in version 2.8.2. The fix replaces the regex-based domain check with explicit hostname parsing using parseurl(), ensuring exact domain and subdomain matching only.

Workarounds

- Disable the Embed extension, or restrict its use to trusted users - Provide your own domain-filtering implementation of EmbedAdapterInterface - Enable a Content Security Policy (CSP) and outbound firewall restrictions

Impact

The DisallowedRawHtml extension can be bypassed by inserting a newline, tab, or other ASCII whitespace character between a disallowed HTML tag name and the closing >. For example, <script\n> would pass through unfiltered and be rendered as a valid HTML tag by browsers. This is a cross-site scripting (XSS) vector for any application that relies on this extension to sanitize untrusted user input.

All applications using the DisallowedRawHtml extension to process untrusted markdown are affected. Applications that use a dedicated HTML sanitizer (such as HTML Purifier) on the rendered output are not affected.

Patches

Fixed in 2.8.1. The regex character class [ \/>] was changed to [\s\/>] to match all whitespace characters that browsers accept as valid tag name terminators.

Workarounds

- Set the htmlinput configuration option to 'escape' or 'strip' to disable all raw HTML, though this is a broader restriction than the DisallowedRawHtml extension provides. - Pass the rendered HTML through a dedicated HTML sanitizer before serving it to users (always recommended)

Resources

- CommonMark DisallowedRawHtml documentation - CWE-79: Improper Neutralization of Input During Web Page Generation - CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)