Outdated Markdown Library Can Be Used to Slow Down or Crash Your App

Vulnerability Explanation

The markdown-it linkify function uses the regular expression /\*+$/ to match trailing asterisks when auto-linking URLs. This pattern is susceptible to catastrophic backtracking: when the regex engine is fed a long sequence of asterisk characters followed by a non-matching character, it must exhaustively explore an exponentially growing number of possible match paths before concluding there is no match. Because JavaScript's regex engine uses backtracking-based NFA evaluation, this causes CPU time to grow super-linearly with input length. An attacker who can submit markdown input to any endpoint that calls markdown-it with linkify enabled can trigger this condition with a simple crafted string.

Root Cause

The vulnerable regex /\*+$/ uses a greedy quantifier (+) on a character class that can match the same characters in multiple ways when combined with the end-of-string anchor ($). When the input contains a long run of asterisks that ultimately does not match the full pattern, the engine backtracks through all possible groupings of those asterisks before failing — a classic catastrophic backtracking pattern. The fix in 14.1.1 replaces or rewrites this regex to eliminate the ambiguous quantifier structure.

Technical Impact

An unauthenticated remote attacker can cause excessive CPU consumption on the server by submitting a crafted markdown payload (e.g., a long string of asterisks followed by a non-matching character). This can degrade application responsiveness or cause a denial-of-service condition for all users. No data confidentiality or integrity impact — this is a pure availability vulnerability.

Severity Justification

CVSS 4.0 base score of 6.9 per published advisory. Network-accessible, no authentication required, low attack complexity, but impact is limited to availability (no confidentiality or integrity impact). Exploitability depends on whether the application exposes markdown processing to untrusted input with linkify enabled.

Affected Components

• markdown-it >= 13.0.0 && < 14.1.1

Remediation Steps

1. Upgrade markdown-it to version 14.1.1 or later: run `npm install markdown-it@latest` or pin to `"markdown-it": "^14.1.1"` in package.json.
2. If you cannot upgrade immediately, disable the linkify option when instantiating markdown-it: `const md = markdownit({ linkify: false })`. This removes the vulnerable code path entirely.
3. Add server-side input length validation on any endpoint that processes markdown. Reject or truncate inputs exceeding a reasonable limit (e.g., 50,000 characters) before they reach the parser.
4. Apply rate limiting to markdown-rendering endpoints to reduce the blast radius of any attempted abuse.

Verification Steps

1. Run `npm list markdown-it` in your project root and confirm the installed version is 14.1.1 or higher.
2. Check your package.json and package-lock.json (or yarn.lock) to confirm the resolved version is not within the vulnerable range (>= 13.0.0 && < 14.1.1).
3. If you have automated tests, add a test that passes a string of 10,000 asterisks followed by 'X' to your markdown renderer and asserts it completes within a reasonable timeout (e.g., 500ms).

Code Examples (javascript)

// Vulnerable: markdown-it 13.0.0 – 14.1.0 with linkify enabled
import markdownit from 'markdown-it'
const md = markdownit({ linkify: true }) // linkify uses the vulnerable /\*+$/ regex
const output = md.render(userInput)      // attacker can supply '***...***X' to trigger ReDoS

// Fixed option 1: upgrade to markdown-it >= 14.1.1 (regex patched upstream)
// package.json: "markdown-it": "^14.1.1"
import markdownit from 'markdown-it'
const md = markdownit({ linkify: true }) // safe in 14.1.1+

// Fixed option 2: disable linkify if not needed (removes vulnerable code path entirely)
const md = markdownit({ linkify: false })

Best Practices

• Pin or range-lock third-party dependencies and run `npm audit` (or equivalent) in CI to catch known vulnerabilities before they reach production.
• Apply input length limits at the API layer before content reaches any parser — this limits the worst-case cost of any ReDoS-class vulnerability.
• Prefer atomic or possessive quantifiers, or use a linear-time regex engine, when writing custom regular expressions that process untrusted input.
• Run markdown rendering in a worker thread or with a CPU timeout so that a slow regex cannot block your main event loop.

References

• nvd.nist.gov/vuln/detail/CVE-2026-2327
• radar.offseq.com/threat/cve-2026-2327-regular-expression-denial-of-service-61f28507
• www.npmjs.com/package/markdown-it