Summary
Plate: Media embed provider metadata can bypass URL sanitization and execute iframe JavaScript
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.
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.
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.
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.
CVE-2026-55596 has a CVSS score of 8.7 (High). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (53.1.4); upgrading removes the vulnerable code path.
Affected versions
Security releases
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 @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.
Frequently Asked Questions
- What is CVE-2026-55596? CVE-2026-55596 is a high-severity cross-site scripting (XSS) vulnerability in @platejs/media (npm), affecting versions >= 53.0.0, < 53.1.4. It is fixed in 53.1.4. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
- How severe is CVE-2026-55596? CVE-2026-55596 has a CVSS score of 8.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of @platejs/media are affected by CVE-2026-55596? @platejs/media (npm) versions >= 53.0.0, < 53.1.4 is affected.
- Is there a fix for CVE-2026-55596? Yes. CVE-2026-55596 is fixed in 53.1.4. Upgrade to this version or later.
- Is CVE-2026-55596 exploitable, and should I be worried? Whether CVE-2026-55596 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
- What actually determines whether CVE-2026-55596 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.
- How do I fix CVE-2026-55596? Upgrade
@platejs/mediato 53.1.4 or later.