SunEditor CVE-2026-59167

Exploitation requires a downstream application that (a) embeds SunEditor prior to 2.47.11, (b) accepts editor content from one (attacker) user, and (c) renders that content to other users without additional server-side sanitization. The specific technical trigger is a namespaced or custom HTML element (matching the pre-fix disallowed-tag regex gap, later broadened to cover style|meta|link|[a-z]+:[a-z]+) that retains an event-handler attribute the sanitizer failed to reject. Exploitation is LIMITED by required victim interaction with the crafted element (the handler fires on interaction, not passively) and by the application's content-rendering model - a single-user editor with no cross-user display of content is not exploitable. The default __allowedScriptTag setting also affects which tags are stripped.

The input assigns a CVSS 3.1 base score of 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), which is substantially overstated for a stored XSS in a client-side editor library. Two vector choices are inconsistent with the description: (1) UI:N contradicts the text 'when a user interacts with the element, the retained handler can execute script' - the retained event-handler attributes (e.g. onmouseover/onclick) require victim interaction, so UI:R is correct; and (2) C:H/I:H/A:H overstates typical XSS impact - script execution in the app origin realistically yields C:L/I:L with no availability impact, though the S:C scope change (attacker content executing in the hosting application's origin) is appropriate. There is no EPSS score, no CISA KEV listing, and no public POC provided, so all exploitation-likelihood signals are absent rather than elevated. This is a genuine but moderate-severity defense-in-depth issue in a JavaScript library, not a 10.0 emergency: exploitation depends on a downstream application choosing to render attacker-controlled SunEditor content to other users. Treat as a routine dependency-update priority, not an actively-exploited critical.

In an application that uses SunEditor (< 2.47.11) and renders one user's editor content to other users (e.g. comments, profiles, CMS posts), an attacker submits content containing a namespaced or custom HTML element carrying an event-handler attribute that the flawed sanitizer in src/lib/core.js fails to strip. When a victim later views and interacts with (hovers/clicks) that element, the retained handler runs JavaScript in the application's origin, enabling session/data theft or unauthorized actions. No public exploit code is identified at time of analysis, though the fixing commit publicly reveals the sanitizer-bypass mechanism.