Update dependency league/commonmark to v2.9.0 [SECURITY] by renovate[bot] · Pull Request #6192 · phpstan/phpstan-src

renovate · 2026-08-07T09:32:23Z

This PR contains the following updates:

Package	Change	Age	Confidence
league/commonmark (source)	`2.8.2` → `2.9.0`

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

league/commonmark has an embed extension allowed_domains bypass

CVE-2026-33347 / GHSA-hh8v-hgvp-g3f5

More information

Details

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 allowed_domains 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 parse_url(), 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

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

CommonMark has DisallowedRawHtml extension bypass via whitespace in HTML tag names

CVE-2026-30838 / GHSA-4v6x-c7xx-hw9f

More information

Details

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 html_input 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)

Severity

CVSS Score: 5.1 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

league/commonmark: AttributesExtension href/src unsafe-link filter bypass via embedded control bytes

CVE-2026-71478 / GHSA-29pj-957v-52mc

More information

Details

## Summary

The AttributesExtension's href/src unsafe-link filter (AttributesHelper::filterAttributes()) can be bypassed by embedding control bytes in a javascript: URL that browsers discard before parsing the scheme. Two variants:

Tab/newline inside the scheme — a literal ASCII TAB (0x09), CR (0x0D), or LF (0x0A), e.g. java<TAB>script:alert(1). Per the WHATWG URL Standard's "basic URL parser" step 3, browsers "remove all ASCII tab or newline from input".
Leading C0 controls — e.g. <0x01>javascript:alert(1). Per step 1 of the same algorithm, browsers remove any leading or trailing C0 control or space. (A leading space alone does not bypass, because parseAttributes() already trim()s the value; other C0 bytes are not trimmed.)

The filter is a literal anchored-prefix regex (RegexHelper::isLinkPotentiallyUnsafe() / REGEX_UNSAFE_PROTOCOL) that matches neither obfuscated form, so in both cases the browser still executes javascript:alert(1).

This is confirmed reproducible even with allow_unsafe_links => false set — i.e. even applications that have followed the library's own documented hardening guidance for untrusted input remain exploitable.

This is a sibling gap in the same defense that CVE-2025-46734 (GHSA-3527-qv2q-pfvx) fixed in v2.7.0 — that fix made href/src respect allow_unsafe_links, but did not normalize control bytes before checking, so these obfuscation techniques were never covered.

Vulnerability

Files:

src/Util/RegexHelper.php:69 (REGEX_UNSAFE_PROTOCOL), :239-242 (isLinkPotentiallyUnsafe())
src/Extension/Attributes/Util/AttributesHelper.php:149-179 (filterAttributes())

CWE: CWE-79 (Improper Neutralization of Input During Web Page Generation / XSS) — primary

CWE-692 (Incomplete Denylist to Cross-Site Scripting) — the anchored-prefix denylist in REGEX_UNSAFE_PROTOCOL is incomplete. This is a composite of CWE-184 and CWE-79, so it captures the full "incomplete denylist → XSS" chain on its own.
CWE-86 (Improper Neutralization of Invalid Characters in Identifiers in Web Pages) — the specific evasion technique: control bytes embedded within the URI scheme identifier, which the browser strips before resolving it.

Root Cause

// src/Util/RegexHelper.php
public const REGEX_UNSAFE_PROTOCOL = '/^(?:javascript|vbscript|file|data):/i';

public static function isLinkPotentiallyUnsafe(string $url): bool
{
    return \preg_match(self::REGEX_UNSAFE_PROTOCOL, $url) !== 0 && \preg_match(self::REGEX_SAFE_DATA_PROTOCOL, $url) === 0;
}

// src/Extension/Attributes/Util/AttributesHelper.php
foreach ($attributes as $name => $value) {
    $attrNameLower = \strtolower($name);
    if (! $allowUnsafeLinks && ($attrNameLower === 'href' || $attrNameLower === 'src') && \is_string($value) && RegexHelper::isLinkPotentiallyUnsafe($value)) {
        unset($attributes[$name]);
        continue;
    }
    ...

The Attributes extension's own quote-value grammar (PARTIAL_DOUBLEQUOTEDVALUE = '"[^"]*"') accepts any byte except " inside quotes, including raw tab/CR/LF and other C0 controls, and parseAttributes() only trim()s (leading/trailing, and only the default charlist " \t\n\r\0\x0B" — so a leading \x01 survives). Critically, the core Markdown link-destination path (LinkParserHelper → UrlEncoder::unescapeAndEncode()) percent-encodes every control byte before this same safety check ever runs — but the Attributes extension's href/src handling has no equivalent normalization step, so the raw control byte reaches both the check and the final HTML output (Xml::escape() only escapes & < > " ', not tab/CR/LF, since they're legal bytes inside an HTML attribute).

