# GHSA-jfm3-95jq-q3rf: league/commonmark: Denial of service via duplicate footnote definitions

> An attacker can cause denial of service by sending a small crafted Markdown document with duplicate footnotes, leading to excessive memory usage and CPU consumption.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 6 Aug 2026

## What is GHSA-jfm3-95jq-q3rf?

GHSA-jfm3-95jq-q3rf is a denial of service vulnerability in league/commonmark, published on 6 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

### 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.

## Which versions are affected by GHSA-jfm3-95jq-q3rf?

2 open source packages ship an affected version, including league/commonmark.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `league/commonmark` | Packagist | From 1.5.0 | 2.9.0 |
| `league/commonmark` | Packagist | From 1.5.0 | 2.9.0 |

## How do I fix GHSA-jfm3-95jq-q3rf?

Upgrade league/commonmark to 2.9.0 or later.

## Is GHSA-jfm3-95jq-q3rf being exploited?

There is no known exploitation of GHSA-jfm3-95jq-q3rf in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-jfm3-95jq-q3rf and fix it if it is affected.

What it is: GHSA-jfm3-95jq-q3rf is a denial of service vulnerability in league/commonmark, published on 6 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-jfm3-95jq-q3rf in the wild and no public exploit code.

Affected packages and fixed versions:
- league/commonmark (Packagist): affected from 1.5.0; fixed in 2.9.0
- league/commonmark (Packagist): affected from 1.5.0; fixed in 2.9.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-jfm3-95jq-q3rf/ (Markdown: https://insights.sbomify.com/GHSA-jfm3-95jq-q3rf/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-jfm3-95jq-q3rf

---
From sbomify Insights: https://insights.sbomify.com/GHSA-jfm3-95jq-q3rf/
Summaries are generated and may contain mistakes; the official description above is the record.