md-editor-v3 CVE-2026-84992

Exploitation requires (1) a host application that embeds md-editor-v3's MdPreview/MdEditor component at version <= 6.5.3, (2) that application accepting attacker-influenced Markdown, and (3) a victim rendering that Markdown (UI:R) - for stored XSS the application must also persist the Markdown and serve it to other users. Notably, having the shipped XSSPlugin enabled does NOT mitigate this, because the filter only inspects existing html_block/html_inline tokens and cannot see the renderer-generated HTML built from the fenced-code language value. The 'noHighlight: true' option only makes the PoC deterministic; the default highlighting path reaches the same unsafe return, so no special/non-default highlighting configuration is needed. Limiting factors: the attacker cannot exploit a deployment that never renders untrusted third-party Markdown, and only self-XSS results if no other user views the content.

This is a legitimate but moderate-severity client-side XSS (CWE-79) whose real-world risk hinges on deployment context rather than raw exploitability. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1 Medium) is internally consistent with the vulnerability: network-reachable, low complexity, no privileges on the vulnerable library, but requiring victim rendering (UI:R) and crossing into the browser security context (S:C). No EPSS score, no CISA KEV listing, and no independent/external exploit tracking are provided - however a fully working proof-of-concept payload IS published inside the GHSA advisory itself ('`x"><details/open/ontoggle=alert(document.domain)>'), so functional exploit code is effectively public. The most important nuance: the vendor scores PR:N because the md-editor-v3 library itself requires no authentication, but the ACTUAL attack surface depends entirely on the host application - whether it accepts and persists attacker-supplied Markdown determines if this is a self-XSS curiosity or a genuine stored-XSS vector against other users. Because md-editor-v3 is commonly embedded in comment systems, wikis, and note apps that store user Markdown, the stored-XSS path is realistic. Absence of EPSS/KEV signals reflects that this is a recently disclosed, non-mass-exploited library flaw, not that it is low-risk in an affected app - treat as a prompt-patch item for any application embedding this component and accepting untrusted Markdown.

An attacker submits Markdown containing a fenced code block whose language 'info string' carries a break-out payload (e.g. '`x"><details/open/ontoggle=alert(document.domain)>'), which md-editor-v3 interpolates unescaped into the code element's class/language HTML attributes, bypassing the shipped XSSPlugin because that filter only inspects pre-existing html tokens, not renderer-generated HTML. When another user's browser renders the stored content via MdPreview, the injected handler fires JavaScript in the application origin. A working PoC is published in the GHSA advisory, so exploitation is straightforward once an app accepts and displays untrusted Markdown.