Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
HIGH severity

GHSA-8rr7-cvq3-gmfh

HIGHFix: thephpleague/commonmark@f27eb72

GHSA-8rr7-cvq3-gmfh is a high-severity (CVSS 7.5) vulnerability in league/commonmark. O3 Security confirms whether GHSA-8rr7-cvq3-gmfh is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

league/commonmark: Denial of service via distinctly-named attributes in the Attributes extension

Published
Sep 1, 2026
Updated
Sep 1, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 1, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐘league/commonmark

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

Impact

AttributesExtension ships with the library but must be explicitly registered on the Environment; it is not included in CommonMarkConverter, GithubFlavoredMarkdownConverter, or GithubFlavoredMarkdownExtension. Applications that do not register AttributesExtension are not affected by this advisory.

Two paths in the extension re-process every attribute a node has already collected each time another attribute is applied to it. When the attributes carry distinct names, the collected set grows by one on every step and is walked again in full, so a run of n attributes costs O(n²).

1. Attribute nodes resolving to a common target (affected from 1.5.0).

AttributesListener::processDocument() merges each attribute node into the set accumulated for its target, then filters the result. Both operations traverse that entire set: AttributesHelper::mergeAttributes() rebuilds it with array_merge(), and AttributesHelper::filterAttributes() matches a regular expression against every name in it. A run of attribute nodes sharing one target therefore re-walks a set that grows by a key per node.

Two input shapes reach this path: adjacent inline attributes at the start of a block ({a0="v"}{a1="v"}…, where quoting the values is what keeps them separate — an unquoted value swallows the }{ that follows it), and a chain of attribute blocks held at their default target by reference definitions ({a0=v} / [a]: u / {a1=v} / [a]: u / …).

256 KB of adjacent inline attributes takes 20.0 seconds to convert, against 0.09 seconds once patched.

2. Consecutive attribute-block lines (affected from 2.0.0).

AttributesBlockContinueParser::tryContinue() merges each continuation line into the block's accumulated attributes, again rebuilding the whole set on every line. One distinct attribute per line ({a0=v} / {a1=v} / …) grows it by a key each time.

256 KB of such lines takes 1.9 seconds to convert while producing zero bytes of output, against 0.08 seconds once patched.

Relationship to GHSA-jjv6-8j6v-6j52. The fix released in 2.9.1 for that advisory made the class attribute cheap to accumulate, but left every other attribute name on the original path. Applications that upgraded to 2.9.1 or 2.9.2 remain exposed to this variant.

Overall impact. An unauthenticated attacker who can submit Markdown to an affected application can consume disproportionate CPU time with a comparatively small request, occupying PHP workers and preventing legitimate requests from completing. The impact is limited to availability: no data is disclosed, rendered output is unchanged, and no rendering restriction is bypassed.

Patches

The issue is patched in 2.10.0. Both paths now fold each node — or each line — into the accumulated attributes at a cost proportional to that node or line alone, rather than re-merging and re-filtering everything gathered so far. Rendered output is unchanged, down to the order in which attributes appear.

The listener path affects 1.5.0 through 2.9.2. The continuation-line path affects 2.0.0 through 2.9.2. The 1.x release line is no longer supported, so its users must upgrade to 2.10.0 or later.

Workarounds

If you cannot upgrade immediately:

  • Do not register AttributesExtension when converting untrusted Markdown. This fully removes both paths.
  • If the extension is required, impose a strict maximum input length before conversion. Because the cost is quadratic, the cap must be small to meaningfully bound worst-case CPU time.

The attributes/allow allow-list added in 2.7.0 is not a mitigation. A non-empty allow-list happens to bound the first path, because unlisted names are discarded before they accumulate, but it does nothing for the second: continuation lines are merged while parsing, before any filtering takes place.

Restricting conversion to trusted users, applying strict execution-time limits, and rate-limiting requests reduce exposure but are not substitutes for upgrading.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistleague/commonmark1.5.0&&< 2.10.02.10.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for league/commonmark. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update league/commonmark to 2.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8rr7-cvq3-gmfh is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-8rr7-cvq3-gmfh is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-8rr7-cvq3-gmfh. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Impact `AttributesExtension` ships with the library but must be explicitly registered on the `Environment`; it is not included in `CommonMarkConverter`, `GithubFlavoredMarkdownConverter`, or `GithubFlavoredMarkdownExtension`. **Applications that do not register `AttributesExtension` are not affected by this advisory.** Two paths in the extension re-process every attribute a node has already collected each time another attribute is applied to it. When the attributes carry distinct names, the collected set grows by one on every step and is walked again in full, so a run of *n* attributes c
O3 Security · Impact-Aware SCA

Is GHSA-8rr7-cvq3-gmfh in your dependencies?

O3 detects GHSA-8rr7-cvq3-gmfh across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-8rr7-cvq3-gmfh: league/commonmark… | O3 Security