GHSA-J95F-988M-3J2F

GHSA-J95F-988M-3J2F is a high-severity uncontrolled resource consumption vulnerability in @tiptap/core (npm), affecting versions >= 3.7.0, < 3.30.5. It is fixed in 3.30.5.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

Tiptap: Quadratic ReDoS in block and inline Markdown attribute parsing

@tiptap/core contains two quadratic regular-expression denial-of-service paths in its default Markdown attribute parsers. Pandoc-style block attributes use two unanchored greedy expressions that rescan repeated __QUOTED_0 prefixes. Inline shortcode attributes use another unanchored greedy key expression that rescans a long word-character run when no equals sign follows.

The public createAtomBlockMarkdownSpec and createBlockMarkdownSpec helpers call the vulnerable Pandoc-style parser; createInlineMarkdownSpec calls the separately vulnerable shortcode parser. Using unmodified npm 3.29.2, a complete 20,508-byte atom-block token took approximately 1.40 seconds while an equal-length control took 0.29 ms. A complete 32,776-byte inline token took approximately 2.21 seconds while its equal-length control took 0.19 ms. Current repository main commit 5158212970344952dd9918b6a44bfb400d7fb6c1 retains both expressions.

Block attribute root cause

packages/core/src/utilities/markdown/attributeUtils.ts uses both matchAll and replace with /([a-zA-Z][\w-]*)\s*=\s*(__QUOTED_\d+__)/g. The candidate is '__QUOTED_0'.repeat(n) + '__QUOTED_0__'. There are no quotes, so the preceding replacement leaves it unchanged. At each Q, the greedy key-name expression consumes the remaining word-character run, the required equals sign fails, and the unanchored engine restarts at the next Q. This yields O(n^2) work, and the cleanup pass repeats it.

A complete public-API proof is:

import { createAtomBlockMarkdownSpec } from '@tiptap/core'
const tokenizer = createAtomBlockMarkdownSpec({ nodeName: 'probe' }).markdownTokenizer
const attack = '__QUOTED_0'.repeat(2048) + '__QUOTED_0__'
const source = `:::probe {${attack}} :::\n`
const started = performance.now()
tokenizer.tokenize(source, [], {})
console.log(performance.now() - started)

Measured complete-tokenizer timings were 6.23, 23.12, 88.93, 369.10, and 1,400.17 ms at 1,308, 2,588, 5,148, 10,268, and 20,508 bytes. Equal-length controls took 0.07 to 0.29 ms. The directly exported parser took 5,645.71 ms at 40,972 bytes while its control took 0.64 ms.

Inline attribute root cause

packages/core/src/utilities/markdown/createInlineMarkdownSpec.ts uses /(\w+)=(?:"([^"]*)"|'([^']*)')/g. For a long word-character run without an equals sign, \w+ consumes the remaining suffix, = fails, and the unanchored engine restarts at the next character. The default inline tokenizer extracts this attacker string directly from a syntactically complete [shortcode attributes] token.

import { createInlineMarkdownSpec } from '@tiptap/core'
const tokenizer = createInlineMarkdownSpec({ nodeName: 'probe', selfClosing: true }).markdownTokenizer
const source = `[probe ${'0'.repeat(32768)}]`
const started = performance.now()
tokenizer.tokenize(source, [], {})
console.log(performance.now() - started)

At 1,032, 2,056, 4,104, 8,200, 16,392, and 32,776 bytes, candidates took 3.24, 12.88, 54.82, 136.91, 557.83, and 2,209.47 ms. Equal-length hyphen controls took 0.02 to 0.19 ms.

History and remediation

Commit 35645d94ae9cd73448a564104c2e08f64e9564bc introduced both parsers on 14 October 2025, first released in 3.7.0. Versions 3.7.0 through current 3.29.2 and current main remain affected. Official issue, PR, and repository-advisory searches found no duplicate.

Require a start-of-string or whitespace boundary before both key-value parsers, and preferably replace the multi-pass placeholder and shortcode regex designs with deterministic single-pass tokenizers. Keep quoted values out-of-band so attacker input cannot collide with predictable __QUOTED_n__ placeholders. Add complete block and inline Markdown-tokenizer scaling regressions with equal-length controls.

Please credit GitHub user joostgrunwald as finder/reporter.

Impact

Applications parsing attacker-controlled Markdown with these helpers can have a browser main thread, server event loop, or worker blocked by a small input. Persisted documents can repeatedly freeze clients; repeated requests can exhaust server-side parsing capacity. Editors that only consume validated ProseMirror JSON and never invoke the Markdown parsing path are not directly affected through document content.

Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.

Affected versions

@tiptap/core (>= 3.7.0, < 3.30.5)

Security releases

@tiptap/core → 3.30.5 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade @tiptap/core to 3.30.5 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is GHSA-J95F-988M-3J2F? GHSA-J95F-988M-3J2F is a high-severity uncontrolled resource consumption vulnerability in @tiptap/core (npm), affecting versions >= 3.7.0, < 3.30.5. It is fixed in 3.30.5. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
  2. Which versions of @tiptap/core are affected by GHSA-J95F-988M-3J2F? @tiptap/core (npm) versions >= 3.7.0, < 3.30.5 is affected.
  3. Is there a fix for GHSA-J95F-988M-3J2F? Yes. GHSA-J95F-988M-3J2F is fixed in 3.30.5. Upgrade to this version or later.
  4. Is GHSA-J95F-988M-3J2F exploitable, and should I be worried? Whether GHSA-J95F-988M-3J2F is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether GHSA-J95F-988M-3J2F is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix GHSA-J95F-988M-3J2F? Upgrade @tiptap/core to 3.30.5 or later.

Stop the waste.
Protect your environment with Kodem.