GHSA-253C-MCHW-3W2R

Vulnerability from github – Published: 2026-09-29 17:57 – Updated: 2026-09-29 17:57
VLAI
Summary
markdown-it linkify: true has two quadratic paths, so a few hundred KB of markdown blocks the event loop for tens of seconds
Details

Summary

Two independent quadratic paths in the linkify: true handling. Both are in markdown-it's own code rather than in linkify-it, which stays linear on both payloads.

src/rules_core/linkify.ts calls arrayReplaceAt once per linkified text token, and that rebuilds the whole children array each time. A paragraph of N soft-broken lines is one inline token with about 2N children, so you get N rebuilds over a 2N array. Schema-less emails are what reach it. A http:// link gets consumed by the inline rule first and never arrives as a text token, so those stay linear.

src/rules_inline/linkify.ts runs state.pending.match(SCHEME_RE) at every :// in the source. state.pending only gets truncated once a link is actually produced, so an unregistered scheme leaves it growing and every :// rescans the lot.

Proof of concept

Clean install of 15.0.0 from npm, new MarkdownIt({ linkify: true }).render(payload), Node 24.

N 5,000 10,000 20,000 40,000
'a@b.co\n'.repeat(N), 34KB to 273KB 1.1s 4.7s 19.6s 89s
'a://'.repeat(N), 20KB to 156KB 0.25s 0.76s 3.1s 15.0s

Doubling the input roughly quadruples the time in both. With linkify: false the same inputs run in 25 to 131ms and stay flat.

Controls for the first one, all at N=20000: putting every email in a single text token ('a@b.co ') takes 0.59s, one email per paragraph ('a@b.co\n\n') takes 0.64s, and soft-broken lines with nothing linkifiable take 42ms. So it needs many children AND many of them linkifying. For the second, replaying just the SCHEME_RE calls against the same growing prefixes with no markdown-it involved accounts for 11.7s of the 15s.

Ordinary prose does it too. 'ping a@b.co ok\n'.repeat(20000) is 293KB and takes 31s.

Caveat

linkify is off by default, so this only reaches apps that turn it on.

Impact

Availability only. A few hundred KB of fairly ordinary markdown pins one core for tens of seconds, and because it's quadratic it degrades quickly with size. Nothing is read, written or executed.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "markdown-it"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.0"
            },
            {
              "fixed": "15.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "15.0.0"
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "markdown-it"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T17:57:56Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nTwo independent quadratic paths in the `linkify: true` handling. Both are in markdown-it\u0027s own code rather than in linkify-it, which stays linear on both payloads.\n\n`src/rules_core/linkify.ts` calls `arrayReplaceAt` once per linkified text token, and that rebuilds the whole `children` array each time. A paragraph of N soft-broken lines is one inline token with about 2N children, so you get N rebuilds over a 2N array. Schema-less emails are what reach it. A `http://` link gets consumed by the inline rule first and never arrives as a text token, so those stay linear.\n\n`src/rules_inline/linkify.ts` runs `state.pending.match(SCHEME_RE)` at every `://` in the source. `state.pending` only gets truncated once a link is actually produced, so an unregistered scheme leaves it growing and every `://` rescans the lot.\n\n## Proof of concept\n\nClean install of 15.0.0 from npm, `new MarkdownIt({ linkify: true }).render(payload)`, Node 24.\n\n| N | 5,000 | 10,000 | 20,000 | 40,000 |\n|---|---|---|---|---|\n| `\u0027a@b.co\\n\u0027.repeat(N)`, 34KB to 273KB | 1.1s | 4.7s | 19.6s | 89s |\n| `\u0027a://\u0027.repeat(N)`, 20KB to 156KB | 0.25s | 0.76s | 3.1s | 15.0s |\n\nDoubling the input roughly quadruples the time in both. With `linkify: false` the same inputs run in 25 to 131ms and stay flat.\n\nControls for the first one, all at N=20000: putting every email in a single text token (`\u0027a@b.co \u0027`) takes 0.59s, one email per paragraph (`\u0027a@b.co\\n\\n\u0027`) takes 0.64s, and soft-broken lines with nothing linkifiable take 42ms. So it needs many children AND many of them linkifying. For the second, replaying just the `SCHEME_RE` calls against the same growing prefixes with no markdown-it involved accounts for 11.7s of the 15s.\n\nOrdinary prose does it too. `\u0027ping a@b.co ok\\n\u0027.repeat(20000)` is 293KB and takes 31s.\n\n## Caveat\n\n`linkify` is off by default, so this only reaches apps that turn it on.\n\n## Impact\n\nAvailability only. A few hundred KB of fairly ordinary markdown pins one core for tens of seconds, and because it\u0027s quadratic it degrades quickly with size. Nothing is read, written or executed.",
  "id": "GHSA-253c-mchw-3w2r",
  "modified": "2026-09-29T17:57:56Z",
  "published": "2026-09-29T17:57:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/security/advisories/GHSA-253c-mchw-3w2r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/commit/09fa07118dda4c953f058848f53dae88395618ca"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/commit/aaadcfa6d817b3c5f89afb49d97c7b797a6dd4fd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/commit/ad70f6b7cff64bee10e42a774147112480ca0d49"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/markdown-it/markdown-it"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "markdown-it linkify: true has two quadratic paths, so a few hundred KB of markdown blocks the event loop for tens of seconds"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…