GHSA-QJ6X-XX2H-8HVV
Vulnerability from github – Published: 2026-08-25 16:29 – Updated: 2026-08-25 16:29Summary
The media embed renderer trusts serialized provider or sourceUrl metadata and skips the URL protocol validation that normally blocks unsafe media embed URLs. A crafted Plate document can set a known video provider while keeping url as a javascript: iframe source. When a victim opens that document in an app using the registry media embed component, the component renders the attacker URL directly as an iframe src.
Impact
An attacker who can create or share Plate document content with another user can execute JavaScript in the victim browser context when the victim opens the document. This can expose application data available to the page and perform actions as the victim, depending on the host application's session model.
Reproduction
Use a Plate editor or viewer that renders media embeds with the registry MediaEmbedElement and load a document containing this node:
{
"type": "media_embed",
"provider": "vimeo",
"sourceUrl": "https://vimeo.com/1",
"url": "javascript:parent.postMessage('plate-media-xss','*')",
"children": [{ "text": "" }]
}
When rendered, the node is treated as a Vimeo media embed because provider is present. The iframe receives the unvalidated url value as its src.
Root Cause / Technical Details
parseMediaUrl is the intended hardening point for media embed URLs and rejects parser output unless the URL protocol is http: or https:. However, useMediaState had a fast path for serialized nodes that already contain provider or sourceUrl. That fast path returned { id, provider, sourceUrl, url } directly and did not call parseMediaUrl or otherwise validate the stored url.
The registry MediaEmbedElement then checks that embed.provider is one of the video providers and renders non-YouTube video providers with <iframe src={embed.url}>. Because provider is attacker-controlled serialized document metadata, it can be set to vimeo while url remains javascript:....
This is fixed in @platejs/media 53.1.4 by recomputing embed metadata from the render URL instead of trusting serialized provider, id, or sourceUrl metadata.
PoC Evidence
A browser proof using the same data flow set an iframe src to:
javascript:parent.postMessage('plate-media-xss','*')
Chromium executed the iframe JavaScript and the parent page received plate-media-xss, confirming execution from the iframe source.
Remediation
Upgrade @platejs/media to 53.1.4 or later. Treat provider, sourceUrl, and id in serialized documents as untrusted derived metadata. Recompute embed metadata from url with parseMediaUrl, or at minimum validate any fast-path url with the same protocol allowlist before rendering an iframe.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@platejs/media"
},
"ranges": [
{
"events": [
{
"introduced": "53.0.0"
},
{
"fixed": "53.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55596"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-25T16:29:25Z",
"nvd_published_at": "2026-07-08T21:16:50Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe media embed renderer trusts serialized `provider` or `sourceUrl` metadata and skips the URL protocol validation that normally blocks unsafe media embed URLs. A crafted Plate document can set a known video provider while keeping `url` as a `javascript:` iframe source. When a victim opens that document in an app using the registry media embed component, the component renders the attacker URL directly as an iframe `src`.\n\n## Impact\n\nAn attacker who can create or share Plate document content with another user can execute JavaScript in the victim browser context when the victim opens the document. This can expose application data available to the page and perform actions as the victim, depending on the host application\u0027s session model.\n\n## Reproduction\n\nUse a Plate editor or viewer that renders media embeds with the registry `MediaEmbedElement` and load a document containing this node:\n\n```json\n{\n \"type\": \"media_embed\",\n \"provider\": \"vimeo\",\n \"sourceUrl\": \"https://vimeo.com/1\",\n \"url\": \"javascript:parent.postMessage(\u0027plate-media-xss\u0027,\u0027*\u0027)\",\n \"children\": [{ \"text\": \"\" }]\n}\n```\n\nWhen rendered, the node is treated as a Vimeo media embed because `provider` is present. The iframe receives the unvalidated `url` value as its `src`.\n\n## Root Cause / Technical Details\n\n`parseMediaUrl` is the intended hardening point for media embed URLs and rejects parser output unless the URL protocol is `http:` or `https:`. However, `useMediaState` had a fast path for serialized nodes that already contain `provider` or `sourceUrl`. That fast path returned `{ id, provider, sourceUrl, url }` directly and did not call `parseMediaUrl` or otherwise validate the stored `url`.\n\nThe registry `MediaEmbedElement` then checks that `embed.provider` is one of the video providers and renders non-YouTube video providers with `\u003ciframe src={embed.url}\u003e`. Because `provider` is attacker-controlled serialized document metadata, it can be set to `vimeo` while `url` remains `javascript:...`.\n\nThis is fixed in `@platejs/media` 53.1.4 by recomputing embed metadata from the render URL instead of trusting serialized `provider`, `id`, or `sourceUrl` metadata.\n\n## PoC Evidence\n\nA browser proof using the same data flow set an iframe `src` to:\n\n```text\njavascript:parent.postMessage(\u0027plate-media-xss\u0027,\u0027*\u0027)\n```\n\nChromium executed the iframe JavaScript and the parent page received `plate-media-xss`, confirming execution from the iframe source.\n\n## Remediation\n\nUpgrade `@platejs/media` to 53.1.4 or later. Treat `provider`, `sourceUrl`, and `id` in serialized documents as untrusted derived metadata. Recompute embed metadata from `url` with `parseMediaUrl`, or at minimum validate any fast-path `url` with the same protocol allowlist before rendering an iframe.",
"id": "GHSA-qj6x-xx2h-8hvv",
"modified": "2026-08-25T16:29:25Z",
"published": "2026-08-25T16:29:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/udecode/plate/security/advisories/GHSA-qj6x-xx2h-8hvv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55596"
},
{
"type": "WEB",
"url": "https://github.com/udecode/plate/pull/5014"
},
{
"type": "WEB",
"url": "https://github.com/udecode/plate/commit/6214914ca811adf22d0ad503154494216eed68ba"
},
{
"type": "PACKAGE",
"url": "https://github.com/udecode/plate"
},
{
"type": "WEB",
"url": "https://github.com/udecode/plate/releases/tag/v53.1.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Plate: Media embed provider metadata can bypass URL sanitization and execute iframe JavaScript"
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.