GHSA-CP6Q-959Q-F8RH

GHSA-CP6Q-959Q-F8RH is a medium-severity cross-site scripting (XSS) vulnerability in @tiptap/core (npm), affecting versions >= 2.0.0-alpha.0, < 3.30.4. It is fixed in 3.30.4.

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: mergeAttributes() turns an own proto key into inherited executable DOM attributes

@tiptap/core's public mergeAttributes() helper uses ordinary bracket assignment on keys returned by Object.entries(). An own __proto__ key from JSON therefore invokes the legacy prototype setter on the fresh merged object. The function returns an object whose prototype is attacker-controlled, while Object.keys() and ordinary own-property checks show no attacker attributes.

When that result is used as a ProseMirror DOMOutputSpec attribute object, prosemirror-model's DOMSerializer.renderSpec() enumerates it with for...in and applies inherited values with setAttribute(). In a browser proof, inherited src and onerror values were copied to an <img> and the error handler executed once. This is per-object prototype manipulation; the proof does not modify global Object.prototype.

Root cause

The affected loop is conceptually:

const mergedAttributes = { ...items }
for (const [key, value] of Object.entries(item)) {
  const exists = mergedAttributes[key]
  // ...
  mergedAttributes[key] = value
}

Object.entries(JSON.parse('{"__proto__": {...}}')) includes __proto__. Reading mergedAttributes['__proto__'] resolves the inherited Object.prototype; assigning to the same key invokes Object.prototype.__proto__'s setter and replaces mergedAttributes' prototype.

Browser reproduction

The following shape was tested with exact @tiptap/core 3.29.2 and prosemirror-model 1.25.11:

const input = JSON.parse(`{
  "__proto__": {
    "data-inherited-canary": "present",
    "src": "x-invalid://canary",
    "onerror": "globalThis.__tiptapXss += 1"
  }
}`)

const attrs = mergeAttributes(input)
// Object.keys(attrs) === []
// Object.getPrototypeOf(attrs) === input.__proto__

const schema = new Schema({
  nodes: {
    doc: { content: 'image' },
    image: { toDOM: () => ['img', attrs] },
    text: {},
  },
})
const doc = schema.node('doc', null, [schema.node('image')])
const fragment = DOMSerializer.fromSchema(schema).serializeFragment(doc.content)
document.body.append(fragment)

Chromium produced an image with data-inherited-canary, src, and onerror; the handler executed exactly once. Object.prototype remained clean.

Impact and preconditions

Applications that merge untrusted imported document, plugin, CMS, API, tenant, or AI-derived attribute objects can receive a prototype-manipulated result. Consumers that enumerate inherited keys, including ProseMirror's DOM serializer, can turn the hidden properties into DOM attributes and execute JavaScript in the application's origin. Own-key validation, object spread, JSON serialization, and logging can miss the inherited values. Other component consumers can read inherited authorization or configuration fields.

Tiptap's standard fixed ProseMirror schemas discard unknown document attributes, so arbitrary Tiptap JSON is not automatically exploitable in every application. A vulnerable application needs an untrusted object boundary into mergeAttributes() or a dynamic/custom extension or schema that preserves the relevant attribute object.

Affected versions

The unsafe assignment was introduced in commit ecadf7ea0a7f8f39a8496a60edf0ac8f379e6eb3 and is present in the first package tag @tiptap/[email protected], v2.0.0, v2.27.1, v3.0.0, and current v3.29.2 source. No fixed release was found.

Recommended remediation

Reject __proto__ before reading or assigning the key, or define copied keys as own data properties without invoking legacy setters. A minimal hardening is to skip key === '__proto__'. Add regression tests using an own JSON-origin __proto__ key and assert that the result keeps Object.prototype as its prototype, exposes no inherited attacker keys, and cannot create an event-handler attribute through DOMSerializer.

This was found during authorized dependency review and is being reported privately. No public zero-day issue has been opened.

Impact

Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.

Affected versions

@tiptap/core (>= 2.0.0-alpha.0, < 3.30.4)

Security releases

@tiptap/core → 3.30.4 (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.4 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-CP6Q-959Q-F8RH? GHSA-CP6Q-959Q-F8RH is a medium-severity cross-site scripting (XSS) vulnerability in @tiptap/core (npm), affecting versions >= 2.0.0-alpha.0, < 3.30.4. It is fixed in 3.30.4. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
  2. Which versions of @tiptap/core are affected by GHSA-CP6Q-959Q-F8RH? @tiptap/core (npm) versions >= 2.0.0-alpha.0, < 3.30.4 is affected.
  3. Is there a fix for GHSA-CP6Q-959Q-F8RH? Yes. GHSA-CP6Q-959Q-F8RH is fixed in 3.30.4. Upgrade to this version or later.
  4. Is GHSA-CP6Q-959Q-F8RH exploitable, and should I be worried? Whether GHSA-CP6Q-959Q-F8RH 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-CP6Q-959Q-F8RH 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-CP6Q-959Q-F8RH? Upgrade @tiptap/core to 3.30.4 or later.

Stop the waste.
Protect your environment with Kodem.