Attack Scenario

An application enables the (commonly-used) AttributesExtension and sets allow_unsafe_links => false — the project's own documented hardening step for untrusted input.
An attacker submits Markdown: [Click me](javascript:alert(0)){href="java<TAB>script:alert(document.cookie)"} (TAB is one literal 0x09 byte).
The library emits <a href="java<TAB>script:alert(document.cookie)">Click me</a> — isLinkPotentiallyUnsafe() doesn't match the tab-split scheme, so the filter takes no action.
A victim viewing/clicking the link has the browser strip the embedded TAB and execute javascript:alert(document.cookie) in the victim's session — stored XSS, cookie theft, account takeover potential.

Why the payload needs an unsafe core destination. Step 2 above deliberately uses [Click me](javascript:alert(0)) rather than a normal link. LinkRenderer overwrites attrs['href'] with the node's own URL unless that URL is itself judged unsafe — so [x](https://example.com){href="java<TAB>script:..."} renders the harmless href="https://example.com", and an empty destination [x](){href="..."} renders href="". The attacker therefore supplies a core destination that the filter does catch, which suppresses the overwrite and lets the attribute-supplied href reach the final tag. This is no obstacle in practice — the attacker writes the entire Markdown document.

Two related forms that are not exploitable, noted so the fix isn't over-scoped:

Attaching the attribute to a non-link block — hi {href="java<TAB>script:alert(1)"} — does bypass the filter and emits <p href="java<TAB>script:alert(1)">, but href on a <p> is inert: there is nothing to navigate. (An earlier draft of this report described this as a "simpler, unconditional variant" of the attack; it is a filter bypass, not an XSS.)
<img src> is unaffected, since ImageRenderer unconditionally overwrites src from the core URL regardless of the safety verdict.

Recommended Fix

Normalize inside RegexHelper::isLinkPotentiallyUnsafe() before testing, mirroring the WHATWG URL parser's own normalization. This covers both variants, fixes every call site at once (LinkRenderer, ImageRenderer, and any third-party callers), and needs no changes in the Attributes extension.

Affected Versions

>= 1.5.0, <= 2.8.3 - every release that ships the AttributesExtension. Verified by installing each version and rendering the payloads with allow_unsafe_links => false. The attribute-value grammar (PARTIAL_DOUBLEQUOTEDVALUE = '"[^"]*"') has accepted raw control bytes since the extension was introduced, and none of the intervening parser rewrites narrowed it.

Prior Related Advisories

GHSA-3527-qv2q-pfvx / CVE-2025-46734 fixed a different Attributes-extension XSS (unallowlisted on* handlers, href/src not respecting allow_unsafe_links at all) in v2.7.0. This issue bypasses the specific href/src protection that fix introduced (the control-byte normalization gap was not part of that fix) - but the obfuscated inputs also work on older versions.

Severity

CVSS Score: 6.1 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

league/commonmark: Quadratic-time denial of service when parsing crafted Markdown

CVE-2026-71488 / GHSA-2q4p-g7hv-5rgv

More information

Details

Impact

Affected versions of league/commonmark can have quadratic time complexity when parsing specially crafted Markdown lines. In practical terms, doubling the length of an affected line can make the parser perform roughly four times as much work. The parser identifies locations using character positions, but regular-expression matches report byte positions. These positions differ when a UTF-8 character uses more than one byte. Several parsing paths repeatedly rescan growing portions of the line to translate between the two positions. The Autolink extension can also copy and validate the remaining line at every URL-like prefix.

In current 2.x releases, a single non-ASCII character anywhere on a line can place that whole line on the slower multibyte path. An attacker can combine it with a long run of leading whitespace or repeated Markdown punctuation, causing increasingly large rescans. When the Autolink extension is enabled, repeated URL-like prefixes provide another trigger, even on ASCII-only lines. Each trigger fits within one long line, so complex Markdown structure is unnecessary.

