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

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
league/commonmark (source)	2.9.0 → 2.10.2

---

league/commonmark XSS: on* event-handler filter in AttributesExtension bypassed with a U+000C form feed

GHSA-f8fg-pg57-v4j8

More information

Details

Summary

The AttributesExtension documents a security guarantee:

Note: Attributes starting with on (e.g. onclick or onerror) are capable of executing
JavaScript code and are therefore never allowed by default. You must explicitly add them to
the allow list if you want to use them.

— docs/2.x/extensions/attributes.md

Prefixing the attribute name with a single U+000C FORM FEED byte defeats that guarantee.
{<FF>onclick="alert(1)"} passes through AttributesHelper::filterAttributes() untouched and is
written verbatim into the output, where browsers parse it as a genuine onclick handler.

The same prefix defeats the allow_unsafe_links check, letting a javascript: URI through on
href / src even when allow_unsafe_links is false.

This bypasses the fix shipped in the 2.7.0 security release ("Fix XSS in AttributesExtension",
43207253ea5f14867c77c697cd3838c446cadcea), which added filterAttributes() for the express
purpose of blocking these attributes.

Throughout this report <FF> denotes a literal U+000C byte ("\x0C" in PHP). It is invisible in
rendered text, so all payloads below are written with PHP escape sequences to stay unambiguous.

Details

Three behaviours combine.

1. \x0C survives the parser's trim().

AttributesHelper::SINGLE_ATTRIBUTE begins with \s*, and Cursor::match() returns
$matches[0][0] — the entire match, including that leading whitespace. The result is cleaned
with PHP's trim():

