GHSA-J8PM-GJ4C-RQ4X

league/commonmark: Denial of service via crafted code fences, reference links, and emphasis delimiters

Affected versions of league/commonmark perform super-linear work on three independent parsing paths, all of which are reachable on a stock new CommonMarkConverter() with default configuration and no extensions registered. Each trigger fits on a single line of input, so no complex Markdown structure is required.

The three paths were introduced at different times. This advisory's version range is their union; the individual ranges are:

1. Fenced code block detection, quadratic, affected from 0.6.0.

FencedCodeStartParser matches the following pattern:

/^[ \t]*(?:`{3,}(?!.*`)|~{3,})/

The lookahead enforces the CommonMark rule that a backtick fence's info string may not itself contain a backtick, but neither the lookahead nor the backtick run it guards is atomic or possessive. On a line consisting of a long backtick run, filler text, and a single trailing backtick, the quantifier gives back one character at a time and re-runs the lookahead across the remainder of the line on every candidate fence length.

A 320 KB single line takes roughly 27 seconds to convert. The identical payload with one x character prefixed, which fails the parser's own leading-character guard, takes 0.011 seconds. preg_last_error() returns 0 at every input size tested, including runs of 160,000 characters, so PCRE never reaches pcre.backtrack_limit and this is sustained CPU consumption rather than an early bail-out.

2. Reference link label lookup, effectively quadratic, affected from 0.6.0.

When a shortcut or collapsed reference link is attempted, CloseBracketParser::tryParseReference() copies the entire span between the brackets and passes it to ReferenceMap::get(), which normalizes the label, up to four full passes over its length (trim, preg_replace, mb_check_encoding, and strtolower, or mb_convert_case on the non-ASCII path). Nested brackets produce one such lookup per closing bracket, each on a span two characters longer than the last.

In 2.x the normalization sits behind an early return for an empty reference map, so a single 8-byte reference definition anywhere in the document ([x]: y) is enough to unlock the path. At n = 64,000 nested brackets the same input takes 22.0 seconds with that line present versus 0.59 seconds without it. A single non-ASCII character inside the brackets forces the mb_convert_case branch, costing roughly 2.5x more again.

3. Emphasis, strikethrough, and highlight delimiter processing, super-linear, affected from 2.6.0.

DelimiterStack::processDelimiters() remains linear only because of the openersBottom memo, which bounds the backward opener scan, an argument that holds only if the memo's key space is O(1). EmphasisDelimiterProcessor::getCacheKey(), and the equivalents in StrikethroughDelimiterProcessor and MarkDelimiterProcessor, embed the closer's raw current run length in the key, leaving that space unbounded. An attacker spends O(n) bytes minting a growing number of distinct run lengths; each distinct length is a fresh key whose recorded bound starts at zero, forcing a full backward re-scan of the entire pile of openers.

The resulting work grows as roughly n^1.5. This is sub-quadratic, but the amplification over linear growth itself scales with input size, so it worsens as inputs grow: 800 KB of ordinary asterisks, letters, and spaces costs roughly 27 seconds on a stock converter.

This path is a regression introduced in 2.6.0. Before that release the cache key was the bare delimiter character, a bounded key space that amortized correctly. * and _ are affected on any default configuration from 2.6.0 onward. ~ (StrikethroughExtension, included in GithubFlavoredMarkdownConverter and GithubFlavoredMarkdownExtension) is affected from 2.6.0. = (HighlightExtension) is affected only from 2.9.0, when MarkDelimiterProcessor was declared cacheable.

Overall impact. An unauthenticated attacker who can submit Markdown for conversion can use a comparatively small request to consume disproportionate CPU time. Repeated or concurrent requests can occupy all available PHP workers and prevent legitimate requests from completing. The impact is limited to availability: no data is disclosed, rendered output is unchanged, and no rendering restriction is bypassed. Applications that process only trusted Markdown are not remotely exploitable.

Settings such as html_input, allow_unsafe_links, and max_nesting_level do not mitigate any of these, because the expensive work occurs during parsing, before rendering. max_delimiters_per_line bounds the third path only, and does so lossily, it silently discards emphasis once the cap is exhausted.

A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use. Typical impact: denial of service when input is crafted to trigger backtracking.

GHSA-J8PM-GJ4C-RQ4X has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.9.1); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

The issues are patched in 2.9.1 and later:

• The fenced code block quantifier is now possessive, which is behavior-identical here: any character given back moves a backtick into the lookahead's scan range, so every retry was guaranteed to fail regardless.
• Reference link lookups now apply the CommonMark 999-character link label limit before copying and normalizing the label, matching the limit already enforced when parsing reference definitions. Because a definition can never exceed that length, an over-length lookup label cannot match one directly. One edge case does change: a label longer than 999 characters that collapses to a shorter match once whitespace is normalized, for example [a followed by 998 spaces and b] against a [a b]: /url definition, previously rendered as a link and now renders literally. This follows cmark, which applies its own label-length cap before normalizing (cmark_reference_lookup()), and matches how this library has always handled the equivalent [text][label] form via LinkParserHelper::parseLinkLabel(). commonmark.js normalizes first and still resolves such labels.
• Delimiter processor cache keys now clamp the run length to the coarsest bucket that can change behavior, min(length, 2) for emphasis, min(length, 3) for strikethrough and highlight, restoring a bounded key space while preserving byte-identical output.

Versions from 0.6.0 through 2.9.0 are affected by at least one of these paths; see the table above for which paths apply to which releases. The 0.x and 1.x release lines are no longer supported, so their users must upgrade to 2.9.1 or later.

1. What is GHSA-J8PM-GJ4C-RQ4X? GHSA-J8PM-GJ4C-RQ4X is a high-severity inefficient regular expression (ReDoS) vulnerability in league/commonmark (composer), affecting versions >= 0.6.0, < 2.9.1. It is fixed in 2.9.1. A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use.
2. How severe is GHSA-J8PM-GJ4C-RQ4X? GHSA-J8PM-GJ4C-RQ4X has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of league/commonmark are affected by GHSA-J8PM-GJ4C-RQ4X? league/commonmark (composer) versions >= 0.6.0, < 2.9.1 is affected.
4. Is there a fix for GHSA-J8PM-GJ4C-RQ4X? Yes. GHSA-J8PM-GJ4C-RQ4X is fixed in 2.9.1. Upgrade to this version or later.
5. Is GHSA-J8PM-GJ4C-RQ4X exploitable, and should I be worried? Whether GHSA-J8PM-GJ4C-RQ4X is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-J8PM-GJ4C-RQ4X is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-J8PM-GJ4C-RQ4X? Upgrade league/commonmark to 2.9.1 or later.

Other vulnerabilities in league/commonmark