An attacker who can submit Markdown for conversion can use a comparatively small request to consume disproportionate CPU time and allocation activity. Repeated or concurrent requests can occupy all available PHP workers and prevent legitimate requests from completing. The core paths affect CommonMarkConverter, GithubFlavoredMarkdownConverter, and custom environments. The autolink-specific path affects applications using AutolinkExtension or GithubFlavoredMarkdownExtension. Applications that process only trusted Markdown are not remotely exploitable. The impact is limited to availability: it does not disclose data, change rendered output, or bypass rendering restrictions. Settings such as html_input and allow_unsafe_links do not mitigate the issue because the expensive work occurs before rendering.

Patches

The issue is patched in 2.9.0 and later. Starting in that release, the parser records UTF-8 character-to-byte positions incrementally, converts ordered regular-expression match positions without restarting from the beginning of the line, and matches autolinks against the original line instead of copying every remaining suffix. The affected work then grows in direct proportion to the input size while preserving existing Markdown output and configuration behavior. Versions from 0.6.0 through 2.8.3 are affected. The 0.x and 1.x release lines are no longer supported, so their users must upgrade to 2.9.0 or later.

Workarounds

If you cannot upgrade immediately, reject or truncate inputs with excessively long individual lines before passing them to the converter. A total request-size limit is also useful, but a per-line limit is important because every demonstrated trigger fits on one line. Choose limits appropriate for the application and enforce them before Markdown parsing begins. Restricting conversion to trusted users, applying strict execution-time limits, rate-limiting requests, and limiting concurrent conversions can further reduce exposure, but these measures are not complete substitutes for upgrading.

Disabling AutolinkExtension and avoiding GithubFlavoredMarkdownExtension removes the autolink-specific trigger, but the core multibyte parsing paths remain reachable in the standard parser. Existing nesting, delimiter, raw-HTML, and unsafe-link configuration options do not eliminate all affected paths. Applications that must continue processing untrusted Markdown should therefore enforce input limits even when autolinking is disabled.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

league/commonmark: Denial of service via adjacent inline attribute blocks

GHSA-g2gp-3wwq-f4ph

More information

Details

Impact

With the Attributes extension enabled, AttributesListener::findTargetAndDirection() resolves each attribute node's target by walking outward through its siblings. For a run of N adjacent inline attribute blocks placed at the start of a block (with nothing to their left), each node scans the entire sibling list to the far-right end before giving up and falling back to the parent. Each resolution is therefore Θ(N) and the whole run is Θ(N²).

