GHSA-jfm3-95jq-q3rf json
league/commonmark: Denial of service via duplicate footnote definitions
published 3mo ago modified 3mo ago
- cvss
- 7.5
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### Impact
The Footnote extension records one backref per footnote *reference* and then appends the **entire** backref list for **every** footnote *definition* block in the document, without ever de-duplicating or removing repeated definitions of the same label (`GatherFootnotesListener`, populated by `NumberFootnotesListener`). A document that references a single label N times and also supplies N duplicate `[^a]:` definitions of that label therefore produces **N × N** `FootnoteBackref` nodes, so output size, parse time, and peak memory are all **O(N²)**.
Reaching the vulnerable path requires `FootnoteExtension` to be registered on the `Environment`. This is opt-in, but is a commonly enabled GFM-style feature; no other non-default configuration is required. An unauthenticated attacker can expand a **~10 KB** request into a **~62 MB** HTML response, **~3 s** of CPU, and **~440 MB** of peak memory — enough to OOM-kill a default 128 MB PHP worker and deny service. Availability impact only; no confidentiality or integrity effect. **The Footnote extension was introduced in 1.5.0 (May 2020) with this backref logic present from the first commit, so all releases from 1.5.0 onward (including every 2.x through 2.8.x) are affected.**
### Workarounds
There is no library-level option to cap the number of footnotes, references, or definitions, so no configuration switch prevents the amplification. Integrators who cannot upgrade should:
- **Disable the Footnote extension** for untrusted input, or - **Enforce a strict input-size limit before conversion** — but note this is a weak control here, since the ~10 KB payload that already triggers the 62 MB / ~440 MB blowup is well within typical request-body limits, so any cap must be aggressively small to help.
Upgrading to the patched release is the recommended remediation.
Patch / fix
- packagist league/commonmark 2.9.0
Is GHSA-jfm3-95jq-q3rf in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| packagist | league/commonmark | >=1.5.0, <2.9.0 |
2.9.0 |
Classification
- Weakness
-
- CWE-407 Inefficient Algorithmic Complexity
References
Sources
- GitHub Advisory GHSA-jfm3-95jq-q3rf
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.