# GHSA-j95f-988m-3j2f: Tiptap: Quadratic ReDoS in block and inline Markdown attribute parsing

> Attackers can cause denial of service in Tiptap editor by submitting crafted Markdown input that triggers quadratic regular expression backtracking.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 8 Sep 2026

## What is GHSA-j95f-988m-3j2f?

GHSA-j95f-988m-3j2f is a denial of service vulnerability in @tiptap/core, published on 8 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

## Summary

`@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:

```js
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.

```js
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.

## 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.

## 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.

## Which versions are affected by GHSA-j95f-988m-3j2f?

2 open source packages ship an affected version, including @tiptap/core.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@tiptap/core` | npm | From 3.7.0 | 3.30.5 |
| `@tiptap/core` | npm | From 3.7.0 | 3.30.5 |

## How do I fix GHSA-j95f-988m-3j2f?

Upgrade @tiptap/core to 3.30.5 or later.

## Is GHSA-j95f-988m-3j2f being exploited?

There is no known exploitation of GHSA-j95f-988m-3j2f in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-j95f-988m-3j2f and fix it if it is affected.

What it is: GHSA-j95f-988m-3j2f is a denial of service vulnerability in @tiptap/core, published on 8 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-j95f-988m-3j2f in the wild and no public exploit code.

Affected packages and fixed versions:
- @tiptap/core (npm): affected from 3.7.0; fixed in 3.30.5
- @tiptap/core (npm): affected from 3.7.0; fixed in 3.30.5

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-j95f-988m-3j2f/ (Markdown: https://insights.sbomify.com/GHSA-j95f-988m-3j2f/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-j95f-988m-3j2f

---
From sbomify Insights: https://insights.sbomify.com/GHSA-j95f-988m-3j2f/
Summaries are generated and may contain mistakes; the official description above is the record.