Reaching the path requires AttributesExtension (opt-in, but first-party: League\CommonMark\Extension\Attributes\AttributesExtension). No other configuration matters — the quadratic walk runs unconditionally during parsing and is not gated by the attributes/allow allow-list, the on* hardening added in 2.7.0, or allow_unsafe_links. An unauthenticated attacker can submit a ~32 KB input ({#a} repeated 8,000 times) that takes over 5 seconds to convert, with time growing quadratically in input length — a cheap denial of service. Availability impact only. The Attributes extension was introduced in 1.5.0 (May 2020) with this outward-walk resolver present from the first commit, so all releases from 1.5.0 onward (including every 2.x) are affected.

Workarounds

There is no library-level configuration that gates the quadratic walk. Integrators who cannot upgrade can only reduce exposure indirectly:

Disable the Attributes extension for untrusted input, or
Impose a strict maximum input length before conversion — noting that because the cost is quadratic, even a modest cap must be small to meaningfully bound worst-case CPU.

Upgrading to a release containing the fix is recommended.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

league/commonmark: Denial of service via colliding heading slugs

GHSA-mh25-x5hq-wrqp

More information

Details

Impact

UniqueSlugNormalizer::normalize() makes each slug document-unique by searching for an unused numeric suffix, but restarts that search from 1 on every collision. The k-th heading that collapses to the same base slug performs k−1 array lookups, so K colliding slugs cost Σ(k−1) = O(K²). An attacker can force every heading onto a single base slug trivially — many empty ATX headings, identical heading text, or punctuation-only headings that normalize to the empty string.

The path is reached whenever the shared slug normalizer runs over attacker-controlled text. That happens when HeadingPermalinkExtension is registered (its HeadingPermalinkProcessor normalizes every heading), independently through FootnoteExtension (its AnonymousFootnoteRefParser normalizes every ^[label] reference), and on any TableOfContentsExtension site (which requires HeadingPermalinkExtension to be co-registered). The default slug_normalizer/unique setting (UniqueSlugNormalizerInterface::PER_DOCUMENT) accumulates collisions across the whole document. No authentication is required — a small document body turns into seconds of CPU and denies service. Availability impact only. UniqueSlugNormalizer was introduced in 2.0.0 (first shipped in 2.0.0-beta1, May 2021); the 1.x heading-permalink slug generator performed no de-duplication and is not affected. All 2.x releases (including 2.8.x) are affected.

Workarounds

Integrators who cannot upgrade immediately can:

Set slug_normalizer/unique to false / UniqueSlugNormalizerInterface::DISABLED, which stops the de-duplication scan entirely — at the cost of losing id uniqueness (colliding headings then share an anchor).
Disable HeadingPermalinkExtension (and TableOfContentsExtension, which depends on it), and FootnoteExtension where anonymous footnotes reach the same normalizer, for untrusted Markdown.
Cap the accepted document size / heading count upstream so K cannot reach the quadratic danger zone.

Each of these trades off functionality or correctness; upgrading to the patched release (which removes the quadratic behavior while keeping unique ids and identical output) is the recommended remediation.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

league/commonmark: Denial of service via duplicate footnote definitions

GHSA-jfm3-95jq-q3rf

More information

Details

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.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

league/commonmark: Denial of service via deeply nested XML output

GHSA-mj63-m3rc-8ppr

More information

Details

Impact

XmlRenderer pretty-prints XML by emitting depth-proportional indentation whitespace for every opening and closing tag. For a tree of depth n, the indentation alone sums to O(n²) bytes of output (and corresponding memory), reachable through MarkdownToXmlConverter — e.g. str_repeat('> ', $depth) . "x\n", a single line of nested blockquotes — or through a direct XmlRenderer::renderDocument() call on an attacker-influenced AST.

This affects applications that convert untrusted Markdown to XML, which is an opt-in output path. The parser's max_nesting_level bounds the depth of parser-created trees, but its default is high enough to reach damaging sizes, can be raised by the host application, and does not constrain custom or programmatically built ASTs handed straight to the renderer. The result is a memory / output-size amplification rather than a hard crash, which is why this issue is rated Medium rather than High. No confidentiality or integrity impact. XML rendering was introduced in 2.0.0 (first shipped in 2.0.0-beta1, June 2021) and has emitted depth-proportional indentation ever since, so all 2.x releases are affected (verified against 2.8.x, clean upstream 1902f60f). 1.x has no XML renderer and is not affected.

Workarounds

Applications converting untrusted Markdown to XML should:

Lower max_nesting_level to a conservative value appropriate to expected content, so the parser refuses to build extremely deep trees. This is the most direct lever for parser-produced ASTs, but does not protect trees built programmatically and passed straight to XmlRenderer.
Cap input size before conversion, since the amplification is driven by input-proportional depth.
Constrain XML consumers with memory / output-size limits (and streaming or size caps on any downstream XML parser or storage) so one request cannot allocate unbounded output.
Prefer HTML rendering for untrusted content where XML is not strictly required — the HTML renderer does not emit depth-proportional indentation and is not subject to this amplification.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

thephpleague/commonmark (league/commonmark)

`v2.9.0`

Compare Source

This is a security release to address five denial of service vulnerabilities and one cross-site scripting (XSS) vulnerability.

Added

Added a new NormalizeHeadingsExtension to constrain headings to a configured level range (#989)
- Rewrites headings that skip levels so the resulting HTML is valid (#1115)
- normalize_headings/rebase_to_min_level - rebases each document so its headings begin at min_level
Added a new footnote/enable_inline_footnotes config option to disable the inline ^[Footnote text] syntax (#1112)
Added Cursor::getBytePosition() for obtaining the cursor's current byte offset within the line
Added a new xml/max_indentation_level config option to control how far XmlRenderer indents nested elements (default: 16; set to 0 for unindented output)

Changed

The FootnoteExtension now uses only the first definition of a footnote label, removing any duplicate definitions instead of rendering them in place
NumberFootnotesListener now stores footnote backrefs under a single footnote/backrefs key in the document data instead of one key per footnote destination
Optimized Cursor to translate character positions to byte offsets in constant time instead of re-decoding the line with mb_substr()
Optimized Cursor::match() to match against the line at the cursor's byte offset instead of copying the remaining line on every call
Optimized InlineParserEngine and UrlAutolinkParser to work with byte offsets directly

Fixed

Fixed quadratic parsing performance on lines containing multibyte characters, which could be abused to cause a denial of service (GHSA-2q4p-g7hv-5rgv)
Fixed the unsafe link filter failing to detect dangerous schemes obfuscated with embedded tabs, newlines, or leading control characters (such as java<TAB>script:), which allowed the allow_unsafe_links protection to be bypassed via href and src attributes (GHSA-29pj-957v-52mc)
Fixed duplicate footnote definitions each claiming the full list of backrefs for their label, causing a quadratic number of backrefs to be generated, which could be abused to cause a denial of service (GHSA-jfm3-95jq-q3rf)
Fixed footnote labels being treated as .//-delimited key paths when storing backrefs, which allowed distinct labels such as [^a.b] and [^a/b] to share a single backref list (GHSA-jfm3-95jq-q3rf)
Fixed a fatal error when one footnote label was a prefix of another, such as [^a] and [^a.b]
Fixed the unique slug normalizer restarting its suffix search from 1 on every collision, causing headings or inline footnotes which normalize to the same slug to be de-duplicated in quadratic time, which could be abused to cause a denial of service (GHSA-mh25-x5hq-wrqp)
Fixed the AttributesExtension scanning the remaining siblings of an inline attribute which can only apply to its parent block, causing long runs of adjacent inline attributes to be resolved in quadratic time, which could be abused to cause a denial of service (GHSA-g2gp-3wwq-f4ph)
Fixed XmlRenderer indenting every element by its full nesting depth without any upper bound, causing deeply-nested documents to render as quadratically-sized XML, which could be abused to cause a denial of service (GHSA-mj63-m3rc-8ppr)
Fixed MarkDelimiterProcessor not being declared as a CacheableDelimiterProcessorInterface, preventing the delimiter stack from caching the opener search for == runs (#1133)

`v2.8.3`

Compare Source

Fixed

Fixed tab-indented fenced code blocks inside list items losing the first character of each line and having their info string mangled (#981, #1130)
Fixed the unsafe link filter incorrectly blocking safe URLs containing vbscript:, file:, or data: anywhere after the start (#1131)

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

Update dependency league/commonmark to v2.9.0 [SECURITY]

82a5f86

SanderMuller approved these changes Aug 7, 2026

View reviewed changes

Navigation Menu

Uh oh!

Update dependency league/commonmark to v2.9.0 [SECURITY] - #6192

Update dependency league/commonmark to v2.9.0 [SECURITY]#6192
renovate[bot] wants to merge 1 commit into
2.2.xfrom
renovate/packagist-league-commonmark-vulnerability

renovate Bot commented Aug 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

renovate Bot commented Aug 7, 2026

league/commonmark has an embed extension allowed_domains bypass

Details

Impact

Patches

Workarounds

Severity

References

CommonMark has DisallowedRawHtml extension bypass via whitespace in HTML tag names

Details

Impact

Patches

Workarounds

Severity

References

league/commonmark: AttributesExtension href/src unsafe-link filter bypass via embedded control bytes

Details

Vulnerability

Root Cause

Attack Scenario

Recommended Fix

Affected Versions

Prior Related Advisories

Severity

References

league/commonmark: Quadratic-time denial of service when parsing crafted Markdown

Details

Impact

Patches

Workarounds

Severity

References

league/commonmark: Denial of service via adjacent inline attribute blocks

Details

Impact

Workarounds

Severity

References

league/commonmark: Denial of service via colliding heading slugs

Details

Impact

Workarounds

Severity

References

league/commonmark: Denial of service via duplicate footnote definitions

Details

Impact

Workarounds

Severity

References

league/commonmark: Denial of service via deeply nested XML output

Details

Impact

Workarounds

Severity

References

Release Notes

v2.9.0

Added

Changed

Fixed

v2.8.3

Fixed

Configuration

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

`v2.9.0`

`v2.8.3`