// src/Extension/Attributes/Util/AttributesHelper.php:62
while ($attribute = \trim((string) $attributeCursor->match('/^' . self::SINGLE_ATTRIBUTE . '/i'))) {

PCRE \s matches \x0C, but PHP's default trim() charlist is " \t\n\r\0\x0B" — it includes
the vertical tab \x0B but not the form feed \x0C. The byte is therefore consumed by the
regex, retained in the returned match, and not stripped. It ends up inside the attribute name:

// src/Extension/Attributes/Util/AttributesHelper.php:94
$attributes[\trim($name)] = \trim($value);   // $name === "\x0Conclick"

\x0C is the only byte with this property: every other character the HTML5 tokenizer treats as
whitespace (\x09, \x0A, \x0D, \x20), plus \x0B, is in PHP's trim charlist. The PoC
includes a \x0B case as a control, and it is correctly stripped.

2. The filter's string comparisons miss it.

filterAttributes() compares the raw name against literal strings:

// src/Extension/Attributes/Util/AttributesHelper.php:148-166
$attrNameLower = \strtolower($name);                            // "\x0conclick"
... ($attrNameLower === 'href' || $attrNameLower === 'src') ... // false
... \str_starts_with($attrNameLower, 'on') ...                  // false -> not removed

3. The renderer never escapes attribute names.

// src/Util/HtmlElement.php:123-129
$result .= ' ' . $key . '="' . Xml::escape($value) . '"';   // $key emitted raw

Because the HTML5 tokenizer treats \x0C as whitespace between attributes, the browser reads
the name as plain onclick.

PoC

<?php
require 'vendor/autoload.php';

use League\CommonMark\Environment\Environment;
use League\CommonMark\Extension\Attributes\AttributesExtension;
use League\CommonMark\Extension\CommonMark\CommonMarkCoreExtension;
use League\CommonMark\MarkdownConverter;

// The most defensive configuration docs/2.x/security.md recommends.
$env = new Environment([
    'html_input'         => 'escape',
    'allow_unsafe_links' => false,
    'max_nesting_level'  => 100,
    // 'attributes' => ['allow' => [...]] deliberately left at its default []
]);
$env->addExtension(new CommonMarkCoreExtension());
$env->addExtension(new AttributesExtension());
$converter = new MarkdownConverter($env);

$FF = "\x0C";

echo $converter->convert('hello {onclick="alert(1)"}')->getContent();
// <p>hello</p>                                    <- filtered, as documented

echo $converter->convert('hello {' . $FF . 'onclick="alert(1)"}')->getContent();
// <p \x0Conclick="alert(1)">hello</p>             <- BYPASS

Full observed output (\x0C shown escaped; it is a literal single byte in the real output):

#	Markdown input	Rendered output	Result
A	hello {onclick="alert(1)"}	<p>hello</p>	filtered (control)
B	hello {\x0Conclick="alert(1)"}	<p \x0Conclick="alert(1)">hello</p>	bypass
C	hello {\x0Bonclick="alert(1)"}	<p>hello</p>	filtered (control)
D	[click](javascript:alert(1))	<p><a>click</a></p>	filtered (control)
E	[click](https://example.com){\x0Chref="javascript:alert(1)"}	<p><a \x0Chref="javascript:alert(1)" href="https://example.com">click</a></p>	bypass
F	{\x0Conerror="alert(1)"}	<p><img \x0Conerror="alert(1)" src="…" alt="x" /></p>	bypass
G	# heading + newline + {\x0Conclick="alert(1)"}	<h1 \x0Conclick="alert(1)">heading</h1>	bypass (block syntax)

In case E the injected href precedes the legitimate one. Per the HTML5 duplicate-attribute rule
the first occurrence wins, so the javascript: URI is the one the browser actually uses.

Browser confirmation. Loading the library's unmodified output in Chrome for Testing 148:

<img> attribute names : ["onerror","src","alt"]      <- parsed as a real `onerror`
typeof img.onerror    : function                     <- bound as an event handler
handlers fired        : ["img-onerror"]              <- fired on load, no interaction
document.title        : XSS-FIRED
link href attribute   : "javascript:void(0)"
link href property    : "javascript:void(0)"         <- javascript: URI is the effective href
page errors           : []

The onerror case executes with no user interaction — rendering the attacker's Markdown is
sufficient.

Verified against git HEAD (f966b17a) and against tag 2.9.0, on PHP 8.5.8.

Impact

Stored cross-site scripting in any application that renders untrusted Markdown with
AttributesExtension enabled and attributes.allow left at its default [] — even when the
application has followed every hardening step in docs/2.x/security.md
(html_input => 'escape', allow_unsafe_links => false, max_nesting_level => 100).

Consequences are the usual for stored XSS: session and cookie theft, actions performed as the
viewing user, and account takeover where the host application permits it. Because the payload can
be attached to an image (onerror), it fires on page load without requiring the victim to
interact with anything.

The affected configuration is the extension's default: attributes.allow defaults to [], and
the documentation describes that default as safe with respect to on* attributes.

Workaround for users

Setting an explicit allow list takes the other branch of filterAttributes(), which drops the
form-feed name because it is not in the list:

$config = ['attributes' => ['allow' => ['id', 'class', 'align']]];

Verified: hello {\x0Conclick="alert(1)"} then renders as <p>hello</p>.

Suggested fix

The narrow fix is to add \x0C to the trim charlist at AttributesHelper.php lines 62, 89, 90
and 94. That closes this instance but leaves the shape of the problem in place.

A more durable fix is to reject anything that is not a well-formed attribute name in
filterAttributes(), reusing the constant the parser already defines (RegexHelper is already
imported in that file):

foreach ($attributes as $name => $value) {
    // Names are compared against literal strings below and emitted without escaping,
    // so anything that isn't a plain attribute name must not get through.
    if (\preg_match('/^' . RegexHelper::PARTIAL_ATTRIBUTENAME . '$/i', $name) !== 1) {
        unset($attributes[$name]);
        continue;
    }

    $attrNameLower = \strtolower($name);
    // ... existing logic unchanged
}

As defence in depth, HtmlElement::__toString() could validate or escape $key. It currently
trusts its callers to supply safe attribute names, and filterAttributes() is the only thing
standing between that method and user-supplied input.

Severity

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

References

• https://github.com/thephpleague/commonmark/security/advisories/GHSA-f8fg-pg57-v4j8
• https://github.com/thephpleague/commonmark/commit/dfcdf4554c16aa37c15e3a5ee3243ee26147c239
• https://github.com/thephpleague/commonmark/releases/tag/2.9.1
• https://github.com/advisories/GHSA-f8fg-pg57-v4j8

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

---

league/commonmark: Denial of service in the SmartPunct and Attributes extensions

GHSA-jjv6-8j6v-6j52

More information

Details

Impact

Two first-party extensions contain quadratic parsing paths. Both ship with the library but must be explicitly registered on the Environment; neither is included in CommonMarkConverter, GithubFlavoredMarkdownConverter, or GithubFlavoredMarkdownExtension. Applications that do not register SmartPunctExtension or AttributesExtension are not affected by this advisory.

1. SmartPunctExtension — quote replacement recopies the whole text node (affected from 2.0.0).

ReplaceUnpairedQuotesListener converts each unpaired Quote node back to a Text node and merges it into its neighbours via AdjacentTextMerger. The merge reads the left node's literal into a local variable, appends to that variable, and writes it back — and because the read aliases the node's string, every append copies the entire accumulated literal rather than only the bytes added. The listener runs this once per surviving unpaired quote against the same continuously growing text node, so the same buffer is fully re-copied a linear number of times.

A 1.2 MB document of alternating text segments and apostrophes takes 34.9 seconds to convert, against 0.069 seconds for the same input with the extension not registered.

Hardened configuration makes this worse rather than better: QuoteParser appends the Quote node to the AST before pushing it onto the delimiter stack, so max_delimiters_per_line removes the quote-pairing work while leaving every node the listener must process.

2. AttributesExtension — block-level attribute runs re-scan their siblings (affected from 1.5.0).

AttributesListener::findTargetAndDirection() walks the entire remaining sibling chain for every block-level Attributes node whose target is the following node. The backward half of that walk returns immediately for such nodes, and the forward half stops only at a sibling that is not itself an attributes node — which a contiguous run never provides — so a run of k nodes costs k(k-1)/2 steps.

An input placing each {#a} on its own line, with a single reference definition to keep the run contiguous, takes 28.4 seconds at 16,000 attribute blocks while producing zero bytes of output.

This is the block-level counterpart of GHSA-g2gp-3wwq-f4ph, patched in 2.9.0. That fix is incomplete: the early break it introduced is guarded on the node being an AttributesInline, so block-level Attributes nodes still re-scan. Applications that upgraded to 2.9.0 specifically to address GHSA-g2gp-3wwq-f4ph remain exposed to this variant.

3. AttributesExtension — class lists are rebuilt on every merge (affected from 1.5.0).

AttributesHelper::mergeAttributes() round-trips the accumulated class list through explode and implode on each merge. An #id attribute assigns a scalar and skips the branch entirely, but a .class attribute appends to an array which is then imploded to a string, written to the target node, and read back on the next iteration — so the ith merge pays a cost proportional to i three separate times.

{.c} repeated 32,000 times takes 33.5 seconds, against 0.26 seconds for byte-identical input using {#a} — a 130x gap that widens with input size. Both the inline and the block-level attribute paths are affected.

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.

No library-level configuration gates any of these paths. For the Attributes extension in particular, neither the attributes/allow allow-list nor the on* event-handler hardening added in 2.7.0 has any effect, because the expensive work happens while parsing and resolving the AST, before any attribute filtering or rendering takes place.

Patches

The issues are patched in 2.9.1 and later:

• Adjacent text merging now appends in place instead of reading, modifying, and writing back the whole literal, so a merge costs only the bytes added. This fixes the defect for every caller, not only the SmartPunct listener.
• AttributesListener now records the runs it has already walked, so each contiguous run of block-level attribute nodes is scanned once rather than once per node.
• Accumulated class lists no longer pass through mergeAttributes() repeatedly; the listener holds pending attributes and joins them in a single pass.

The SmartPunct path affects 2.0.0 through 2.9.0. The Attributes paths affect 1.5.0 through 2.9.0, including releases that already contain the 2.9.0 fix for GHSA-g2gp-3wwq-f4ph. The 1.x release line is no longer supported, so its users must upgrade to 2.9.1 or later.

Workarounds

If you cannot upgrade immediately:

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

Restricting conversion to trusted users, applying strict execution-time limits, and rate-limiting requests reduce exposure but are not substitutes for upgrading. Configuration options including attributes/allow, max_delimiters_per_line, max_nesting_level, html_input, and allow_unsafe_links do not mitigate these issues.

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

• https://github.com/thephpleague/commonmark/security/advisories/GHSA-jjv6-8j6v-6j52
• https://github.com/thephpleague/commonmark/commit/04a5d11ef6bf2d0b927310810d6a2a85d3c184b9
• https://github.com/thephpleague/commonmark/commit/2f611b599c51661b005dc45c16ceaa547546e687
• https://github.com/thephpleague/commonmark/releases/tag/2.9.1
• https://github.com/advisories/GHSA-jjv6-8j6v-6j52

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

---

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

GHSA-8rr7-cvq3-gmfh

More information

Details

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.

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

• https://github.com/thephpleague/commonmark/security/advisories/GHSA-8rr7-cvq3-gmfh
• https://github.com/thephpleague/commonmark/commit/f27eb720972490b5af4dbb635ad8634529faf9f2
• https://github.com/thephpleague/commonmark/releases/tag/2.10.0
• https://github.com/advisories/GHSA-8rr7-cvq3-gmfh

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

---

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

GHSA-j8pm-gj4c-rq4x

More information

Details

Impact

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:

Path	Affected from	Affected through
1. Fenced code block detection	0.6.0	2.9.0
2. Reference link label lookup	0.6.0	2.9.0
3. Emphasis / strikethrough delimiters (*, _, ~)	2.6.0	2.9.0
3. Highlight delimiters (=)	2.9.0	2.9.0

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.

Patches

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.

Workarounds

If you cannot upgrade immediately, enforce a maximum length for individual lines before passing input to the converter, in addition to a total request-size limit. A per-line limit matters because every trigger described above fits within a single line. Because the cost grows super-linearly, the cap must be genuinely small to bound worst-case CPU.

Setting max_delimiters_per_line reduces exposure to the delimiter path only, and does so by silently dropping emphasis from the rendered output. It has no effect on the fenced code or reference link paths.

Restricting conversion to trusted users, applying strict execution-time limits, rate-limiting requests, and limiting concurrent conversions all reduce exposure, but none is a complete substitute for upgrading.

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

• https://github.com/thephpleague/commonmark/security/advisories/GHSA-j8pm-gj4c-rq4x
• https://github.com/thephpleague/commonmark/commit/0768217751fbfaeb8d76762f6944e9af7114295e
• https://github.com/thephpleague/commonmark/commit/d9375fadc308a63a02950a68d822417a6e4c33b2
• https://github.com/thephpleague/commonmark/commit/e0036ef031fd36ec1c3c82db8743fc928b5271c8
• https://github.com/thephpleague/commonmark/releases/tag/2.9.1
• https://github.com/advisories/GHSA-j8pm-gj4c-rq4x

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

---

league/commonmark: Quadratic-time denial of service in the GitHub Flavored Markdown Table extension block-start scan

GHSA-3q6v-r5mr-hxv8

More information

Details

Summary

league/commonmark's GitHub Flavored Markdown Table extension registers TableStartParser as a block-start parser. While a paragraph is the active block, the core block parser calls TableStartParser::tryStart() on every non-blank line. Its first action fetches the entire growing paragraph buffer via getParagraphContent() and runs strpos($paragraph, '|') across all of it. For a paragraph of M pipe-free lines, line k rescans about k lines of buffer, so total work is 1+2+...+M, which is O(M^2). An unauthenticated user who submits a single large paragraph of pipe-free lines that do not begin with a letter (see Attack Chain) to any service that converts untrusted Markdown with GithubFlavoredMarkdownConverter (or any environment that enables TableExtension) drives seconds to tens of seconds of single-core CPU that grows quadratically with body size, enough to exhaust worker processes and deny service.

Root Cause

The GFM table detector performs a per-line "quick check" against the whole accumulated paragraph rather than only the portion that could form a table header. A paragraph never closes while non-blank lines keep arriving, so its buffer grows without bound, and the quick check rescans the entire buffer on each line. Only the paragraph's last line can ever be a table header (it is extracted separately via strrpos/substr), so scanning the full multi-line buffer for a pipe on every line is unnecessary work and creates quadratic time complexity. There is no input-size cap and the default nesting limit is not reached, so nothing bounds the scan.

Affected function: League\CommonMark\Extension\Table\TableStartParser::tryStart
Location: src/Extension/Table/TableStartParser.php:35-38
  $paragraph = $parserState->getParagraphContent();       // returns the FULL growing buffer
  if ($paragraph === null || \strpos($paragraph, '|') === false) {
      return BlockStart::none();                           // strpos scans whole buffer each line
  }
Buffer growth: src/Reference/ReferenceParser.php:89-95 ($this->paragraph .= "\n"; $this->paragraph .= $line;)
Per-line dispatch: src/Parser/MarkdownParser.php:135-147 and :224-236

Impact

An unauthenticated, remote attacker with no user interaction can cause denial of service against any application that renders untrusted Markdown with the GitHub Flavored Markdown converter or any configuration that enables the Table extension (the default GFM bundle enables it). A single request carrying a large paragraph of pipe-free, blank-line-free lines that do not begin with a letter consumes CPU proportional to the square of the input size: measured runs show roughly 4x CPU growth per input doubling. A body of a few megabytes ties up a worker for seconds to tens of seconds; repeated or concurrent requests exhaust all available PHP worker processes, denying service to legitimate users. Impact is limited to availability; there is no confidentiality or integrity impact.

Proof of Concept

Requires PHP with league/commonmark 2.x installed. The harness parses pipe-free paragraphs of increasing size with the real MarkdownParser and the real block-start parsers, comparing a GFM-plus-Table configuration against a core-only configuration to isolate the Table parser's contribution.

1. Install league/commonmark (2.10.1 or any 2.x release).
2. Convert a single large paragraph of pipe-free, blank-line-free lines that do not begin with a letter, with GithubFlavoredMarkdownConverter.
3. Measure wall-clock time as the paragraph size doubles.

<?php
require 'vendor/autoload.php';
use League\CommonMark\GithubFlavoredMarkdownConverter;

$converter = new GithubFlavoredMarkdownConverter();
foreach ([25000, 50000, 100000, 200000] as $lines) {
    $md = str_repeat("12345678\n", $lines); // one paragraph, no blank lines, no '|', lines not starting with a letter
    $t = microtime(true);
    $converter->convert($md);
    printf("%7d lines  %6.3fs\n", $lines, microtime(true) - $t);
}

   lines    input    letter-leading    non-letter-leading
                     ("aaaaaaaa")          ("12345678")
   25000   0.23MB        0.27s               0.75s
   50000   0.45MB        0.50s               2.36s
  100000   0.90MB        1.07s               7.70s
  200000   1.80MB        2.26s              27.81s

Letter-leading input scales linearly (doubles per input doubling) because SkipLinesStartingWithLettersParser aborts before the Table parser is reached. Non-letter-leading input quadruples per doubling (0.75, 2.36, 7.70, 27.81), confirming O(M^2) behavior attributable to the Table start parser.

Attack Chain

1. Exposure: The attacker submits a Markdown body to any endpoint that converts untrusted Markdown with GithubFlavoredMarkdownConverter, or any environment that adds TableExtension. The default GFM bundle registers the Table extension: GithubFlavoredMarkdownExtension adds TableExtension (src/Extension/GithubFlavoredMarkdownExtension.php:30), which registers TableStartParser (src/Extension/Table/TableExtension.php:56).
2. Control: The attacker fully controls the Markdown body. The exploit input is one paragraph with no blank lines, no | character, and lines that do not begin with a letter (for example str_repeat("12345678\n", 200000)).
3. Path: MarkdownParser::parseLine() loops over block-start parsers for every non-blank line while a paragraph is active (src/Parser/MarkdownParser.php:135-147). ParagraphParser::tryContinue() keeps the paragraph open for every non-blank line, so the buffer keeps growing (src/Parser/Block/ParagraphParser.php:46-53), appended line by line in ReferenceParser::parse() (src/Reference/ReferenceParser.php:89-95). Since 2.0.2, the highest-priority SkipLinesStartingWithLettersParser returns BlockStart::abort() for any line whose first non-space character is a letter, short-circuiting findBlockStart() before TableStartParser. When lines begin with a non-letter (e.g. a digit), that parser returns none and every remaining core parser returns null, so control reaches TableStartParser on every line (src/Parser/MarkdownParser.php:224-236).
4. Guard: There is no input-size cap in MarkdownInput, and max_nesting_level defaults to PHP_INT_MAX, which the depth-1 paragraph never approaches. No guard bounds the whole-buffer scan.
5. Primitive: TableStartParser::tryStart() runs strpos($paragraph, '|') over the entire buffer returned by getParagraphContent() (src/Extension/Table/TableStartParser.php:35-38). With no pipe present, strpos scans to the end of the buffer on every line.
6. Result: Cumulative scanning work is O(M^2). A single small request drives disproportionate, quadratically growing CPU, exhausting worker processes and denying service.

Bypass Evidence

No prior fix exists for this code path, so this is not an incomplete-fix or regression case; it is a distinct, previously undisclosed quadratic path. The strongest disproof attempts were made and all failed:

• Attempt: the observed quadratic is core-parser or PHP string overhead, not the Table parser. Refuted: the only difference between the two measured configurations is TableStartParser; the core-only baseline is linear while the isolated Table contribution quadruples per input doubling.
• Attempt: strpos short-circuits or the buffer does not actually grow. Refuted by source trace: ReferenceParser::parse() appends every line unconditionally before its state switch, and for pipe-free text strpos finds no | and scans the full buffer each line.
• Attempt: another parser short-circuits before TableStartParser. Partially correct: since 2.0.2 SkipLinesStartingWithLettersParser aborts block-start scanning for lines beginning with a letter, so letter-leading input (including the original aaaaaaaa PoC) never reaches the Table parser and runs in linear time. Input whose lines begin with a non-letter (e.g. a digit) passes every core parser and reaches TableStartParser on every line, exhibiting the quadratic behavior.
• Attempt: an input-size or nesting guard neutralizes it. Refuted: there is no size cap and the default nesting limit is never reached.
• Attempt: this duplicates an existing quadratic-DoS advisory or was already fixed. Refuted: published quadratic advisories address per-line position translation and other distinct mechanisms in other files; git log on src/Extension/Table/TableStartParser.php shows no security fix ever touched this rescan, and the code is present unchanged in the latest release.

Affected Versions

• Ecosystem: composer
• Package: league/commonmark
• Confirmed affected range: >= 2.0.0, <= 2.10.1
• Latest release checked: 2.10.1 (Packagist, repo.packagist.org/p2/league/commonmark.json)
• Fix status: not fixed

Note: SkipLinesStartingWithLettersParser was introduced in 2.0.2. On 2.0.0 and 2.0.1 the issue can also be triggered with letter-leading lines. Regardless, the underlying quadratic scan itself is present across the whole >= 2.0.0, <= 2.10.1 range.

The vulnerable rescan is artifact-verified present in tags 2.8.0 and 2.10.1 (the latest published release). The lower bound 2.0.0 is inferred from the 2.x block-parser rewrite that introduced the getParagraphContent()-based architecture this quick check depends on; the checkout contains only tags 2.8.0 through 2.10.1, so the path is not artifact-verified below 2.8.0. No published release removes or bounds the whole-buffer scan.

Suggested Fix

Enforce that the per-line quick check inspects only the paragraph's last line, which is the only line that can form a table header. Compute the last line break with strrpos($paragraph, "\n"), derive the last line, and test strpos($lastLine, '|') instead of scanning the whole buffer. This bounds the per-line check to the length of the last line and removes the quadratic behavior without changing table detection semantics. As an interim mitigation without a code change, operators can cap the size of untrusted Markdown accepted for conversion, or disable the Table extension for untrusted input, which reduces exposure but does not remove the underlying quadratic path.

Reported by zx (GitHub: @​manus-pi).

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

• https://github.com/thephpleague/commonmark/security/advisories/GHSA-3q6v-r5mr-hxv8
• https://github.com/thephpleague/commonmark/commit/5f63680a5e29dd57f9c6be9743b0e90493d3c2d0
• https://github.com/thephpleague/commonmark/releases/tag/2.10.2
• https://github.com/advisories/GHSA-3q6v-r5mr-hxv8

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

---

league/commonmark: DisallowedRawHtml bypassed when a disallowed tag name ends the raw-HTML literal

GHSA-97jj-33gv-5xf9

More information

Details

## Summary

The DisallowedRawHtml extension does not escape a disallowed tag when the tag name is the last thing in the raw HTML. A Markdown line containing just <script is emitted unchanged, and the next block can supply its attributes. With the shipped GFM defaults this allows stored XSS by anyone who can post Markdown.

Details

DisallowedRawHtmlRenderer escapes tags with this regex:

/<(\/?(?:title|textarea|style|xmp|iframe|noembed|noframes|script|plaintext)[\s\/>])/i

The trailing character class requires one character after the tag name. The block parser does not: RegexHelper::PARTIAL_HTMLBLOCKOPEN accepts end of line after a tag name, so <script alone opens an HTML block. Because a rendered HtmlBlock has no trailing newline, the regex has nothing to match and the < passes through.

In the browser the newline is still present, so the tag name terminates there and whatever follows becomes attributes.

This is the same filter that GHSA-4v6x-c7xx-hw9f fixed in 2.8.1. That fix widened the character class but still requires one character, so this case was not covered.

Reproduction

Render this with GithubFlavoredMarkdownConverter and default settings:

<div>
<script

<span src="/evil.js">

Output:

<div>
<script
<span src="/evil.js">

A browser parses that as <script src="/evil.js"> with a junk <span attribute, and the script runs. <iframe with <span onload="..."> works the same way and does not need a later </script> in the page.

Control: <script src="/evil.js"></script> is correctly escaped to <script src="/evil.js"></script>.

Affected versions

1.3.0 (when the extension was added) through the current release. The </style and mid-line forms are only affected as continuation lines inside an already-open HTML block.

Preconditions

• html_input is allow (the default)
• The DisallowedRawHtml extension is active, which the GFM extension enables automatically
• Untrusted users can post Markdown

Setting html_input to escape or strip fully mitigates this.

Suggested fix

Allow end of string after the tag name:

$regex = \sprintf('/<(\/?(?:%s))([\s\/>]|$)/i', \implode('|', \array_map('preg_quote', $tags)));

return \preg_replace($regex, '&lt;$1$2', $rendered);

This escapes every bypass shape above and leaves <div>, <scripts> and <span class="a"> untouched. The existing unit test only covers tag names followed by another character, so a case for a bare tag name should be added.

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

• https://github.com/thephpleague/commonmark/security/advisories/GHSA-97jj-33gv-5xf9
• https://github.com/thephpleague/commonmark/commit/411afcc2a7402756d96c89af8882c724d12d47ca
• https://github.com/thephpleague/commonmark/releases/tag/2.10.2
• https://github.com/advisories/GHSA-97jj-33gv-5xf9

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

---

league/commonmark XSS: on* event-handler filter in AttributesExtension bypassed with a U+000C form feed

CVE-2026-86431 / GHSA-f8fg-pg57-v4j8

More information

Details

Summary

The AttributesExtension documents a security guarantee:

Note: Attributes starting with on (e.g. onclick or onerror) are capable of executing
JavaScript code and are therefore never allowed by default. You must explicitly add them to
the allow list if you want to use them.

— docs/2.x/extensions/attributes.md

Prefixing the attribute name with a single U+000C FORM FEED byte defeats that guarantee.
{<FF>onclick="alert(1)"} passes through AttributesHelper::filterAttributes() untouched and is
written verbatim into the output, where browsers parse it as a genuine onclick handler.

The same prefix defeats the allow_unsafe_links check, letting a javascript: URI through on
href / src even when allow_unsafe_links is false.

This bypasses the fix shipped in the 2.7.0 security release ("Fix XSS in AttributesExtension",
43207253ea5f14867c77c697cd3838c446cadcea), which added filterAttributes() for the express
purpose of blocking these attributes.

Throughout this report <FF> denotes a literal U+000C byte ("\x0C" in PHP). It is invisible in
rendered text, so all payloads below are written with PHP escape sequences to stay unambiguous.

Details

Three behaviours combine.

1. \x0C survives the parser's trim().

AttributesHelper::SINGLE_ATTRIBUTE begins with \s*, and Cursor::match() returns
$matches[0][0] — the entire match, including that leading whitespace. The result is cleaned
with PHP's trim():

// src/Extension/Attributes/Util/AttributesHelper.php:62
while ($attribute = \trim((string) $attributeCursor->match('/^' . self::SINGLE_ATTRIBUTE . '/i'))) {

PCRE \s matches \x0C, but PHP's default trim() charlist is " \t\n\r\0\x0B" — it includes
the vertical tab \x0B but not the form feed \x0C. The byte is therefore consumed by the
regex, retained in the returned match, and not stripped. It ends up inside the attribute name:

// src/Extension/Attributes/Util/AttributesHelper.php:94
$attributes[\trim($name)] = \trim($value);   // $name === "\x0Conclick"

\x0C is the only byte with this property: every other character the HTML5 tokenizer treats as
whitespace (\x09, \x0A, \x0D, \x20), plus \x0B, is in PHP's trim charlist. The PoC
includes a \x0B case as a control, and it is correctly stripped.

2. The filter's string comparisons miss it.

filterAttributes() compares the raw name against literal strings:

// src/Extension/Attributes/Util/AttributesHelper.php:148-166
$attrNameLower = \strtolower($name);                            // "\x0conclick"
... ($attrNameLower === 'href' || $attrNameLower === 'src') ... // false
... \str_starts_with($attrNameLower, 'on') ...                  // false -> not removed

3. The renderer never escapes attribute names.

// src/Util/HtmlElement.php:123-129
$result .= ' ' . $key . '="' . Xml::escape($value) . '"';   // $key emitted raw

Because the HTML5 tokenizer treats \x0C as whitespace between attributes, the browser reads
the name as plain onclick.

PoC

<?php
require 'vendor/autoload.php';

use League\CommonMark\Environment\Environment;
use League\CommonMark\Extension\Attributes\AttributesExtension;
use League\CommonMark\Extension\CommonMark\CommonMarkCoreExtension;
use League\CommonMark\MarkdownConverter;

// The most defensive configuration docs/2.x/security.md recommends.
$env = new Environment([
    'html_input'         => 'escape',
    'allow_unsafe_links' => false,
    'max_nesting_level'  => 100,
    // 'attributes' => ['allow' => [...]] deliberately left at its default []
]);
$env->addExtension(new CommonMarkCoreExtension());
$env->addExtension(new AttributesExtension());
$converter = new MarkdownConverter($env);

$FF = "\x0C";

echo $converter->convert('hello {onclick="alert(1)"}')->getContent();
// <p>hello</p>                                    <- filtered, as documented

echo $converter->convert('hello {' . $FF . 'onclick="alert(1)"}')->getContent();
// <p \x0Conclick="alert(1)">hello</p>             <- BYPASS

Full observed output (\x0C shown escaped; it is a literal single byte in the real output):

#	Markdown input	Rendered output	Result
A	hello {onclick="alert(1)"}	<p>hello</p>	filtered (control)
B	hello {\x0Conclick="alert(1)"}	<p \x0Conclick="alert(1)">hello</p>	bypass
C	hello {\x0Bonclick="alert(1)"}	<p>hello</p>	filtered (control)
D	[click](javascript:alert(1))	<p><a>click</a></p>	filtered (control)
E	[click](https://example.com){\x0Chref="javascript:alert(1)"}	<p><a \x0Chref="javascript:alert(1)" href="https://example.com">click</a></p>	bypass
F	{\x0Conerror="alert(1)"}	<p><img \x0Conerror="alert(1)" src="…" alt="x" /></p>	bypass
G	# heading + newline + {\x0Conclick="alert(1)"}	<h1 \x0Conclick="alert(1)">heading</h1>	bypass (block syntax)

In case E the injected href precedes the legitimate one. Per the HTML5 duplicate-attribute rule
the first occurrence wins, so the javascript: URI is the one the browser actually uses.

Browser confirmation. Loading the library's unmodified output in Chrome for Testing 148:

<img> attribute names : ["onerror","src","alt"]      <- parsed as a real `onerror`
typeof img.onerror    : function                     <- bound as an event handler
handlers fired        : ["img-onerror"]              <- fired on load, no interaction
document.title        : XSS-FIRED
link href attribute   : "javascript:void(0)"
link href property    : "javascript:void(0)"         <- javascript: URI is the effective href
page errors           : []

The onerror case executes with no user interaction — rendering the attacker's Markdown is
sufficient.

Verified against git HEAD (f966b17a) and against tag 2.9.0, on PHP 8.5.8.

Impact

Stored cross-site scripting in any application that renders untrusted Markdown with
AttributesExtension enabled and attributes.allow left at its default [] — even when the
application has followed every hardening step in docs/2.x/security.md
(html_input => 'escape', allow_unsafe_links => false, max_nesting_level => 100).

Consequences are the usual for stored XSS: session and cookie theft, actions performed as the
viewing user, and account takeover where the host application permits it. Because the payload can
be attached to an image (onerror), it fires on page load without requiring the victim to
interact with anything.

The affected configuration is the extension's default: attributes.allow defaults to [], and
the documentation describes that default as safe with respect to on* attributes.

Workaround for users

Setting an explicit allow list takes the other branch of filterAttributes(), which drops the
form-feed name because it is not in the list:

$config = ['attributes' => ['allow' => ['id', 'class', 'align']]];

Verified: hello {\x0Conclick="alert(1)"} then renders as <p>hello</p>.

Suggested fix

The narrow fix is to add \x0C to the trim charlist at AttributesHelper.php lines 62, 89, 90
and 94. That closes this instance but leaves the shape of the problem in place.

A more durable fix is to reject anything that is not a well-formed attribute name in
filterAttributes(), reusing the constant the parser already defines (RegexHelper is already
imported in that file):

foreach ($attributes as $name => $value) {
    // Names are compared against literal strings below and emitted without escaping,
    // so anything that isn't a plain attribute name must not get through.
    if (\preg_match('/^' . RegexHelper::PARTIAL_ATTRIBUTENAME . '$/i', $name) !== 1) {
        unset($attributes[$name]);
        continue;
    }

    $attrNameLower = \strtolower($name);
    // ... existing logic unchanged
}

As defence in depth, HtmlElement::__toString() could validate or escape $key. It currently
trusts its callers to supply safe attribute names, and filterAttributes() is the only thing
standing between that method and user-supplied input.

Severity

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

References

• https://github.com/thephpleague/commonmark/security/advisories/GHSA-f8fg-pg57-v4j8
• https://github.com/thephpleague/commonmark/commit/dfcdf4554c16aa37c15e3a5ee3243ee26147c239
• https://github.com/thephpleague/commonmark
• https://github.com/thephpleague/commonmark/releases/tag/2.9.1

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

---

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

CVE-2026-86430 / GHSA-j8pm-gj4c-rq4x

More information

Details

Impact

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:

Path	Affected from	Affected through
1. Fenced code block detection	0.6.0	2.9.0
2. Reference link label lookup	0.6.0	2.9.0
3. Emphasis / strikethrough delimiters (*, _, ~)	2.6.0	2.9.0
3. Highlight delimiters (=)	2.9.0	2.9.0

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

FencedCodeStartParser matches th

❗ Important

✂ PR body was truncated to here.

[renovate]

Branch automerge failure

This PR was configured for branch automerge. However, this is not possible, so it has been raised as a PR instead.

---

• Branch has one or more failed status checks

[github-actions]

Hello 👋

here is the most recent benchmark result:

SplitStreamBench
================

+-------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
|                         | time (kde mode)                                     | memory                                     |
+-------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| subject                 | Tag: <current>     | Tag: base          | time-diff | Tag: <current>  | Tag: base  | memory-diff |
+-------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| benchLoad10000Events () | 4.124ms (±0.00%)   | 4.370ms (±0.00%)   | -5.64%    | 35.654mb        | 36.172mb   | -1.43%      |
| benchSave10000Events () | 311.333ms (±0.00%) | 333.730ms (±0.00%) | -6.71%    | 35.656mb        | 35.656mb   | 0.00%       |
+-------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+

SubscriptionEngineBench
=======================

+---------------------------+-----------------+-----------------+-----------+-----------------+------------+-------------+
|                           | time (kde mode)                               | memory                                     |
+---------------------------+-----------------+-----------------+-----------+-----------------+------------+-------------+
| subject                   | Tag: <current>  | Tag: base       | time-diff | Tag: <current>  | Tag: base  | memory-diff |
+---------------------------+-----------------+-----------------+-----------+-----------------+------------+-------------+
| benchHandle10000Events () | 2.483s (±0.00%) | 2.475s (±0.00%) | +0.34%    | 47.564mb        | 47.564mb   | 0.00%       |
+---------------------------+-----------------+-----------------+-----------+-----------------+------------+-------------+

NoopSubscriptionEngineBench
===========================

+---------------------------+-------------------+-------------------+-----------+-----------------+------------+-------------+
|                           | time (kde mode)                                   | memory                                     |
+---------------------------+-------------------+-------------------+-----------+-----------------+------------+-------------+
| subject                   | Tag: <current>    | Tag: base         | time-diff | Tag: <current>  | Tag: base  | memory-diff |
+---------------------------+-------------------+-------------------+-----------+-----------------+------------+-------------+
| benchHandle10000Events () | 88.494ms (±0.00%) | 79.835ms (±0.00%) | +10.85%   | 47.564mb        | 47.564mb   | 0.00%       |
+---------------------------+-------------------+-------------------+-----------+-----------------+------------+-------------+

SimpleSetupStreamStoreBench
===========================

+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
|                                        | time (kde mode)                                     | memory                                     |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| subject                                | Tag: <current>     | Tag: base          | time-diff | Tag: <current>  | Tag: base  | memory-diff |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| benchLoad1Event ()                     | 947.300μs (±0.00%) | 928.700μs (±0.00%) | +2.00%    | 35.210mb        | 35.210mb   | 0.00%       |
| benchLoad10000Events ()                | 54.506ms (±0.00%)  | 52.779ms (±0.00%)  | +3.27%    | 35.211mb        | 35.211mb   | 0.00%       |
| benchSave1Event ()                     | 1.264ms (±0.00%)   | 1.121ms (±0.00%)   | +12.76%   | 35.210mb        | 35.210mb   | 0.00%       |
| benchSave10000Events ()                | 234.358ms (±0.00%) | 243.438ms (±0.00%) | -3.73%    | 35.211mb        | 35.211mb   | 0.00%       |
| benchSave10000Aggregates ()            | 15.875s (±0.00%)   | 7.421s (±0.00%)    | +113.92%  | 35.211mb        | 35.211mb   | 0.00%       |
| benchSave10000AggregatesTransaction () | 3.775s (±0.00%)    | 3.786s (±0.00%)    | -0.28%    | 35.211mb        | 35.211mb   | 0.00%       |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+

SubscriptionEngineBatchBench
============================

+---------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
|                           | time (kde mode)                                     | memory                                     |
+---------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| subject                   | Tag: <current>     | Tag: base          | time-diff | Tag: <current>  | Tag: base  | memory-diff |
+---------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| benchHandle10000Events () | 100.766ms (±0.00%) | 103.875ms (±0.00%) | -2.99%    | 35.549mb        | 35.549mb   | 0.00%       |
+---------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+

SimpleSetupBench
================

+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
|                                        | time (kde mode)                                     | memory                                     |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| subject                                | Tag: <current>     | Tag: base          | time-diff | Tag: <current>  | Tag: base  | memory-diff |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| benchLoad1Event ()                     | 950.100μs (±0.00%) | 966.600μs (±0.00%) | -1.71%    | 34.983mb        | 34.983mb   | 0.00%       |
| benchLoad10000Events ()                | 47.457ms (±0.00%)  | 49.087ms (±0.00%)  | -3.32%    | 34.983mb        | 34.983mb   | 0.00%       |
| benchSave1Event ()                     | 1.010ms (±0.00%)   | 1.048ms (±0.00%)   | -3.62%    | 34.983mb        | 34.983mb   | 0.00%       |
| benchSave10000Events ()                | 173.881ms (±0.00%) | 181.744ms (±0.00%) | -4.33%    | 34.983mb        | 34.983mb   | 0.00%       |
| benchSave10000Aggregates ()            | 8.722s (±0.00%)    | 8.571s (±0.00%)    | +1.77%    | 34.983mb        | 34.983mb   | 0.00%       |
| benchSave10000AggregatesTransaction () | 3.658s (±0.00%)    | 3.662s (±0.00%)    | -0.12%    | 34.983mb        | 34.983mb   | 0.00%       |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+

PersonalDataBench
=================

+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
|                                        | time (kde mode)                                     | memory                                     |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| subject                                | Tag: <current>     | Tag: base          | time-diff | Tag: <current>  | Tag: base  | memory-diff |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| benchLoad1Event ()                     | 1.180ms (±0.00%)   | 1.154ms (±0.00%)   | +2.18%    | 35.589mb        | 35.589mb   | 0.00%       |
| benchLoad10000Events ()                | 71.538ms (±0.00%)  | 72.255ms (±0.00%)  | -0.99%    | 35.589mb        | 35.589mb   | 0.00%       |
| benchSave1Event ()                     | 1.485ms (±0.00%)   | 1.480ms (±0.00%)   | +0.36%    | 35.589mb        | 35.589mb   | 0.00%       |
| benchSave10000Events ()                | 213.767ms (±0.00%) | 204.472ms (±0.00%) | +4.55%    | 35.591mb        | 35.591mb   | 0.00%       |
| benchSave10000Aggregates ()            | 15.882s (±0.00%)   | 18.116s (±0.00%)   | -12.33%   | 35.589mb        | 35.589mb   | 0.00%       |
| benchSave10000AggregatesTransaction () | 6.899s (±0.00%)    | 6.848s (±0.00%)    | +0.74%    | 36.049mb        | 36.049mb   | 0.00%       |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+

SnapshotsBench
==============

+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
|                                        | time (kde mode)                                     | memory                                     |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| subject                                | Tag: <current>     | Tag: base          | time-diff | Tag: <current>  | Tag: base  | memory-diff |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+
| benchLoad10000EventsMissingSnapshot () | 47.703ms (±0.00%)  | 49.479ms (±0.00%)  | -3.59%    | 35.054mb        | 35.054mb   | 0.00%       |
| benchLoad10000Events ()                | 929.900μs (±0.00%) | 894.500μs (±0.00%) | +3.96%    | 35.054mb        | 35.054mb   | 0.00%       |
+----------------------------------------+--------------------+--------------------+-----------+-----------------+------------+-------------+

CommandToQueryBench
===================

+----------------+------------------+-------------------+-----------+-----------------+------------+-------------+
|                | time (kde mode)                                  | memory                                     |
+----------------+------------------+-------------------+-----------+-----------------+------------+-------------+
| subject        | Tag: <current>   | Tag: base         | time-diff | Tag: <current>  | Tag: base  | memory-diff |
+----------------+------------------+-------------------+-----------+-----------------+------------+-------------+
| benchCreate () | 2.208ms (±0.00%) | 2.252ms (±0.00%)  | -1.96%    | 4.980mb         | 4.980mb    | 0.00%       |
| benchUpdate () | 3.295ms (±0.00%) | 3.483ms (±0.00%)  | -5.39%    | 4.986mb         | 4.986mb    | 0.00%       |
| benchBoth ()   | 6.392ms (±0.00%) | 20.872ms (±0.00%) | -69.37%   | 5.029mb         | 5.029mb    | 0.00%       |
+----------------+------------------+-------------------+-----------+-----------------+------------+-------------+

This comment gets update everytime a new commit comes in!